Обновление крупных конфигураций, таких как 1С:Комплексная автоматизация 2 или 1С:ERP, часто сопровождается длительным выполнением процедур отложенного обновления. Эти процедуры могут выполняться часы или даже сутки, блокируя работу пользователей или вызывая вопросы о корректности процесса. В этой статье мы подробно разберем, как устроено отложенное обновление, можно ли его ускорить простым изменением расписания и что делать, если обработчики «зависли».
Для начала проанализируем ситуацию: почему процедуры обновления могут длиться так долго? В современных конфигурациях на базе Библиотеки стандартных подсистем (БСП) большинство тяжелых операций по трансформации данных вынесено в «отложенный» режим. Это позволяет пользователям начать работу в базе сразу после обновления метаданных, в то время как данные (документы, справочники, регистры) будут постепенно приводиться к новому формату в фоновом режиме.
Рассмотрим механизм работы регламентного задания ОтложенноеОбновлениеИБ. Оно запускает обработчики, которые работают порционно. Например, за один цикл задание может обработать 500 документов, после чего оно завершается, а через некоторое время, согласно расписанию, запускается снова. Если в вашей базе миллионы записей, а расписание настроено на «раз в час», процесс растянется на недели.
Выясним, поможет ли изменение расписания с «раз в час» на «раз в минуту». Ответ зависит от поведения конкретного обработчика:
Рекомендуем устанавливать расписание для ОтложенноеОбновлениеИБ следующим образом: повторять каждые 60 секунд, пауза между повторами — 10-20 секунд. Это обеспечит максимально плотный график обработки данных без лишних простоев.
Проанализируем ситуацию, когда процедуры «висят». Как понять, делают ли они что-то или просто зациклились? Для этого в системе существует специальный технический объект — план обмена ОбновлениеИнформационнойБазы. Рассмотрим, как его использовать:
Каждый объект, требующий обновления, регистрируется в этом плане обмена. Вы можете открыть обработку «Регистрация изменений для обмена» и выбрать этот план. Если вы видите, что количество зарегистрированных объектов (например, документов ЗаказКлиента) постепенно уменьшается — процесс идет, нужно просто ждать. Если же число не меняется в течение долгого времени — обработчик либо столкнулся с ошибкой, либо зациклился.
Разберем, что делать, если вы обнаружили проблемные объекты. Если вы уверены, что данные по конкретному объекту обновлять не нужно (например, старые закрытые периоды), можно вручную отменить регистрацию этих объектов в плане обмена. После этого регламентное задание посчитает, что работа выполнена, и перейдет к следующему шагу.
Если серверные ресурсы позволяют, мы можем значительно ускорить процесс, включив многопоточное обновление. В современных версиях конфигураций (КА 2, ERP) это делается в разделе Обслуживание — Обновление программы — Результаты обновления. Там можно найти гиперссылку «Настроить».
Увеличив количество потоков (например, до 4 или 8), вы позволите системе запускать несколько фоновых заданий одновременно. Каждое задание будет обрабатывать свою порцию данных из плана обмена ОбновлениеИнформационнойБазы, что дает практически линейный прирост скорости на многоядерных серверах.
Иногда типовые механизмы дают сбой, и нам требуется запустить процесс «вручную». Рассмотрим пример кода, который можно выполнить в консоли кода или во внешней обработке для инициации процесса обновления без ожидания регламентного задания:
// Принудительный запуск отложенных обработчиков
Справочники.ОбновлениеИнформационнойБазы.ВыполнитьОтложенноеОбновлениеСейчас();
Этот метод заставит систему немедленно начать выполнение процедур в текущем сеансе (или запустить фоновое задание принудительно). Будьте осторожны: выполнение в текущем сеансе может привести к блокировке интерфейса до окончания обработки порции данных.
Разберем специфический случай, упомянутый в практике. Часто в КА 2 процедуры «висят» на справочнике Назначения. Это происходит потому, что система пытается пересчитать обособленный учет товаров, даже если работа с заказами отключена. Если вы столкнулись с такой ситуацией, проверьте следующее:
tempdb переполнен или лог транзакций LDF разросся до огромных размеров, запись новых элементов справочника Назначения будет крайне медленной.Simple (Простой) на уровне SQL-сервера, чтобы исключить тормоза из-за логирования каждой транзакции обновления.Если процедура выполняется 12 часов и прогресса в плане обмена нет, скорее всего, произошло зацикливание. В этом случае рекомендуем следующий алгоритм действий:
Для программной отметки используется работа с регистром сведений ОчередьОбработчиковОбновления. Рассмотрим пример (использовать с осторожностью!):
Менеджер = РегистрыСведений.ОчередьОбработчиковОбновления.СоздатьМенеджерЗаписи();
Менеджер.ИмяОбработчика = "ИмяЗависшегоОбработчика";
Менеджер.Прочитать();
Если Менеджер.Выбран() Тогда
Менеджер.Статус = Перечисления.СтатусыОбработчиковОбновления.Выполнен;
Менеджер.Записать();
КонецЕсли;
Подводя итог, отметим, что для ускорения обновления в 90% случаев помогает установка ежеминутного интервала запуска регламентного задания и включение многопоточности в настройках обновления. Изменение расписания с часа до минуты — это правильный шаг, который позволит системе не простаивать между порциями данных. Однако всегда держите под контролем план обмена ОбновлениеИнформационнойБазы, чтобы вовремя заметить реальное зависание системы.