Отложенное обновление ИБ 1С: что это такое и как с ним работать

Отложенное обновление информационной базы 1С — это механизм, при котором часть обработчиков обновления данных выполняется не сразу при запуске новой версии конфигурации, а позже: фоновым заданием по расписанию или по инициативе пользователей. Такой подход позволяет быстро запустить базу после обновления и не заставлять всех сотрудников ждать, пока завершится длительная обработка больших объёмов данных.

Механизм встроен в Библиотеку стандартных подсистем (БСП), на которой построены типовые конфигурации: «1С:Бухгалтерия», «1С:Зарплата и управление персоналом», «1С:Управление торговлей», «1С:ERP» и другие. Администратору и разработчику важно понимать, как отложенные обработчики запускаются, почему они могут зависнуть и что делать, если обновление «застряло» на определённом проценте.

Что такое отложенное обновление и чем оно отличается от обычного

При обновлении конфигурации 1С выполняет два типа операций. Первый — изменение структуры базы данных (добавление реквизитов, таблиц, индексов) — выполняется всегда сразу, в монопольном режиме. Второй — обработчики обновления данных: перенос значений, заполнение новых реквизитов, пересчёт итогов. Именно часть этих обработчиков может быть отложена.

Обычные (оперативные, монопольные) обработчики выполняются до того, как пользователи войдут в систему. Отложенные стартуют уже после: специальное регламентное задание «Отложенное обновление ИБ» запускает их последовательно, по очереди приоритетов. Благодаря этому обновление крупной базы, которое монопольно заняло бы несколько часов, распределяется на фоновую работу.

Компромисс очевиден: до завершения всех отложенных обработчиков часть функциональности работает ограниченно. Например, новый отчёт может показывать неполные данные, а документы — открываться с предупреждением, что их данные ещё не обработаны.

Зачем разработчики выносят обработчики в отложенные

Главная причина — простой в работе пользователей. Если обработчик обходит миллионы записей регистра или перепроводит документы, в монопольном режиме это может занять часы. Для крупной организации такое окно недопустимо, поэтому тяжёлые операции переносятся в фон.

Вторая причина — поэтапность. Некоторые данные нужны не сразу: исторические архивы, редко используемые справочники. Их обработку разумно выполнить ночью, когда нагрузка минимальна. Третья причина — возможность обновлять данные порциями: отложенный обработчик обычно умеет работать итеративно, обрабатывая пачку записей за один запуск и сохраняя прогресс.

Как выполняется отложенное обновление: механика процесса

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

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

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

Параллельно работает механизм «по требованию»: если пользователь открывает объект, данные которого ещё не обработаны, система может выполнить обработку этого конкретного объекта на месте. Это снижает заметность фонового обновления для пользователей.

Почему отложенное обновление зависает и что с этим делать

Самая частая ситуация — прогресс «застыл» на одном значении часами. Причины бывают разные: обработчик упал с ошибкой и зациклился на проблемной записи, фоновое задание заблокировано, сервер перезагружался, либо объём данных действительно велик и обработка просто идёт медленно.

Первое действие — открыть «Результаты обновления программы» и найти обработчик со статусом «Ошибка» или бесконечно «выполняющийся». Далее смотрят журнал регистрации: там видно текст исключения. Типичные варианты — конфликт блокировок с работающими пользователями, нехватка места на диске, ошибка в коде обработчика на нестандартных данных.

Если обработчик завис из-за блокировок, помогает запуск обновления в период минимальной активности пользователей или временное ограничение сеансов. Если причина — ошибка в данных, проблемную запись иногда удаётся исправить вручную, после чего обработчик продолжит работу со следующего запуска.

Как ускорить или принудительно завершить отложенное обновление

В типовых конфигурациях в форме «Результаты обновления программы» доступна команда принудительного запуска: обновление можно выполнить «сейчас», не дожидаясь расписания. Для клиент-серверных баз убедитесь, что на сервере разрешены фоновые задания и не установлена блокировка регламентных заданий.

Для разработчика есть программный интерфейс БСП: процедуры модуля ОбновлениеИнформационнойБазы позволяют запустить выполнение отложенных обработчиков из кода, например из внешней обработки или консоли кода.

// Принудительный запуск отложенного обновления (БСП)
Результат = ОбновлениеИнформационнойБазы.ВыполнитьОтложенноеОбновлениеСейчас();

Если база файловая, фоновое задание выполняется в сеансе запустившего его пользователя. В этом случае имеет смысл выделить отдельный сеанс (например, запущенный специально для обновления толстый клиент) и не закрывать его до завершения обработки.

Отложенное обновление для разработчика: как писать свои обработчики

При доработке конфигурации собственный отложенный обработчик регистрируется в переопределяемом модуле обновления: ему задаётся версия, режим выполнения «Отложенно», очередь и процедура-обработчик. Ключевое требование — идемпотентность: обработчик должен корректно работать при повторном запуске и обрабатывать данные порциями.

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

Контроль результата и завершение обновления

Обновление считается полностью завершённым только когда все отложенные обработчики имеют статус «Выполнено». До этого момента не рекомендуется выполнять регламентные операции, зависящие от новых данных: закрытие месяца, формирование регламентированной отчётности, свёртку базы.

После завершения имеет смысл снять контрольные показатели: количество документов, обороты по ключевым регистрам — и сравнить их со значениями до обновления. Расхождения без объяснимых причин — повод детально проверить журнал регистрации и список выполненных обработчиков.

Частые вопросы