Администрирование · 10 мин
Как прервать тестирование и исправление в 1С и не повредить базу
Как безопасно прервать тестирование и исправление в 1С, чем это грозит базе, что делать после остановки и когда лучше запустить проверку заново.
Тестирование и исправление (ТиИ) — штатный инструмент 1С для проверки физической и логической целостности информационной базы. Проблема в том, что на больших базах процедура может идти часами, а иногда выглядит «зависшей»: индикатор не двигается, процессор или диск загружены на 100%, пользователи не могут войти в систему. Возникает резонный вопрос — можно ли прервать процесс и что будет с базой после этого.
Коротко: прервать ТиИ можно, но способ зависит от режима работы базы (файловый или клиент-серверный) и от того, на каком этапе находится проверка. Самое опасное — обрывать процесс, когда уже включён режим «исправления» и идёт запись изменений в таблицы. Неправильная остановка способна превратить рабочую базу в нечитаемую, особенно в файловом варианте.
Ниже разберём, как понять, что процесс действительно завис, как корректно его остановить в каждом режиме, что проверить после прерывания и как организовать работу, чтобы не пришлось гасить проверку на половине пути.
Как понять, что процесс завис, а не просто долго работает
Прежде чем прерывать, убедитесь, что ТиИ действительно зависло. На базах объёмом в десятки гигабайт проверка отдельных таблиц (например, журнала документов или регистра накопления) может занимать десятки минут без видимого прогресса в окне конфигуратора.
Признаки реальной работы: процесс 1cv8.exe (или rphost на сервере) потребляет процессор и активно читает/пишет диск, файл базы или temp-файлы меняют размер, в диспетчере задач видна дисковая активность. Признаки зависания: нулевая загрузка CPU и диска длительное время, процесс не отвечает, на сервере СУБД виден зависший запрос или взаимоблокировка.
Дождитесь завершения этапа, прерывать не нужно
Проверьте блокировки на СУБД и логи
Проверка на сервере могла продолжиться — проверьте сеансы в консоли кластера
Оцените нагрузку процесса 1cv8.exe перед снятием задачи
Прерывание в файловом режиме
В файловом варианте ТиИ выполняется процессом конфигуратора (1cv8.exe) на том компьютере, где он запущен. Прервать его можно только одним способом — снять задачу через диспетчер задач Windows. Штатной кнопки «Отмена» у этой операции нет.
Порядок действий: откройте диспетчер задач, найдите процесс 1cv8.exe с запущенным конфигуратором, убедитесь по загрузке CPU/диска, что он не выполняет активную запись, и снимите задачу. После этого файл 1Cv8.1CD может остаться в неконсистентном состоянии, особенно если ТиИ шло с включённым исправлением ошибок.
Сразу после снятия процесса не открывайте базу в рабочем режиме. Сначала сделайте копию файла 1Cv8.1CD (простым копированием), затем запустите проверку утилитой chdbfl.exe из каталога bin установленной платформы — она проверяет физическую целостность файловой базы и работает быстрее, чем полное ТиИ.
Прерывание в клиент-серверном режиме
В клиент-серверном варианте проверка выполняется рабочим процессом кластера (rphost) с запросами к СУБД (MS SQL, PostgreSQL и др.). Здесь у администратора больше контроля: можно завершить конкретный сеанс, не трогая весь сервер.
Первый способ — через консоль кластера серверов 1С: откройте ветку «Сеансы» нужной базы, найдите сеанс конфигуратора, запустившего ТиИ, и удалите его. Сеанс завершится, а транзакция на СУБД откатится. Второй способ — на уровне СУБД: в MS SQL через Activity Monitor или команду KILL по номеру SPID, в PostgreSQL через pg_terminate_backend. Этот вариант применяют, когда сеанс в консоли кластера не отображается или не удаляется.
Плюс клиент-серверного режима в том, что СУБД обеспечивает транзакционность: откат прерванной операции обычно возвращает базу в целостное состояние. Минус — откат большой транзакции сам по себе может занять заметное время, и в этот период база остаётся недоступной или частично заблокированной.
- 1Убедитесь, что процесс действительно завис: проверьте CPU, диск, активность на СУБД
- 2Проверьте наличие актуальной резервной копии; если её нет — по возможности сделайте копию файла или снимок базы
- 3В клиент-серверном режиме завершите сеанс через консоль кластера; в файловом — снимите процесс 1cv8.exe
- 4Дождитесь отката транзакции на СУБД (в клиент-серверном режиме)
- 5Проверьте целостность базы: chdbfl для файловой, штатные средства СУБД для серверной
- 6Проанализируйте логи и выясните причину зависания перед повторным запуском
Что делать сразу после прерывания
После остановки процесса главная задача — убедиться, что база не повреждена. Для файловой базы запустите chdbfl.exe: укажите путь к 1Cv8.1CD, включите проверку (при необходимости — с исправлением) и дождитесь результата. Утилита покажет, есть ли физические повреждения таблиц.
Для клиент-серверной базы проверьте логи СУБД на предмет ошибок, убедитесь, что откат транзакции завершён и нет подвисших блокировок. Затем войдите в базу в пользовательском режиме и проверьте доступность ключевых данных: откройте несколько документов, журналы, отчёты за разные периоды.
Если повреждения обнаружены — не запускайте повторное ТиИ «поверх» в надежде, что оно всё починит. Сначала восстановите базу из резервной копии или выполните исправление утилитой chdbfl (для файлового режима), и только потом планируйте новую проверку.
Как проверить результат после прерывания
База открывается в конфигураторе и пользовательском режиме без ошибок
Ошибка формата потока, ошибка СУБД, база не открывается
Проверка завершается без сообщений о повреждениях
Найдены повреждённые таблицы или страницы данных
Списки открываются, документы проводятся
Ошибки при чтении записей, пустые таблицы
Нет зависших сессий и блокировок
Висят процессы с откатом или блокировками
Почему ТиИ зависает и как этого избежать
Типичные причины чрезмерно долгой работы: большой объём базы, включённая реструктуризация таблиц, проверка ссылочной целостности на базе с миллионами записей, медленные диски, нехватка оперативной памяти, антивирус, сканирующий файл базы в реальном времени, а в клиент-серверном режиме — блокировки со стороны других сеансов, если монопольный режим не был установлен корректно.
Чтобы не пришлось прерывать процесс, планируйте ТиИ заранее: запускайте его в нерабочее время, отключайте лишние проверки (например, реструктуризацию и проверку ссылочной целостности можно выполнять отдельно и реже), добавьте каталог базы в исключения антивируса, убедитесь в достаточном объёме свободного места на диске.
Полезная практика — запускать ТиИ не на рабочей базе, а на её копии. Так вы получите список ошибок без риска и простоя, а исправление на рабочей базе выполните точечно и под контролем.
Когда прерывать нельзя и что делать вместо этого
Есть ситуации, когда прерывание почти гарантированно приведёт к повреждению данных: идёт реструктуризация таблиц (платформа перестраивает структуру данных), включено исправление ошибок с активной записью, выполняется загрузка/выгрузка или обновление конфигурации параллельно. В этих случаях правильнее дождаться завершения текущего этапа, даже если он длится долго.
Если ждать невозможно (например, база нужна пользователям утром), альтернатива — восстановление из последней резервной копии на отдельном сервере и перенос данных, либо отказ от ТиИ в пользу точечного решения конкретной проблемы, ради которой проверка запускалась.
Как выбрать действие
Что важно запомнить
Прерывание ТиИ допустимо, но только после проверки, что процесс действительно завис, и при наличии резервной копии. В клиент-серверном режиме завершайте сеанс через консоль кластера, в файловом — снимайте процесс и сразу проверяйте базу утилитой chdbfl. Лучшая защита — запуск проверки на копии базы и в нерабочее время.
Частые вопросы
Можно ли прервать тестирование и исправление кнопкой в конфигураторе?
Нет, штатной кнопки отмены у этой операции нет. Остановить процесс можно только внешними средствами: диспетчером задач для файлового режима или завершением сеанса через консоль кластера / СУБД для клиент-серверного.
Что будет с базой, если выдернуть питание компьютера во время ТиИ?
Для файловой базы это худший сценарий: высок риск повреждения 1Cv8.1CD, особенно если шла запись. После такого сбоя проверьте файл утилитой chdbfl до открытия базы. Клиент-серверная база обычно переживает обрыв клиента без последствий благодаря транзакционности СУБД.
Зависло ТиИ на одной таблице — это нормально?
На очень больших таблицах (регистры накопления, журналы документов) проверка может идти десятки минут без видимого прогресса. Ориентируйтесь не на индикатор, а на активность процесса: загрузку CPU и диска.
Нужно ли после прерывания запускать ТиИ заново полностью?
Не обязательно. Сначала выясните причину зависания и проверьте целостность базы. Повторную проверку имеет смысл запускать выборочно — только нужные виды проверок, желательно на копии базы.
Можно ли запускать ТиИ, пока пользователи работают в базе?
Нет, для ТиИ требуется монопольный доступ: все сеансы должны быть завершены. Попытка запуска в многопользовательском режиме приведёт либо к отказу в установке монопольного режима, либо к блокировкам и конфликтам.
Чем chdbfl отличается от тестирования и исправления?
chdbfl проверяет только физическую целостность файла файловой базы (структуру страниц и таблиц) и работает быстрее. ТиИ дополнительно проверяет логическую целостность данных, ссылки и может выполнять реструктуризацию. После аварийной остановки разумно начать с chdbfl.