← На главную
При обновлении крупных конфигураций, таких как 1С:ERP Управление предприятием, администраторы часто сталкиваются с сообщением о том, что обновление выполнено не полностью и часть обработок переведена в отложенный режим. Разберем подробнее, с какой целью разработчики платформы и Библиотеки Стандартных Подсистем (БСП) реализовали этот механизм и как корректно с ним работать.
Смысл и назначение отложенного обновления
Проанализируем суть процесса конвертации данных при смене версии конфигурации. Весь объем процедур обновления разделяется на две ключевые части:
- Критичные процедуры (первая часть): выполняются монопольно при запуске программы под администратором. Без них корректный запуск базы и работа структуры конфигурации невозможны. Они меняют ключевые структуры данных и занимают относительно немного времени.
- Отложенные обработчики (вторая часть): предназначены для длительной обработки и реструктуризации исторических данных (заполнение новых реквизитов, пересчет регистров, конвертация накопительных данных). Эти процедуры вынесены в фоновые задачи, чтобы пользователи могли приступить к работе сразу после завершения монопольного этапа, не дожидаясь окончания всех длинных расчетов.
Таким образом, отложенное обновление внедрено для сокращения времени простоя предприятия во время технологических окон.
Правила обновления на несколько релизов подряд
Выясним, как поступать в ситуации, когда базу требуется обновить последовательно на несколько версий (например, через 3–4 промежуточных релиза). Возникает соблазн накатить все конфигурации подряд и запустить отложенные обработчики только в самом конце.
Делать так категорически не рекомендуется! Разберем причины, почему необходимо полностью завершать отложенное обновление для каждого релиза перед переходом к следующему:
- Зависимость данных: алгоритмы обновления последующих версий конфигурации рассчитывают на то, что структуры и регистры предыдущих версий уже полностью сформированы и заполнены. Если пропустить этап отложенной обработки на промежуточном релизе, обработчики следующего релиза могут обратиться к незаполненным данным, что приведет к логическим ошибкам или сбоям выполнения кода.
- Потеря контекста изменений: при пропуске промежуточных обработчиков система не сможет корректно отследить последовательность конвертации данных из одной структуры в другую.
Рассмотрим правильный алгоритм действий при поэтапном обновлении:
- Обновить конфигурацию базы данных до следующего релиза.
- Запустить режим «1С:Предприятие» и дождаться полного завершения как монопольного, так и отложенного обновления.
- Проверить статус завершения процедур.
- Только после 100% готовности переходить к обновлению на следующий релиз.
Контроль и варианты выполнения отложенного обновления
Посмотрим, где в интерфейсе программы контролируется ход выполнения процедур и какие режимы запуска доступны. В режиме «1С:Предприятие» перейдем в раздел Администрирование — Обслуживание — Результаты обновления программы (или ссылка Результаты обновления и дополнительная обработка данных).
В открывшемся окне отображается текущий статус выполнения каждого обработчика, время начала и прогресс обработки.
Для ускорения и контроля процесса можно использовать следующие возможности:
- Принудительный (запуск вручную): если требуется завершить обновление до запуска пользователей в базу, обработку данных можно запустить вручную прямо из формы статуса обновления. В этом случае процедуры выполнятся монопольно с максимальной скоростью.
- Многопоточная обработка: процедуры БСП поддерживают параллельное выполнение в несколько потоков. В настройках производительности длительных операций можно увеличить количество потоков, что существенно сократит время обработки на мощных серверных мощностях.
Технические нюансы, риски и исправление сбоев
Рассмотрим возможные проблемы, с которыми можно столкнуться при выполнении отложенных процедур:
- Блокировка регламентных заданий: отложенная обработка выполняется регламентным заданием
Отложенное обновление ИБ. Если на уровне консоли кластера серверов или в настройках базы включена блокировка регламентных задач, фоновое обновление не запустится.
- Ограничения файлового режима: в файловых информационных базах фоновые задания не выполняются автоматически в фоновом режиме, если не запущен отдельный сеанс для обработки регламентных задач или процедуры не запущены вручную из интерфейса.
- Конфликты блокировок: если фоновый обработчик изменяет документы или справочники, которые в этот момент активно редактируются пользователем, могут возникать ошибки блокировки транзакций.
- Ошибки и приостановка цепи обработчиков: в случае возникновения критической ошибки в одном из обработчиков выполнение всех зависимых процедур приостанавливается. В этом случае необходимо проанализировать Журнал регистрации, устранить причину сбоя (исправить некорректные данные или применить патч) и воспользоваться функцией перезапуска отложенного обновления для продолжения работы.