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

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

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

Проанализируем механику применения изменений при сохранении и обновлении конфигурации. При нажатии сочетания клавиш Ctrl+S сохраняется только основная конфигурация разработчика. Непосредственное обновление конфигурации базы данных происходит при нажатии F7 (или кнопки с изображением синего цилиндра на панели инструментов).

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

1. Изменения записываются в базу данных немедленно: сама конфигурация базы данных обновляется сразу же в момент подтверждения динамического обновления в Конфигураторе. Платформа не ожидает выхода пользователей и не откладывает перезапись структуры до момента входа первого пользователя.
2. Поведение сеансов пользователей: каждый активный сеанс клиента при старте загружает метаданные и скомпилированные модули в локальную память. Сеансы, запущенные до динамического обновления, продолжают исполнять старую версию кода. Новые сеансы, подключившиеся после нажатия F7, сразу начинают работу с обновленной конфигурацией.
3. Оповещение клиентов: если в конфигурации используется Библиотека стандартных подсистем (БСП) или встроенные механизмы оповещения платформы, активные пользователи получают уведомление о том, что версия конфигурации изменилась, с предложением перезапустить сеанс программы для вступления изменений в силу.

Что можно и что нельзя обновлять динамически

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

Рассмотрим, какие элементы можно обновлять без отключения пользователей:

1. Текст программного кода в общих модулях, модулях менеджеров, модулях объектов и модулях форм.
2. Элементы интерфейса, формы документов, справочников и отчетов (разметка, элементы управления, оформление).
3. Макеты печатных форм, текстовые макеты и двоичные данные.
4. Новые отчеты, обработки и внешние печатные формы, которые не создают собственных таблиц хранения данных.
5. Права доступа и роли (без изменения состава объектов метаданных).

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

Причины сбоев и накопление версионных дельт

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

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

1. Рассинхронизация серверного и клиентского кэша: контексты рабочих процессов кластера (каталоги snccntx в srvinfo) и кэш на клиентских рабочих станциях могут содержать разные версии скомпилированных общих модулей. Это приводит к ошибкам несоответствия типов, падению рабочих процессов rphost и сообщению Ошибка формата потока.
2. Разрушение цепочки версий: при аварийном завершении сеанса Конфигуратора во время записи дельты нарушается целостность системных таблиц, что блокирует дальнейшее обновление базы данных.

Методы восстановления и безопасной работы

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

1. Сброс цепочки дельт (полная пересборка конфигурации): чтобы принудительно перезаписать таблицу конфигурации монопольно, выгоняем всех пользователей из базы данных. В Конфигураторе вносим незначительное изменение (например, ставим пробел в любом общем модуле или меняем комментарий в свойствах конфигурации) и сохраняем изменения через F7 в обычном (монопольном) режиме. Платформа полностью пересоберет метаданные и сотрет промежуточные дельты.
2. Очистка серверного кэша кластера: останавливаем службу сервера 1C:Enterprise Server Agent. В каталоге кластера (по умолчанию srvinfo) удаляем временные папки с префиксом snccntx* и кэш рабочих процессов. Системные файлы настроек кластера с расширением .lst удалять нельзя. После этого запускаем службу заново.
3. Очистка клиентского кэша: запускаем клиентское приложение с параметром командной строки /ClearCache или очищаем папки локального кэша пользователя в каталогах AppData\Local\1C\1cv8 и AppData\Roaming\1C\1cv8.
4. Тестирование и исправление: при сохранении ошибок целостности выполняем штатную процедуру тестирования и исправления информационной базы через Конфигуратор с включенными опциями проверки логической целостности и реиндексации таблиц (для файловых баз также применяется утилита chdbfl.exe).

Регламент завершения сеансов и современные альтернативы

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

1. Принудительное завершение сеансов: для регламентного монопольного обновления сеансы пользователей завершаются через консоль администрирования кластера серверов 1С или с помощью установки блокировки соединений с использованием кода разрешения (параметр /UC). Это позволяет администратору выполнять обновление, пока для остальных пользователей вход заблокирован.
2. Использование расширений конфигурации (cfe): большинство правок логики форм, алгоритмов проведения и печатных форм целесообразно выносить в расширения. Механизм расширений позволяет обновлять код без изменения основной конфигурации поставщика и без накопления опасных дельт в таблице метаданных.
3. Фоновая реструктуризация: в современных версиях платформы 1С:Предприятие для клиент-серверных баз доступен режим фоновой реструктуризации, при котором основная часть перестроения таблиц выполняется параллельно с работой пользователей, а монопольная блокировка устанавливается лишь на короткий финальный интервал времени.