Как прервать тестирование и исправление базы 1С 8.3

Тестирование и исправление информационной базы (ТиИ) — штатный механизм конфигуратора 1С, который проверяет логическую и физическую целостность данных и устраняет найденные ошибки. Проблема в том, что на больших базах процедура может выполняться часами, а иногда внешне «зависает»: индикатор прогресса не двигается, окно не отвечает. В такой ситуации администратору нужно понять, действительно ли процесс завис, и как его остановить, не усугубив повреждения.

Прерывание ТиИ — потенциально опасная операция. В файловом режиме утилита напрямую перезаписывает файл 1Cv8.1CD, и внезапная остановка может оставить базу в промежуточном состоянии. В клиент-серверном варианте изменения выполняются средствами СУБД внутри транзакций, что снижает риск, но не устраняет его полностью. Поэтому первое правило: перед любым запуском ТиИ, особенно с включёнными режимами исправления, должна существовать свежая резервная копия.

Ниже разобраны признаки реального зависания, способы остановки процесса для файлового и клиент-серверного вариантов, действия после прерывания и типичные ошибки, которые превращают управляемую ситуацию в аварийную.

Как понять, что ТиИ действительно зависло, а не просто работает долго

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

Откройте диспетчер задач Windows и посмотрите на процесс конфигуратора (1cv8.exe): если загрузка процессора или диска заметно отличается от нуля, работа идёт. Для клиент-серверной базы проверьте активность на стороне СУБД: в MS SQL Server это представления sys.dm_exec_requests и монитор активности, в PostgreSQL — представление pg_stat_activity. Наличие выполняющихся запросов от сеанса 1С означает, что процесс жив.

Реальным зависанием можно считать ситуацию, когда в течение продолжительного времени (десятки минут и более при видимом простое) нет ни дисковой, ни процессорной активности со стороны процесса, нет запросов на стороне СУБД, а файл базы не изменяется. Только после такой проверки имеет смысл переходить к принудительной остановке.

Штатные способы остановки: отмена и закрытие конфигуратора

Первый и самый безопасный способ — нажать кнопку отмены в окне выполнения операции, если оно отвечает. Платформа завершит текущий элемент обработки и остановит процедуру. Важно понимать: отмена не откатывает уже внесённые исправления. Если ТиИ работало в режиме «исправлять ошибки», часть изменений уже записана в базу, и состояние данных может отличаться от исходного.

Второй вариант — закрыть окно конфигуратора стандартным способом. Платформа выдаст запрос на прерывание выполняемой операции. Это мягче, чем снятие задачи, потому что даёт механизму шанс корректно завершить текущую запись. Не выключайте компьютер и не разрывайте сетевое соединение: аварийное обесточивание в момент записи — один из главных источников физических повреждений файловой базы.

Принудительное прерывание в файловом режиме

Если конфигуратор не отвечает, остаётся снять задачу. Откройте диспетчер задач (Ctrl+Shift+Esc), найдите процесс 1cv8.exe, соответствующий зависшему конфигуратору, и завершите его. Убедитесь, что завершаете именно тот процесс: если открыто несколько сеансов 1С, ориентируйтесь по командной строке процесса (включается в параметрах столбцов диспетчера задач).

Файловая база в этот момент наиболее уязвима: утилита chdbfl.exe и механизм ТиИ работают с файлом 1Cv8.1CD напрямую. После снятия задачи не запускайте базу в рабочем режиме сразу. Сначала скопируйте файл 1Cv8.1CD в отдельный каталог — это будет аварийный слепок текущего состояния. Затем проверьте физическую целостность утилитой chdbfl.exe из каталога bin установленной платформы, указав файл базы и запустив проверку сначала без исправления ошибок.

Если chdbfl показывает ошибки, решение об исправлении принимайте, только имея копию файла. При серьёзных повреждениях надёжнее восстановить базу из резервной копии, сделанной до запуска ТиИ, чем накатывать исправления на уже повреждённый файл.

1. 1
   Убедитесь в отсутствии активности процесса в диспетчере задач
2. 2
   Попробуйте отмену операции или закрытие окна конфигуратора
3. 3
   При отсутствии реакции завершите процесс 1cv8.exe нужного сеанса
4. 4
   Скопируйте файл 1Cv8.1CD в резервный каталог
5. 5
   Запустите chdbfl.exe в режиме проверки без исправления
6. 6
   По результатам решите: работать дальше или восстанавливать из копии

Принудительное прерывание в клиент-серверном режиме

В клиент-серверном варианте снятие процесса конфигуратора на клиентской машине недостаточно: основная работа выполняется на сервере 1С и в СУБД. После закрытия клиентского процесса сеанс на сервере может какое-то время оставаться активным и продолжать выполнение запросов. Проверьте консоль кластера серверов 1С: найдите зависший сеанс по пользователю и времени начала и завершите его штатно через контекстное меню сеанса.

Если после завершения сеанса на стороне СУБД остаются выполняющиеся запросы, завершите их средствами самой СУБД. В MS SQL Server это команда KILL с номером SPID, в PostgreSQL — функция pg_terminate_backend с идентификатором процесса. СУБД откатит незавершённую транзакцию, что обычно возвращает базу в согласованное состояние на момент начала последней транзакции.

-- PostgreSQL: завершение зависшего бэкенда
SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname = 'my_base' AND state = 'active' AND query_start < now() - interval '30 minutes';

После прерывания проверьте журналы: технологический журнал платформы (если настроен), журнал ошибок СУБД и консоль кластера. Они подскажут, на каком этапе остановился процесс и не осталось ли блокировок. Затем выполните контрольный запуск ТиИ в режиме «только тестирование» без исправления — это покажет, есть ли в базе ошибки после прерывания.

Что делать после прерывания: проверка и восстановление

Алгоритм после любой принудительной остановки одинаков: сначала зафиксировать текущее состояние, потом диагностировать, и только затем исправлять. Снимите копию базы в том виде, в каком она осталась после прерывания, — этот слепок пригодится, если последующие действия ухудшат ситуацию.

Далее запустите ТиИ в режиме «тестирование без исправления» или проверку chdbfl для файловой базы. Если ошибок нет — база, скорее всего, цела, и можно возвращаться к работе. Если ошибки есть, сопоставьте их объём с наличием резервной копии: при свежей копии восстановление из неё почти всегда надёжнее, чем исправление на живой базе. После восстановления проанализируйте, какие данные введены после создания копии, и организуйте их повторный ввод.

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

Большинство проблем с прерыванием ТиИ устраняются подготовкой. Запускайте процедуру в нерабочее время, когда в базе нет пользователей, — монопольный режим для ТиИ обязателен в любом случае. Разбивайте проверку на этапы: сначала реиндексация, затем проверка логической целостности, затем ссылочной — так проще контролировать прогресс и локализовать проблемный этап.

Следите за ресурсами сервера: нехватка оперативной памяти и места на диске — частая причина «зависаний», которые на деле являются мучительно медленной работой с подкачкой. Перед запуском убедитесь, что на диске достаточно свободного места (для файловой базы — ориентировочно с запасом относительно размера 1Cv8.1CD), и настройте технологический журнал, чтобы в случае проблемы видеть, на каком этапе остановился процесс.

Часто задаваемые вопросы