Администрирование · 11 мин
Как заблокировать фоновые задания в 1С при обновлении
Как заблокировать фоновые и регламентные задания в 1С перед обновлением: консоль заданий, код блокировки, проверка результата, типичные ошибки и FAQ.
При обновлении конфигурации 1С активные фоновые и регламентные задания — один из главных источников проблем. Задание, запустившееся в момент реструктуризации базы, может обратиться к ещё не обновлённым объектам метаданных, вызвать ошибки, конфликты блокировок или даже порчу данных. Поэтому стандартная практика — полностью заблокировать выполнение заданий до начала обновления и снять блокировку только после успешного завершения.
Способ блокировки зависит от режима работы базы: файловый или клиент-серверный. В файловом варианте задания выполняются отдельным сеансом, который можно просто завершить и не запускать. В клиент-серверном варианте заданиями управляет кластер серверов 1С, и там есть штатный механизм блокировки — как через консоль кластера, так и программно из кода конфигурации.
Ниже разобраны оба сценария, программный способ через методы встроенного языка, проверка результата и типичные ошибки, из-за которых задания всё равно запускаются во время обновления.
Зачем блокировать задания перед обновлением
Обновление конфигурации базы данных часто включает реструктуризацию: изменение таблиц, добавление реквизитов, перенос данных. Если в этот момент выполняется регламентное задание — например, обмен с сайтом, загрузка курсов валют или расчёт итогов — оно работает со старой структурой данных и может завершиться ошибкой или записать некорректные значения.
Вторая причина — монопольный режим. Многие этапы обновления требуют монопольного доступа к базе. Активное фоновое задание удерживает соединение и не даёт установить монопольный режим, из-за чего обновление прерывается с ошибкой «Конфликт блокировок при выполнении транзакции» или невозможностью установить исключительный доступ.
Третья причина — обработчики обновления. После реструктуризации запускаются процедуры переноса данных, которые нередко сами выполняются как фоновые задания (отложенное обновление). Если в этот момент параллельно работают прикладные регламентные задания, они могут обратиться к данным, которые ещё не приведены к новой версии, и завершиться аварийно.
Блокировка в клиент-серверном варианте через консоль кластера
Самый надёжный способ для серверной базы — штатная настройка в консоли кластера серверов 1С. Блокировка действует на уровне кластера, поэтому задания не запустятся независимо от того, что происходит в сеансах пользователей.
Порядок действий: откройте консоль управления сервером 1С (оснастка «Администрирование серверов 1С Предприятия»), найдите нужную информационную базу в списке, откройте её свойства. Установите флажок «Блокировка регламентных заданий включена» и при необходимости задайте сообщение о блокировке сеансов. Сохраните изменения.
Блокировка начинает действовать сразу: уже выполняющиеся задания завершат текущую итерацию, новые запускаться не будут. Учтите, что задание, которое уже работает, консоль не прерывает — его нужно либо дождаться, либо завершить принудительно через список сеансов.
- 1Откройте оснастку администрирования серверов 1С и найдите нужную базу
- 2Откройте свойства информационной базы
- 3Установите флажок «Блокировка регламентных заданий включена»
- 4Проверьте список сеансов: дождитесь завершения или завершите активные фоновые сеансы
- 5Выполните обновление конфигурации
- 6Снимите флажок блокировки и убедитесь, что задания снова выполняются
Программная блокировка через встроенный язык
Если конфигурация построена на Библиотеке стандартных подсистем (БСП), блокировку можно установить прямо из кода или через внешнюю обработку. Для этого используется менеджер регламентных заданий.
Базовый вызов выглядит так:
УстановитьБлокировкуРегламентныхЗаданий(Истина);Проверить текущее состояние можно функцией:
Если РегламентныеЗаданияСервер.РегламентныеЗаданияЗаблокированы() Тогда
Сообщить("Задания заблокированы");
КонецЕсли;
В типовых конфигурациях на БСП блокировка хранится в константе и применяется при старте сеанса. Это удобно для сценариев автоматического обновления через пакетный запуск конфигуратора: сначала выполняется обработка, устанавливающая блокировку, затем запускается обновление, после него — обработка снятия блокировки.
// Установить блокировку
УстановитьБлокировкуРегламентныхЗаданий(Истина);
// Выполнить обновление...
// Снять блокировку
УстановитьБлокировкуРегламентныхЗаданий(Ложь);Файловый вариант: как остановить выполнение заданий
В файловой базе нет кластера серверов, и регламентные задания выполняются либо в отдельном сеансе, запущенном с ключом выполнения заданий, либо в сеансе пользователя, если настроен соответствующий режим. Поэтому блокировка сводится к тому, чтобы не допустить запуск такого сеанса.
Практический порядок: найдите сеанс, который выполняет фоновые задания (в списке активных пользователей он обычно виден как отдельное подключение), завершите его. После этого убедитесь, что планировщик Windows или скрипт автозапуска не поднимет этот сеанс заново — временно отключите соответствующую задачу планировщика. Затем запускайте обновление в монопольном режиме.
В типовых конфигурациях на БСП для файлового варианта также работает константа блокировки регламентных заданий: если она установлена, сеанс выполнения заданий стартует, но задания не выполняет. Однако надёжнее комбинировать оба подхода — и блокировку, и остановку сеанса.
Сравнение вариантов блокировки
Подходит для серверных баз, действует централизованно и надёжно; требует доступа администратора кластера
Удобна для автоматизации и скриптов обновления; работает только в конфигурациях с соответствующей подсистемой
Единственный вариант для файловой базы без БСП; не защищает от повторного автозапуска сеанса планировщиком
Отключает задания на уровне публикации или запуска; требует перезапуска и аккуратности с настройками
Отложенное обновление и фоновые обработчики
В современных типовых конфигурациях после основного обновления запускаются отложенные обработчики, которые выполняются как фоновые задания. Это создаёт нюанс: полностью заблокированные задания могут помешать завершению отложенного обновления.
Поэтому правильная последовательность выглядит так: блокируете задания, выполняете обновление конфигурации и монопольные обработчики, затем снимаете блокировку и даёте отложенным обработчикам отработать. До завершения отложенного обновления не рекомендуется пускать пользователей в базу и запускать прикладные обмены.
Контролировать ход отложенного обновления можно в типовых конфигурациях через раздел «Результаты обновления приложения» (в старших версиях БСП — «Результаты обновления программы»). Там видно, какие обработчики выполнены, какие ожидают, а какие завершились с ошибкой.
Проверка результата и типичные ошибки
После установки блокировки убедитесь, что она реально работает. Признак корректной блокировки — в списке сеансов кластера нет активных фоновых заданий, а в журнале регистрации не появляются новые записи о запуске регламентных заданий. Если задания продолжают стартовать, чаще всего причина в том, что база опубликована в нескольких кластерах или блокировка установлена не для той базы.
После снятия блокировки проверьте обратное: задания должны возобновить выполнение по расписанию. Откройте консоль заданий (в типовых — «Регламентные и фоновые задания» в разделе администрирования) и убедитесь, что у ключевых заданий обновилось время последнего выполнения и нет ошибок.
Как проверить результат
Нет активных фоновых сеансов во время обновления
Фоновые сеансы появляются снова — блокировка не сработала
Нет ошибок запуска регламентных заданий в период обновления
Ошибки обращения к объектам метаданных — задание работало во время реструктуризации
Задания выполняются по расписанию, дата последнего запуска свежая
Задания не стартуют — блокировка не снята или константа осталась включённой
Все отложенные обработчики завершены успешно
Есть обработчики с ошибками — их нужно перезапустить после разбора причины
FAQ
Можно ли обновлять конфигурацию, не блокируя регламентные задания?
Технически иногда можно, если обновление не требует монопольного режима и не меняет структуру данных. Но это риск: любое задание, запустившееся в момент реструктуризации, может вызвать конфликт или ошибку. Стандартная безопасная практика — блокировать задания всегда.
Что произойдёт с заданием, которое выполняется в момент установки блокировки?
Блокировка не прерывает уже запущенное задание — оно доработает до конца. Прерываются только новые запуски. Если задание длительное и мешает обновлению, его нужно дождаться или завершить принудительно через список сеансов, понимая риск незавершённой транзакции.
Как автоматизировать блокировку при обновлении через скрипты?
Используйте пакетный запуск конфигуратора с вызовом внешней обработки, которая выполняет УстановитьБлокировкуРегламентныхЗаданий(Истина) до обновления и снимает блокировку после. В серверном варианте альтернатива — управление свойствами базы через RAC (утилиту администрирования кластера).
Задания не запускаются после обновления, хотя блокировку сняли. В чём причина?
Проверьте три места: флажок блокировки в свойствах базы в консоли кластера, константу блокировки в настройках конфигурации (раздел администрирования, «Обслуживание») и состояние самих заданий в консоли заданий — задание могло быть отключено вручную ранее.
Нужно ли блокировать задания при обновлении расширений конфигурации?
Зависит от расширения. Если оно меняет роли, добавляет собственные регламентные задания или затрагивает данные, блокировка желательна. Простое обновление расширения с формами обычно не требует остановки заданий, но при сомнениях безопаснее заблокировать.
Мешают ли заблокированные задания отложенному обновлению?
Да, отложенные обработчики БСП выполняются как фоновые задания, поэтому при полной блокировке они не стартуют. Снимайте блокировку сразу после основного обновления и дождитесь завершения отложенных обработчиков, прежде чем открывать базу пользователям.
Что важно запомнить
Перед обновлением заблокируйте регламентные задания: в серверной базе — через консоль кластера или кодом, в файловой — завершением сеанса заданий и отключением автозапуска. Дождитесь завершения активных заданий, выполните обновление, снимите блокировку и проверьте, что задания и отложенные обработчики отработали без ошибок. Не забудьте снять блокировку — это самая частая причина «молчащих» обменов после обновления.