Зависло «Тестирование и исправление» в 1С: прерываем без потери базы
Содержание
Остановить «Тестирование и исправление» можно двумя способами: нажать кнопку прерывания в окне процесса, а если окно не отвечает, завершить сеанс Конфигуратора. В файловой базе это процесс 1cv8.exe в диспетчере задач, в клиент-серверной — сеанс в консоли кластера. Прерывать процесс на этапе реструктуризации или сжатия таблиц опасно: база может остаться повреждённой.
Сначала определите, завис ли процесс на самом деле. Проверка большой базы нередко идёт часами, а индикатор при этом стоит на месте. Ниже — как отличить зависание от долгой работы, как остановить процесс в каждом режиме и что делать с базой после обрыва.
Завис процесс или просто работает долго
Не убивайте сеанс по первому подозрению. Тестирование базы на 50 ГБ спокойно занимает 3-6 часов, а на медленном диске и дольше. Окно при этом может не обновляться по несколько минут.
Признаки того, что процесс жив:
- 📈 растёт нагрузка на диск: в диспетчере задач или мониторе ресурсов
1cv8.exeчитает и пишет данные; - 🔄 меняется размер файла
1Cv8.1CD(для файловой базы) или идёт активность в СУБД; - 🖱 окно перерисовывается, когда вы его перетаскиваете или сворачиваете и разворачиваете.
Признаки настоящего зависания:
- ⛔ нагрузка на диск и процессор нулевая уже минут 20-30;
- ⛔ в диспетчере задач у процесса статус «Не отвечает» и он не реагирует на перетаскивание окна;
- ⛔ в клиент-серверном режиме сеанс на сервере есть, а запросы к СУБД не выполняются (в мониторе СУБД нет активных запросов от этого сеанса).
Хорошая привычка: перед запуском проверки запомните время старта и размер базы. Тогда через час вы сможете оценить, идёт ли процесс вообще.
Если есть сомнение, подождите ещё час-два. Потерянное время дешевле восстановления из копии.
Что остановка делает с базой
Режим «Тестирование и исправление» открывается из Конфигуратора: Администрирование → Тестирование и исправление. В диалоге вы отмечаете, что проверять: логическую целостность, ссылочную целостность, пересчёт итогов, реиндексацию, сжатие таблиц, реструктуризацию. Для запуска нужен монопольный доступ к базе.
Риск прерывания зависит от того, что делал процесс в этот момент.
| Этап | Меняет данные | Риск при обрыве |
|---|---|---|
| Проверка логической целостности | нет | низкий |
| Проверка ссылочной целостности (без исправления) | нет | низкий |
| Пересчёт итогов | да, служебные таблицы | средний, итоги можно пересчитать повторно |
| Реиндексация таблиц | да | средний или высокий |
| Сжатие таблиц | да | высокий |
| Реструктуризация таблиц | да | высокий |
Если вы запускали режим «Только тестирование», база не изменялась, и остановка безопасна. Если выбрано «Тестирование и исправление», данные могут перезаписываться. Тут нужен бэкап.
Прежде чем прервать процесс, предупредите всех, кто может работать в базе. В клиент-серверном режиме завершение рабочего процесса или сеанса обрывает работу других пользователей этого сервера. Делайте это в нерабочее время или после согласования.
Как остановить процесс в файловой базе
В файловом варианте всё происходит на вашем компьютере или на сетевой папке. Идите от мягкого способа к жёсткому.
Способ 1. Кнопка прерывания в окне
- Найдите окно с ходом проверки. Оно может быть свёрнуто на панели задач.
- Нажмите кнопку прерывания процесса и дождитесь реакции. Платформа должна закончить текущую операцию и корректно остановиться. Это занимает от нескольких секунд до нескольких минут.
- Если окно не отвечает 5-10 минут, переходите к способу 2.
Способ 2. Закрыть Конфигуратор
Закройте окно Конфигуратора обычным способом (крестик). Платформа спросит подтверждение и попробует завершить сеанс. Подождите несколько минут: ей нужно закончить запись.
Способ 3. Завершить процесс в диспетчере задач
- Откройте диспетчер задач (
Ctrl+Shift+Esc). - Найдите процесс
1cv8.exe. Если открыто несколько сеансов, ориентируйтесь на заголовок окна и на время запуска. - Выберите «Снять задачу» и подтвердите.
Это последняя мера. Процесс просто обрывается, и записи в файл базы могут остаться неполными.
Если на компьютере открыта другая база в Конфигураторе или в клиенте, не снимайте все процессы 1cv8.exe подряд. Иначе потеряете несохранённую работу в соседних окнах.
После остановки проверьте, что в каталоге базы не осталось файла блокировки 1Cv8.cdn, а процессы 1cv8.exe действительно исчезли из списка. Если файл остался и никто не работает
в базе, его можно удалить вручную, но только когда вы убедились, что ни один сеанс не держит базу.
Как остановить процесс в клиент-серверном варианте
Здесь процесс разделён на две части: клиентский сеанс Конфигуратора и работа на сервере 1С с СУБД. Если закрыть только окно, серверная часть иногда продолжает работать.
Шаг 1. Закрыть сеанс Конфигуратора
Сначала попробуйте остановить процесс там же, где запустили: кнопка прерывания, затем закрытие окна. Если Конфигуратор запущен на другом компьютере, зайдите туда или завершите задачу удалённо.
Шаг 2. Завершить сеанс в консоли кластера
Откройте консоль администрирования серверов 1С:Предприятия:
- Раскройте нужный кластер и перейдите к информационной базе.
- Откройте раздел «Сеансы».
- Найдите сеанс с приложением «Конфигуратор» (колонка с названием приложения). Ориентируйтесь на пользователя и время начала.
- Вызовите контекстное меню и выберите «Удалить» (завершить сеанс).
Консоль в таком случае посылает команду серверу, и он завершает сеанс. Проверьте, что он пропал из списка. Когда список пуст, а база всё ещё помечена как занятая, посмотрите соединения в соседнем разделе консоли: иногда зависает именно соединение, а не сеанс.
Из командной строки можно посмотреть сеансы
утилитой rac, например rac session list. Подробности по параметрам и подключению к агенту кластера смотрите в справке rac help, не подставляйте команды наугад.
Шаг 3. Проверить запросы на стороне СУБД
Серверная часть тестирования выполняет тяжёлые операции в СУБД: реиндексацию, пересчёт итогов, реструктуризацию. Даже после завершения сеанса СУБД может продолжать откат длинной транзакции.
Не перезапускайте службу СУБД и не убивайте процесс сервера, пока идёт откат. Откат тоже занимает время, иногда столько же, сколько сама операция. Проверьте в средствах мониторинга вашей СУБД, остались ли активные запросы от этого сеанса, и дождитесь их завершения.
Перезапуск службы агента сервера 1С или рабочего процесса оборвёт сеансы всех пользователей этого сервера. Делайте это только вне рабочего времени.
Что проверить после прерывания
Остановить процесс мало. Нужно убедиться, что база открывается и данные целы.
Порядок такой:
- Убедитесь, что нет открытых сеансов. В файловом режиме проверьте диспетчер задач, в клиент-серверном — список сеансов в консоли.
- Откройте базу в Конфигураторе. Если она не открывается или выдаёт ошибку чтения таблиц, дальше пробовать смысла нет, вам нужна копия.
- Запустите «Только тестирование». Выберите проверку логической и ссылочной целостности без исправления. Если ошибок нет, база цела.
- Пересчитайте итоги. Если тестирование оборвалось на этом этапе, итоги регистров могут быть неверными. Запустите пересчёт отдельно, на нужном регистре.
- Запустите штатный клиент и проверьте данные. Откройте несколько последних документов, оборотно-сальдовую ведомость, остатки по складу. Сверьте контрольные цифры с теми, что были до проверки.
Для файловой базы есть дополнительный инструмент: утилита chdbfl.exe в каталоге bin установленной платформы. Она проверяет и исправляет физическую структуру файла 1Cv8.1CD и умеет восстанавливать его после сбоя. Перед её запуском сделайте копию файла, потому что она тоже изменяет базу.
Для клиент-серверной базы подобной утилиты нет. Восстановление идёт средствами СУБД и самой платформы либо из резервной копии.
Когда без резервной копии не обойтись
Откатывайтесь на копию, если:
- 🔴 база не открывается ни в Конфигураторе, ни в клиенте;
- 🔴 «Только тестирование» показывает много ошибок в разных таблицах;
- 🔴 обрыв произошёл на реструктуризации или сжатии таблиц;
- 🔴
chdbfl.exeне справился или после него база снова ругается; - 🔴 после проверки данные расходятся с контрольными цифрами.
Как выбрать копию:
- Возьмите самую свежую копию, сделанную до запуска тестирования. Выгрузку в
.dtи копию файла1Cv8.1CDсделайте заранее, пока база была цела. - Разверните её в новую базу, не поверх повреждённой.
- Сравните разницу: что вводили между копией и обрывом. Эти документы придётся внести заново.
- Старую базу сохраните: она пригодится, чтобы вытащить свежие документы.
Если копия старая, не торопитесь её разворачивать. Иногда выгоднее сначала попытаться восстановить повреждённую базу утилитой или средствами СУБД, а потом сверить с копией.
Мини-кейс: ночная проверка, которая не закончилась к утру
Типичная картина: бухгалтер запустил проверку с реиндексацией и сжатием в шесть вечера, утром окно всё ещё крутится. Диск при этом загружен, файл базы изменяется.
Правильно подождать. Если в 9:00 нужна работа, а процесс идёт на этапе сжатия, оборвать его хуже, чем потерять утро. Когда же диск молчит уже полчаса, вариант один: аккуратно завершить сеанс, проверить базу режимом «Только тестирование» и при необходимости поднять копию, сделанную перед запуском.
Как не допустить зависания в следующий раз
Большая часть зависаний решается подготовкой, а не героическими мерами.
Несколько приёмов, которые реально помогают:
- 💾 Свободное место. Для реструктуризации и сжатия нужен запас, ориентировочно сопоставимый с размером базы. Если места мало, процесс может встать посередине.
- 🧩 Разбивайте этапы. Не отмечайте все галочки сразу. Сначала проверка, потом пересчёт итогов, потом реиндексация. Так проще понять, на чём застряло, и меньше потерь при обрыве.
- 🕐 Окно обслуживания. Выбирайте ночь или выходные. Для базы на 20-30 ГБ закладывайте не меньше 3-4 часов.
- 🛡 Антивирус. Исключите каталог базы и каталог платформы из постоянной проверки. Антивирус на каждую запись замедляет процесс в разы и порой выглядит как зависание.
- 🌐 Сетевой диск. Файловую базу не проверяйте по сети. Скопируйте её на локальный диск, проверьте там и верните обратно. Обрыв соединения при тестировании по сети повреждает базу чаще всего.
- 🖥 Питание. Для сервера и рабочего места, где идёт длинная операция, нужен источник бесперебойного питания.
Если база регулярно требует тестирования, ищите причину: сбои питания, нехватку места, некорректное завершение работы пользователей. Периодические проверки не заменяют борьбу с первопричиной.