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

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

Главная опасность связана с режимами, которые не просто проверяют, а изменяют базу: «Тестирование и исправление», реиндексация, сжатие таблиц. Если прервать их в момент записи, файл базы или таблицы на сервере СУБД могут остаться в повреждённом состоянии. Поэтому корректная последовательность действий зависит от типа базы — файловая она или клиент-серверная.

Почему процесс нельзя просто «отменить»

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

Отсутствие реакции интерфейса — не всегда признак зависания. На объёмных базах отдельные этапы (например, проверка ссылочной целостности большой таблицы документов) могут занимать десятки минут без видимого прогресса. Прежде чем прерывать процесс, стоит убедиться, что он действительно остановился, а не просто выполняется медленно.

Как определить, зависло тестирование или ещё работает

Откройте диспетчер задач Windows (Ctrl+Shift+Esc) и найдите процесс конфигуратора. Если по столбцам «ЦП» и «Диск» есть регулярная активность, процесс выполняется — на больших таблицах это нормально. Дополнительно можно посмотреть на файл базы или каталог: изменение размера временных файлов и времени модификации также говорит о продолжающейся работе.

Для клиент-серверного варианта проверку нужно делать на стороне сервера: в консоли кластера 1С видно активный сеанс и соединение с СУБД, а в мониторе SQL-сервера — выполняющиеся запросы. Если запросы к базе идут, прерывать операцию особенно опасно: транзакция может находиться в середине изменения данных.

Зависание разумно диагностировать, когда все признаки активности отсутствуют продолжительное время: ноль по процессору и диску, нет запросов на СУБД, индикатор не меняется. Частая причина такого состояния — нехватка места на диске (при сжатии и реиндексации создаются временные копии таблиц) или повреждение базы, на котором проверка «зацикливается».

Как безопасно прервать процесс в файловой базе

Если решение об остановке принято, действуйте в такой последовательности. Сначала дождитесь паузы в дисковой активности — момент, когда запись не ведётся. Затем откройте диспетчер задач, найдите процесс конфигуратора (1cv8.exe) и выберите «Снять задачу». Это единственный способ прервать операцию, штатного механизма отмены платформа не предоставляет.

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

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

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

Остановка тестирования в клиент-серверном варианте

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

Если запрос уже ушёл в СУБД и выполняется там, его придётся завершать средствами самой СУБД (например, командой отмены сессии в MS SQL Server или PostgreSQL). Это операция для администратора баз данных: принудительное прерывание длинной транзакции вызовет её откат, который на больших таблицах сам по себе может занять значительное время. В этот период база будет недоступна или работать медленно — это нормально и не повод перезагружать сервер.

Чем грозит прерывание и как восстановить базу

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

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

Порядок восстановления такой. Для файловой базы сначала прогоните chdbfl.exe с включённым исправлением ошибок — утилита работает на уровне физической структуры файла. Затем, если база открывается, выполните тестирование и исправление в конфигураторе. Если повреждения серьёзные или утилита не помогла, единственный надёжный вариант — восстановление из резервной копии, сделанной до запуска операции. Для клиент-серверной базы используйте средства резервного копирования и восстановления СУБД.

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

Как не допустить ситуации, когда приходится прерывать процесс

Большинство проблем с остановкой тестирования возникает из-за нарушения базовых правил подготовки. Перед запуском всегда делайте резервную копию: для файловой базы — копию файла 1Cv8.1CD или выгрузку в dt, для клиент-серверной — бэкап средствами СУБД. Без копии любое принудительное прерывание превращается в лотерею.

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

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

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

Можно ли остановить тестирование и исправление кнопкой в конфигураторе?

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

Повредится ли база, если снять задачу конфигуратора?

Если выполнялась только проверка без изменения данных — почти наверняка нет. Если были включены исправление, реиндексация или сжатие, риск повреждения реален, особенно при прерывании в момент активной записи. После такой остановки обязательно проверьте целостность базы до начала работы.

Конфигуратор «не отвечает» уже несколько часов — это зависание?

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

Что делать, если после прерывания база не открывается?

Для файловой базы сначала запустите утилиту chdbfl.exe из каталога платформы с включённым исправлением ошибок. Если она не помогла или ошибки остались, восстанавливайте базу из резервной копии. Для клиент-серверной базы используйте восстановление из бэкапа СУБД.

Как ускорить тестирование, чтобы не пришлось его прерывать?

Запускайте операцию в монопольном режиме без пользователей, разбивайте её на отдельные этапы, обеспечьте достаточно свободного места на диске и достаточный объём оперативной памяти. Для клиент-серверных баз часть проверок целесообразно выполнять средствами СУБД, которые работают быстрее.