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

Программист 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

Особенности и риски динамического обновления конфигурации 1С

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

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

  1. Рассинхронизация кэша метаданных: При выполнении динамического обновления активные сеансы пользователей продолжают работать со старой версией кода в памяти. В многосерверных кластерах 1С рабочий процесс rphost не всегда мгновенно обновляет кэш метаданных на всех узлах. Это приводит к возникновению критических ошибок работы с памятью и аварийному завершению сеансов.
  2. Накопление устаревших версий в таблице Config: Каждая процедура динамического обновления сохраняет в служебных таблицах СУБД (Config, Params) очередную версию структуры метаданных. При частом использовании этого метода системные таблицы раздуваются, происходит дефрагментация индексов, что со временем вызывает ошибки целостности вроде «Ошибка формата потока».
  3. Последовательные обновления без перезапуска Конфигуратора: Настоятельно не рекомендуется выполнять два и более динамических обновления подряд в рамках одной сессии работы в Конфигураторе. Подобные действия существенно повышают риск повреждения структуры метаданных.

Что делать, если база «упала» после динамического обновления

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

Шаг 1. Очистка кэша пользователей и сервера 1С

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

  1. Остановим службу «Агент сервера 1С:Предприятия» через консоль управления службами.
  2. Перейдем в служебную папку srvinfo на сервере и удалим временные каталоги сеансов и конфигураций (не затрагивая файлы лицензий и ключевые настройки).
  3. Запустим службу агента сервера 1С.

Шаг 2. Восстановление таблицы Config из резервной копии в СУБД

Если база данных работает под управлением СУБД (MS SQL Server или PostgreSQL) и после динамического обновления Конфигуратор отказывается запускаться, не обязательно восстанавливать всю базу целиком и терять введенные за день данные пользователей. Достаточно восстановить только конфигурацию:

  1. Развернем актуальную резервную копию базы данных в отдельный тестовый контур СУБД.
  2. С помощью средств СУБД перенесем таблицу Config (а при необходимости и ConfigSave) из тестовой базы в рабочую.
  3. Удалим из таблицы Config записи, относящиеся к незавершенным транзакциям динамического обновления.

Шаг 3. Принудительный сброс динамического режима через командную строку

Выйти из состояния незавершенного обновления конфигурации базы данных можно путем запуска Конфигуратора в автоматическом режиме с ключом /UpdateDBCfg -Dynamic-:


1cv8.exe DESIGNER /IBName "РабочаяБаза" /N "Администратор" /P "Пароль" /UpdateDBCfg -Dynamic-

Флаг -Dynamic- запрещает использование динамического обновления и принудительно заставляет платформу выполнить стандартную процедуру обновления конфигурации БД.

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

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

1. Использование расширений конфигурации (патчей)

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

2. Двухэтапное сохранение конфигурации

Если правки вносятся в разгар рабочего дня, целесообразно разделить процесс на два этапа:

  1. Внесем изменения в код и нажмем Сохранить конфигурацию (Ctrl + S). При этом конфигурация базы данных не меняется, а пользователи продолжают штатно работать.
  2. В конце рабочего дня или во время технологического перерыва выполним стандартное обновление конфигурации базы данных (F7) в монопольном режиме.

3. Фоновое обновление конфигурации БД

Платформа 1С:Предприятие поддерживает механизм фонового обновления. Запуск фоновой реструктуризации выполняется через командную строку с параметром /UpdateDBCfg -BackgroundStart. Основной объем подготовки данных происходит в фоновом режиме во время работы пользователей, а короткая блокировка требуется только на финальной стадии фиксации изменений.

4. Кратковременная блокировка сеансов

Если изменения критичны для работы организации, лучшей практикой остаётся установка административной блокировки новых сеансов и завершение работы текущих через консоль кластера 1С. Монопольное обновление занимает всего 1–2 минуты, после чего пользователи могут безопасно продолжать работу в обновленной системе.

← На главную