Зависла проверка базы 1С: как безопасно прервать процесс

Остановить тестирование и исправление в Конфигураторе 1С 8.3 можно только снятием процесса: в файловой базе — завершением 1cv8.exe в диспетчере задач, в клиент-серверной — удалением сеанса Конфигуратора в консоли кластера или прерыванием запроса в СУБД. Делать это стоит, когда проверка действительно зависла, а не просто идёт долго.

Прерванная на этапе реструктуризации или сжатия проверка может оставить базу в неконсистентном состоянии. Поэтому до любого «убийства» процесса убедитесь, что есть свежая резервная копия, и решите, готовы ли вы к ней откатиться.

Можно ли прервать проверку и чем это грозит

Тестирование и исправление (Администрирование → Тестирование и исправление… в Конфигураторе) работает в монопольном режиме. Пока оно идёт, пользователи в базу не войдут, а сам Конфигуратор на действия не отвечает.

Риск прерывания зависит от того, что именно делала платформа в момент остановки:

• 🟢 Проверка логической или ссылочной целостности в режиме «только тестирование» — данные не меняются, прерывание почти безопасно.
• 🟡 Пересчёт итогов — итоги останутся неполными. Их можно пересчитать заново, данные документов не страдают.
• 🔴 Реструктуризация таблиц, реиндексация, сжатие — платформа переписывает таблицы. Обрыв в этот момент — самый опасный сценарий.

Как отличить зависшую проверку от долгой

На базе в 20–30 ГБ полная проверка с реструктуризацией идёт часами. Окно Конфигуратора при этом часто пишет «Не отвечает» — это нормально и ещё не повод останавливать процесс.

Признаки, что проверка работает:

• 📈 процесс 1cv8.exe (файловая база) или rphost.exe (сервер) нагружает процессор или диск;
• 💾 в мониторе ресурсов Windows видно чтение и запись файла 1Cv8.1CD или файлов данных СУБД;
• 📊 в строке состояния Конфигуратора меняется прогресс, если окно перерисовывается.

Признаки зависания:

• ⏸ нагрузка на процессор и диск у процесса около нуля 15–20 минут и больше;
• 🔒 в СУБД сеанс 1С висит в ожидании блокировки, которую держит другой сеанс;
• ❌ процесс занимает всю доступную память и не освобождает её.

Ещё одна частая причина «зависания» в серверной базе — проверка ждёт блокировку. Например, регламентное задание или сеанс обмена успели подключиться до установки монопольного режима и держат таблицу. Снимите такой сеанс, и проверка часто продолжает работу сама, без остановки.

Для клиент-серверной базы картина видна точнее в консоли кластера: у сеанса Конфигуратора обновляется время текущего вызова и растут счётчики обращений к СУБД. Если цифры замерли — процесс стоит.

Остановка тестирования и исправления в файловой базе

В файловом варианте всю работу делает сам процесс Конфигуратора на вашем компьютере (или на сервере терминалов, где он запущен). Остановить его — значит завершить этот процесс.

1. Убедитесь, что у вас есть копия каталога базы, сделанная до запуска проверки.
2. Откройте диспетчер задач (Ctrl+Shift+Esc), вкладку «Подробности».
3. Найдите процесс 1cv8.exe. Если запущено несколько, ориентируйтесь на столбец «Имя пользователя» и на того, который грузит диск.
4. Выберите «Снять задачу».
5. Дождитесь, пока процесс исчезнет из списка, и только потом запускайте Конфигуратор снова.

На сервере терминалов то же самое удобно сделать из командной строки администратора:

tasklist /fi "imagename eq 1cv8.exe" /v
taskkill /pid 12345 /f

Вместо 12345 подставьте PID нужного процесса из первой команды. Не завершайте все 1cv8.exe подряд — снимете работающих пользователей других баз.

Для физической проверки файловой базы есть отдельная утилита chdbfl.exe из каталога bin платформы. Её можно запустить вместо Конфигуратора, когда база не открывается вовсе. Работает она тоже монопольно, а останавливается кнопкой в своём окне или снятием процесса.

Служебные файлы в каталоге базы и файл dbv77cd.1cd

В каталоге файловой базы 8.3 рабочие данные лежат в одном файле 1Cv8.1CD. Рядом могут появляться служебные файлы: временный 1Cv8tmp.1CD и файл блокировки 1Cv8.1CL.

В инструкциях по остановке проверки встречается имя dbv77cd.1cd. Такого служебного файла в файловой базе 8.3 нет: по названию это наследие версии 7.7, где использовались другие форматы хранения. Если вы видите в каталоге 8.3 посторонний файл с похожим именем, он не участвует в тестировании и исправлении и не влияет на его остановку.

Что делать со служебными файлами после принудительного снятия процесса:

• 📁 1Cv8.1CD — не трогать. Это и есть база.
• 🧹 1Cv8tmp.1CD — временный файл. Если после снятия процесса он остался, а в базе точно никого нет, его можно перенести в другую папку.
• 🔐 1Cv8.1CL — признак того, что базу кто-то держит. Если все процессы 1cv8.exe по этой базе завершены, а файл не удаляется, значит его держит ещё один процесс или сетевая сессия.

Снять сеанс Конфигуратора в консоли кластера 1С

В клиент-серверном варианте проверку выполняет не клиент, а рабочий процесс rphost на сервере 1С. Закрыть Конфигуратор на своём компьютере недостаточно: серверная часть может продолжить работу или остаться висеть с монопольной блокировкой.

Через оснастку «Администрирование серверов 1С:Предприятия»

1. Откройте оснастку и раскройте кластер → «Информационные базы» → нужная база → «Сеансы».
2. Найдите сеанс с приложением «Конфигуратор» от вашего пользователя.
3. Посмотрите время текущего вызова. Если оно растёт, сеанс работает.
4. Чтобы прервать проверку, вызовите контекстное меню сеанса и выберите удаление.
5. Обновите список и убедитесь, что сеанс исчез. В ветке «Соединения» не должно остаться соединения Конфигуратора.

После удаления сеанса сервер откатывает незавершённую транзакцию в СУБД. На большой таблице откат может идти долго, и в это время база ещё занята.

Через утилиту rac

Если оснастка недоступна, то же можно сделать через rac при запущенном ras:

rac cluster list
rac session list --cluster=<id_кластера>
rac session terminate --cluster=<id_кластера> --session=<id_сеанса>

Если на кластере задан администратор, добавьте учётные данные. Точный набор параметров для вашей версии платформы смотрите в rac help session.

Как прервать процесс проверки на уровне СУБД

Иногда сеанс 1С уже удалён, а в СУБД висит запрос от рабочего процесса, который держит блокировки. Тогда остановка нужна на стороне СУБД. Её делает администратор базы данных.

MS SQL Server

Найдите соединение по имени базы и посмотрите, что оно делает:

EXEC sp_who2;

SELECT session_id, status, command, wait_type, blocking_session_id
FROM sys.dm_exec_requests
WHERE database_id = DB_ID('ИмяБазы');

Прервать выбранное соединение:

KILL 57;
KILL 57 WITH STATUSONLY;

Вторая команда показывает ход отката. Если реструктуризация успела изменить много строк, откат может занять сопоставимое с ней время. Повторный KILL его не ускорит.

PostgreSQL

SELECT pid, state, wait_event_type, query_start, left(query, 80)
FROM pg_stat_activity
WHERE datname = 'имя_базы';

SELECT pg_cancel_backend(12345);
SELECT pg_terminate_backend(12345);

Сначала пробуйте pg_cancel_backend — отменяет текущий запрос. Если не помогло, pg_terminate_backend закрывает соединение целиком.

Что проверить после принудительной остановки

Сразу работать в базе после прерванной проверки не стоит. Порядок такой:

1. Откройте базу в Конфигураторе. Если открылась без ошибок, перейдите в Администрирование → Журнал регистрации и отфильтруйте события по времени проверки: увидите, на каком этапе она оборвалась.
2. Запустите тестирование и исправление повторно, но только с теми флажками, которые не успели выполниться. Не повторяйте заново всю цепочку, если, например, реиндексация уже прошла.
3. Если на этапе реструктуризации база выдаёт ошибки при открытии, восстановите копию и запускайте проверку в спокойное время, без прерываний.
4. Пересчитайте итоги, если остановка пришлась на их пересчёт.

Как запускать проверку, чтобы не прерывать её

Большинство вынужденных остановок происходит потому, что проверку запустили днём, когда базу ждут пользователи. Профилактика простая.

Копия перед запуском. Для файловой базы — копия каталога с 1Cv8.1CD при закрытой базе. Для серверной — резервная копия средствами СУБД или выгрузка .dt через Администрирование → Выгрузить информационную базу.

Монопольный режим без сюрпризов. Проверка не стартует, пока в базе есть другие сеансы. Заранее закройте вход:

• в консоли кластера в свойствах базы включите блокировку начала сеансов и задайте код разрешения;
• в самой конфигурации на БСП (БП 3.0, ЗУП 3.1, УТ 11) — в разделе Администрирование, через команду блокировки работы пользователей в группе обслуживания.

Сами вы входите с кодом разрешения через параметр запуска /UC<код>.

Ночной запуск без окна. Проверку можно выполнить в пакетном режиме Конфигуратора по расписанию:

"C:\Program Files\1cv8\8.3.24.1691\bin\1cv8.exe" DESIGNER /F"D:\Bases\Buh" /N"Администратор" /P"пароль" /IBCheckAndRepair -LogIntegrity /Out"D:\Logs\check.log"

Путь к платформе и номер версии подставьте свои. Набор ключей проверки смотрите в справке Конфигуратора по параметрам командной строки. Лог в /Out покажет, чем закончилась проверка, даже если смотреть утром.

Место на диске. Реструктуризация и сжатие переписывают таблицы, поэтому на диске с базой нужен запас свободного места, сопоставимый с размером самой базы. Если места не хватит, проверка упадёт или встанет на середине — ровно в том состоянии, которое потом приходится разбирать.

Антивирус. Добавьте каталог файловой базы и файлы *.1CD в исключения проверки при доступе. Антивирус, сканирующий каждую запись в многогигабайтный файл, растягивает тестирование в разы, и его легко принять за зависание.

Одна база — один запуск. Не запускайте проверку двух больших баз на одном сервере одновременно: они делят диск, и обе пойдут медленнее. Очередь из двух ночных заданий надёжнее.

Сначала — только тестирование. Запустите проверку без исправления. Это быстрее и безопасно для прерывания. Режим исправления включайте, когда знаете, что именно сломано.

Частые вопросы