Как работает фоновое обновление конфигурации базы данных в 1С и какие лицензии требуются для его запуска?

При сопровождении высоконагруженных информационных баз 1С с круглосуточным режимом работы (24/7) или большим количеством активных сеансов одной из ключевых проблем становится длительное технологическое окно для применения изменений. Внесение масштабных правок в структуру метаданных (добавление реквизитов, изменение типов, добавление новых объектов) в стандартном режиме требует монопольного захвата таблиц СУБД, что влечет за собой длительный простой пользователей. Рассмотрим подробнее, как устроен механизм фонового обновления конфигурации базы данных, сколько времени занимает его запуск и какие лицензионные и аппаратные требования необходимо выполнить.

Лицензионные требования и дополнительные затраты

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

Для легального и полноценного использования механизма требуются:

1. Серверная лицензия «1С:Предприятие 8.3 КОРП»: использование 64-разрядного сервера уровня КОРП является обязательным условием.
2. Клиентские лицензии уровня КОРП: все рабочие места, подключающиеся к серверу КОРП, также должны быть обеспечены клиентскими лицензиями уровня КОРП.

В ранних версиях платформы (например, в линейке 8.3.10) данный функционал технически мог инициироваться и на лицензиях уровня ПРОФ, однако юридически использование функции без лицензий КОРП являлось нарушением лицензионного соглашения («ограничение на бумаге»). Начиная с версий платформы 8.3.14/8.3.15 фирма «1С» встроила строгую программную валидацию: при попытке запустить фоновое обновление на сервере уровня ПРОФ система выдаст ошибку о недоступности функции КОРП. Поэтому основным дополнительным расходом при переходе на фоновое обновление является апгрейд лицензий с ПРОФ на КОРП.

Время на настройку и сложность внедрения

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

Запуск фонового обновления возможен двумя способами:

1. Интерактивный запуск через Конфигуратор:

   Администратор открывает дерево конфигурации, применяет изменения и в меню выбирает команду «Конфигурация — Обновить конфигурацию базы данных в фоновом режиме».

2. Автоматизированный запуск через командную строку (CLI / CI/CD):

   Для автоматизации регламентных процедур и ночных обновлений используются пакетные параметры запуска исполняемого файла 1cv8.exe или ibcmd.

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

Запуск фонового процесса обновления конфигурации базы данных:

1cv8.exe DESIGNER /S "ServerName\BaseName" /N "Admin" /P "Password" /UpdateDBCfg -BackgroundStart -Visible

Завершение обновления и применение изменений (финализация):

1cv8.exe DESIGNER /S "ServerName\BaseName" /N "Admin" /P "Password" /UpdateDBCfg -BackgroundFinish

Отмена запущенного фонового обновления в случае необходимости (Rollback):

1cv8.exe DESIGNER /S "ServerName\BaseName" /N "Admin" /P "Password" /UpdateDBCfg -BackgroundCancel

Как устроен процесс фоновой реструктуризации

Разберем по шагам, как платформа 1С выполняет фоновое обновление без прерывания текущей работы пользователей в информационной базе:

1. Фаза фоновой реструктуризации: Платформа анализирует внесенные изменения в метаданные и создает в СУБД дубликаты модифицируемых таблиц с новой схемой. Далее в фоновом потоке данные из старых таблиц порциями переносятся в новые структуры. Пользователи продолжают свободно работать со старыми таблицами, проводить документы и вводить данные.
2. Фаза синхронизации изменений: Платформа накладывает служебные триггеры фиксации изменений на исходные таблицы. Все новые записи и модификации данных, которые делают пользователи во время реструктуризации, переносятся в новые таблицы в режиме накопления дельты.
3. Фаза финализации (завершение): Единственный этап, требующий монопольного доступа, однако его продолжительность сокращается с нескольких часов до 20–60 секунд (в редких случаях — до 2–3 минут). Система на короткий момент блокирует пользовательские сеансы, быстро переносит оставшийся небольшой хвост изменений, переименовывает таблицы в СУБД и мгновенно делает обновленную конфигурацию активной.

Технические ограничения и требования к ресурсам

Рассмотрим важные нюансы, о которых должен знать системный администратор перед использованием механизма:

1. Дисковое пространство СУБД: Из-за одновременного присутствия в базе старых и новых таблиц объем дискового пространства должен быть достаточным. Для сильно изменяемых таблиц рекомендуется иметь запас свободного места в 1,5–2 раза больше размера самих обновляемых таблиц. Также существенно возрастает нагрузка на журнал транзакций (LDF для MS SQL Server или WAL для PostgreSQL).
2. Нагрузка на дисковую подсистему и процессор: Фоновый перенос данных и работа триггеров синхронизации создают дополнительную нагрузку на диски (I/O) и серверные мощности. Рекомендуется запускать фоновую фазу во время умеренной или низкой пользовательской активности.
3. Типы поддерживаемых изменений: Большинство стандартных изменений (добавление реквизитов, справочников, табличных частей) поддерживаются в фоне. Однако при сложных изменениях типов данных или структур некоторых регистров платформа может выдать предупреждение о невозможности фоновой реструктуризации и потребует проведения стандартного монопольного обновления.
4. Надежность и откат: Механизм является полностью транзакционным и безопасным. При возникновении сбоя питания, перезагрузки сервера или принудительной отмены командой -BackgroundCancel созданные временные структуры аккуратно удаляются, а исходные рабочие данные пользователей остаются в целости и сохранности.