При обновлении крупных информационных баз 1С:ERP, особенно при переходе с релизов ветки 2.5.6 на 2.5.7 и выше, специалисты часто сталкиваются с критической остановкой процесса. Процедура отложенного обновления РегистрыСведений.РеестрДокументов.ОбработатьДанныеДляПереходаНаНовуюВерсию завершается аварией с диагностическим сообщением: «Превышено допустимое количество запусков процедуры обновления. Выполнение прервано для предотвращения зацикливания механизма обработки данных». В этой статье мы подробно разберем, почему возникает эта ситуация, как диагностировать «зависшие» данные и какие методы позволяют успешно завершить обновление.
Для начала проанализируем внутреннюю логику работы Библиотеки стандартных подсистем (БСП), которая управляет процессом обновления. Ошибка «Превышено количество запусков» — это защитный механизм. Когда процедура отложенного обновления запускается, она должна обработать определенную порцию данных (например, 1000 документов) и зафиксировать прогресс. Если система видит, что процедура вызывалась несколько раз подряд (по умолчанию лимит составляет 5 попыток), но количество необработанных объектов не уменьшается, она делает вывод, что алгоритм попал в бесконечный цикл на одной и той же записи.
В релизе ERP 2.5.7 произошла глобальная переработка регистра РеестрДокументов. Изменился состав индексируемых полей и логика формирования записей для ускорения работы динамических списков. Это привело к тому, что обработчик обновления вынужден пересчитывать данные практически по всем документам в базе. Основными факторами возникновения ошибки являются:
Прежде чем приступать к радикальным мерам, рассмотрим, как найти конкретную запись, на которой «спотыкается» система. Если стандартная отладка не срабатывает, проверим настройки сервера. Убедимся, что на сервере 1С разрешена отладка (параметр -debug), иначе точки останова в фоновых заданиях не будут активны.
Проанализируем состояние базы с помощью консоли запросов. Нам необходимо проверить два ключевых объекта: сам регистр реестра и очередь обновления. Выполним следующий запрос, чтобы проверить наличие записей с битыми ссылками в регистре РеестрДокументов:
ВЫБРАТЬ
Реестр.Ссылка КАК ПроблемнаяСсылка
ИЗ
РегистрСведений.РеестрДокументов КАК Реестр
ГДЕ
Реестр.Ссылка.Номер ЕСТЬ NULL
Если запрос возвращает строки, значит, в регистре присутствуют ссылки на несуществующие объекты. Именно они чаще всего становятся причиной зацикливания, так как обработчик не может прочитать метаданные документа для его повторной регистрации. Для этой задачи есть диагностика регистров и удаление битых ссылок.
Рассмотрим еще один эффективный метод поиска проблемных данных с помощью типовой обработки «Регистрация изменений для обмена данными» (ее можно найти в составе инструментов разработчика или на ИТС). Несмотря на то, что это инструмент для РИБ, он позволяет наглядно увидеть все объекты, зарегистрированные в различных узлах, включая технические очереди обновления. В этом поможет расширенное управление регистрацией изменений на узлах обмена.
РегистрСведений.РеестрДокументов.Рассмотрим ситуацию, когда количество записей в регистре исчисляется миллионами, и поиск конкретной ошибки занимает слишком много времени. Как показала практика (сообщение №2 в обсуждении), эффективным решением является временная очистка регистра РеестрДокументов. Для очистки базы от проблемных данных есть обработка удаления битых движений и устаревших регистров.
Важно: Перед выполнением этой операции обязательно создайте резервную копию базы данных!
Алгоритм действий следующий:
РеестрДокументов. Это можно сделать программно:
Набор = РегистрыСведений.РеестрДокументов.СоздатьНаборЗаписей();
Набор.Записать();
Если очистка регистра средствами 1С выполняется крайне медленно из-за огромного объема данных, мы можем воспользоваться средствами СУБД. Проанализируем структуру базы данных, найдем таблицу, соответствующую регистру РеестрДокументов, и выполним команду TRUNCATE TABLE. Это мгновенно очистит таблицу без записи в лог транзакций в таких объемах, как это делает 1С.
После очистки таблицы на уровне SQL необходимо:
Иногда зацикливание является ложным и вызвано таймаутами при параллельной работе нескольких потоков. Попробуем ограничить количество потоков обновления до одного. Для этого перейдем в раздел НСИ и администрирование — Обслуживание — Обновление программы — Результаты обновления. В настройках (кнопка «Настроить потоки») установим количество потоков равным «1».
Это позволит:
Мы проанализировали проблему зацикливания процедуры ОбработатьДанныеДляПереходаНаНовуюВерсию и выяснили, что наиболее действенными методами являются поиск битых ссылок и полная очистка регистра перед повторным запуском. В большинстве случаев после того, как регистр очищен, система успешно заполняет его новыми данными в автоматическом режиме при переходе на следующий минорный релиз (например, с 2.5.7.226 на 2.5.7.255 или 2.5.8).
Помните, что архитектурные изменения в Реестре документов в версии 2.5.7 направлены на долгосрочное повышение производительности, и разовое прохождение этой процедуры очистки является необходимым этапом технического обслуживания базы данных.