Почему не выполняются дополнительные процедуры обновления в клиент-серверной версии 1С и как это исправить?

При обновлении крупных конфигураций на платформе 1С:Предприятие 8.3 (таких как "Зарплата и управление персоналом", "Бухгалтерия предприятия" или "ERP Управление предприятием") администраторы и разработчики часто сталкиваются с ситуацией, когда основное обновление конфигурации завершено, но система сообщает о необходимости выполнения дополнительных процедур обработки данных. В файловом варианте базы данных этот процесс запускается автоматически при первом входе пользователя и завершается достаточно быстро. Однако в клиент-серверном варианте эти процедуры могут "зависать" неделями, ограничивая работу пользователей с необновленными данными.

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

В чем разница запуска обновления в файловом и клиент-серверном режимах?

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

В файловом варианте у платформы нет постоянно работающего сервера приложений и планировщика задач. Поэтому при первом запуске программы после обновления система запускает обработку данных в интерактивном режиме от имени текущего пользователя. Весь процесс выполняется в одном потоке прямо на рабочем месте.

В клиент-серверном варианте логика меняется. Платформа стремится освободить пользователя от ожидания. Сразу после запуска обновленной базы управление передается планировщику заданий на сервере приложений 1С:Предприятия. Запуск обработчиков обновления делегируется специальному регламентному заданию, которое называется "Отложенное обновление ИБ". Если это регламентное задание по какой-то причине не может стартовать, отложенное обновление останавливается, а пользователи видят предупреждение об ограничении работы с данными.

Основная причина: Блокировка регламентных заданий в свойствах базы данных

Самой частой причиной, по которой "зависает" отложенное обновление на сервере, является включенная блокировка регламентных и фоновых заданий для конкретной информационной базы. Часто администраторы включают эту блокировку перед обновлением конфигурации, чтобы пользователи или другие фоновые процессы не мешали процессу накатывания нового релиза, но забывают снять ее после завершения технических работ.

Выясним, как проверить и исправить эту настройку. Разберем два основных способа управления этой опцией.

Способ 1. Снятие блокировки через консоль администрирования кластера 1С

Для того чтобы проверить параметры информационной базы на сервере приложений, выполним следующие шаги:

1. Запустим утилиту "Администрирование серверов 1С:Предприятия" на сервере или на рабочем компьютере администратора.
2. Раскроем дерево кластера, перейдем в ветку "Информационные базы" и найдем в списке нашу базу (например, базу ЗУП).
3. Откроем контекстное меню базы кликом правой кнопки мыши и выберем пункт "Свойства".
4. В открывшемся окне параметров найдем флаг "Блокировка регламентных заданий включена" (в некоторых версиях платформы он называется "Блокировка регламентных заданий").
5. Если этот флаг установлен, снимите его, введите имя и пароль администратора базы данных (если они установлены) и нажмите кнопку "ОК" для сохранения изменений.

Важное примечание: Существует распространенное заблуждение, что регламентные задания можно заблокировать только глобально для всего кластера. На самом деле, эта блокировка устанавливается индивидуально для каждой информационной базы в ее свойствах. Однако администратор может также запустить сам рабочий сервер кластера с ключом блокировки фоновых заданий (параметр запуска службы /b), либо перевести кластер в режим отладки, блокирующий планировщик. В этом случае потребуется проверка параметров запуска службы 1С:Предприятия в диспетчере служб Windows или конфигурационных файлах Linux.

Способ 2. Проверка состояния заданий в режиме "1С:Предприятие"

Если у вас нет прямого доступа к консоли администрирования серверов 1С, мы можем проанализировать состояние планировщика непосредственно из пользовательского интерфейса. Для этого выполним следующие действия:

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

Альтернативные причины, почему обновление не запускается на сервере

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

• Дефицит клиентских лицензий 1С. Каждое фоновое задание, порождаемое сервером для выполнения отложенного обновления, требует наличия свободной клиентской лицензии. Если все имеющиеся лицензии заняты активными пользователями, фоновый процесс просто не сможет стартовать и перейдет в режим ожидания. Рекомендуется запускать обновление в нерабочее время, когда лицензии свободны.
• Лимиты рабочих процессов (rphost). Если в настройках кластера серверов жестко ограничены ресурсы (например, максимальный объем памяти на рабочий процесс или лимит количества фоновых заданий), сервер может отказывать в порождении новых потоков для обработки данных обновления.
• Ограничения прав учетной записи службы 1С. Служба сервера 1С:Предприятия в ОС Windows обычно функционирует под специальной системной учетной записью (например, USR1CV8). Если у этого пользователя нет полных прав на чтение и запись во временную директорию (папку Temp) сервера или в каталоги установленной платформы, фоновые задания будут аварийно завершаться сразу после старта без детального логирования в журнале регистрации.
• Конфликты блокировок данных (Deadlocks). В отличие от файлового варианта, где обновление идет монопольно, в клиент-серверном режиме пользователи могут работать в базе одновременно с выполнением отложенного обновления. Если пользователь пытается изменить документ или элемент справочника, который в этот же момент перезаписывается обработчиком обновления, возникнет конфликт объектных блокировок, и процедура обновления прервется с ошибкой.

Принудительный запуск обновления через командную строку

Бывают ситуации, когда нам необходимо выполнить обновление максимально быстро и гарантированно, минуя стандартный планировщик регламентных заданий кластера. Для этого мы можем задействовать недокументированные параметры запуска Библиотеки стандартных подсистем.

Рассмотрим два ключевых параметра запуска системы, которые передаются через ключ /C командной строки:

1. /C ВыполнитьОтложенноеОбновлениеСейчас — этот ключ указывает системе запустить выполнение всех отложенных обработчиков обновления немедленно в текущем сеансе. Запуск происходит в монопольном (однопоточном) режиме. Это гарантирует, что обновление выполнится до того, как в базу зайдут пользователи. Данный ключ незаменим при последовательном обновлении конфигурации через несколько релизов подряд, когда нельзя переходить к следующему этапу обновления, пока не завершился предыдущий.
2. /C ЧислоПотоковОбновления;<число> — позволяет вручную регулировать количество параллельных потоков, выполняющих обработку данных. По умолчанию система пытается использовать 8 потоков. На производительных серверах это число можно увеличить (рекомендуется устанавливать по количеству ядер процессора), что существенно ускорит процесс. Если же в процессе обновления возникают ошибки транзакционных блокировок, количество потоков имеет смысл уменьшить до 1 или 2.

Пример строки запуска для принудительного выполнения отложенного обновления в монопольном режиме:

"C:\Program Files\1cv8\8.3.22.1709\bin\1cv8.exe" ENTERPRISE /S "Server1C\ZUP_Base" /N "Администратор" /P "Пароль" /C ВыполнитьОтложенноеОбновлениеСейчас /DisableStartupMessages

Программный запуск и сброс зависших процедур

Иногда возникает ситуация, когда статус процедур обновления в интерфейсе "Результаты обновления программы" застывает в положении "Выполняется", но фактически никаких фоновых процессов на сервере 1С не запущено (например, произошел аварийный перезапуск сервера или службы rphost). В этом случае стандартные механизмы могут бесконечно ожидать завершения несуществующего процесса.

Для программного решения этой проблемы разработчик или администратор с правами на запуск внешних обработок может выполнить специальный код. Рассмотрим эти методы подробнее.

Для принудительного программного старта процедур обновления выполним следующий код:

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

Если обновление зависло и не реагирует на стандартные команды, выполним сброс состояния обработчиков и их перезапуск с помощью метода БСП:

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

Этот метод принудительно останавливает текущее зависшее регламентное задание, заново анализирует зарегистрированные данные для обработки и корректно перезапускает процесс обновления с чистого листа.

Резюме

Мы проанализировали основные причины, по которым могут не выполняться дополнительные процедуры обновления в клиент-серверной версии 1С:Предприятия. В большинстве случаев проблема кроется в банальной блокировке регламентных заданий в свойствах информационной базы. Решив эту проблему на уровне администрирования кластера или воспользовавшись параметрами командной строки для принудительного запуска, мы сможем гарантировать стабильную работу системы и актуальность всех данных в базе.