Что делать, если обработка свертки информационной базы 1С заблокирована после сбоя?

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

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

Понимание механизма блокировки

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

Решение проблемы: очистка параметров свертки

Чтобы разблокировать доступ, нам необходимо принудительно очистить значение этой константы. Это можно сделать через консоль кода или создав внешнюю обработку.

Разберем способ с созданием внешней обработки по шагам:

1. Откройте «Конфигуратор» в режиме разработки.
2. Создайте новую внешнюю обработку (Файл -> Новый -> Внешняя обработка).
3. Добавьте на форму кнопку, например, «Разблокировать свертку».
4. В модуле команды или обработчике нажатия кнопки пропишите следующий код:

// Очищаем параметры свертки для возможности повторного запуска
Константы.ПараметрыСверткиИБ.Установить(Неопределено);
// Дополнительно можно закрыть форму, если она была открыта
// Закрыть();

После выполнения этого кода константа ПараметрыСверткиИБ сбросится в значение Неопределено. Теперь система будет воспринимать открытие обработки как самый первый запуск, и доступ к функционалу будет восстановлен.

Почему свертка может падать повторно?

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

Рассмотрим основные причины повторных ошибок:

• Нехватка системных ресурсов: На больших базах (более 100 ГБ) свертка создает колоссальную нагрузку на tempdb и лог транзакций SQL-сервера. Убедитесь, что на диске достаточно места для роста файлов базы данных.
• Блокировки: Если в базе одновременно с процессом свертки работают другие пользователи или выполняются регламентные задания, вероятность конфликта блокировок возрастает. На время свертки рекомендуется переводить базу в монопольный режим.
• Битые ссылки и некорректные регистры: Если в базе накопились логические ошибки, свертка не сможет корректно сформировать остатки. Рекомендуется перед сверткой выполнить Тестирование и исправление информационной базы с установленными флагами проверки ссылочной целостности и пересчета итогов.

Стратегия безопасной свертки

Чтобы избежать «первоклассной камасутры» с восстановлением данных, рекомендуем придерживаться следующей тактики при работе с крупными базами:

1. Сначала тестовый полигон: Никогда не проводите свертку напрямую в рабочей базе. Сделайте копию базы, протестируйте сценарий на ней. Если все проходит успешно, только тогда планируйте работы на рабочей базе.
2. Миграция через обмен данными: Если база слишком «старая» (накопила много ошибок с 2009 года), свертка может оказаться невозможной. В таких случаях надежнее создать «чистую» базу, перенести в нее справочники и начальные остатки, а текущие документы донести обменом через ПланыОбмена или РИБ.
3. Использование внешних обработок: Если вы выполняете свертку через Обработку свертки, сохраните ее как внешнюю. Это позволит вам гибко настраивать параметры создания документов ввода остатков (например, создавать их непроведенными или с определенными комментариями), что упростит последующий анализ результатов.
4. Автоматизация контроля: При повторных запусках следите, чтобы старые документы ввода остатков (созданные предыдущей попыткой) были корректно удалены или перезаписаны. Проверьте, чтобы в конфигурации не было задвоения движений по регистрам.

Помните: техническая разблокировка — это лишь первый шаг. Внимательно проанализируйте технологический журнал (события EXCP и DBMSSQL), чтобы найти реальную причину сбоя, и только после устранения этой причины запускайте процесс повторно.