Динамическое обновление конфигурации базы данных (в профессиональной среде часто именуемое «демоническим») позволяет вносить доработки в код модулей, печатных форм и отчетов без отключения активных пользователей. Однако применение этого механизма нередко приводит к непредвиденным последствиям: от локального зависания старого кода у отдельных сотрудников до полной блокировки работы базы и повреждения метаданных.
Разберем детально, почему происходят сбои, с какими симптомами можно столкнуться, как восстановить работоспособность информационной базы и каких правил следует придерживаться для минимизации рисков.
Типовые симптомы и ошибки динамического обновления
Проанализируем основные проблемы, с которыми сталкиваются разработчики и администраторы при регулярном использовании динамического обновления:
Рассинхронизация кэша на клиентах и сервере. Пользователь жалуется на ошибки в модулях, хотя в конфигураторе код исправлен. Клиентское приложение продолжает обращаться к локально сохраненным старым метаданным. В ряде случаев расчетные алгоритмы продолжают работать по старой логике у одних пользователей и по новой — у других, что приводит к искажению данных в базе.
«Ошибка формата потока» и дублирование объектов. При многократном накатывании изменений подряд платформа может сохранить поврежденную структуру описания метаданных. В дереве конфигурации могут появиться задвоенные реквизиты или объекты, а запуск приложения блокируется критической ошибкой.
«Нарушена целостность структуры конфигурации». Возникает, если в процессе сохранения произошел сетевой сбой, аварийное закрытие конфигуратора или конфликт блокировок таблиц СУБД. Конфигуратор перестает открываться, а режим 1С:Предприятие может выдавать ошибки при обращении к измененным модулям.
Откат изменений или пропажа кода. При совместной разработке или динамическом обновлении из хранилища конфигурации часть ранее примененных правок может бесследно исчезнуть или откатиться на предыдущую ревизию.
Технические причины сбоев в механизме динамического обновления
Выясним причину такого поведения на системном уровне:
Зависание служебных маркеров транзакций. При динамическом обновлении платформа выполняет пакетную запись измененных данных конфигурации в таблицу Config базы данных СУБД. В эту же таблицу добавляются служебные записи с параметрами в поле FileName: commit, dynamicCommit, dbStruFinal, DynamicallyUpdated. Если сессия конфигуратора обрывается до завершения транзакции, эти маркеры остаются в базе и блокируют любые последующие штатные обновления.
Несинхронное обновление рабочих процессов кластера. В многопроцессорных клаверах 1С процессы rphost и rmngr кэшируют метаданные в оперативной памяти. Динамическое обновление не всегда одновременно доходит до всех рабочих процессов, что провоцирует ошибку несовпадения версий метаданных при переключении клиентских сеансов между процессами.
Ограничение архитектуры метаданных. Механизм динамического обновления в принципе не рассчитан на изменение структуры таблиц СУБД (добавление реквизитов, изменение типов, табличных частей или регистров). Попытка обойти это ограничение или обновить служебные структуры (планы обмена, регламентные задания) приводит к разрушению целостности базы.
Способы восстановления информационной базы после сбоя
Рассмотрим по шагам варианты восстановления в зависимости от степени повреждения конфигурации.
Вариант 1. Очистка пользовательского и серверного кэша
Если база открывается, но у части пользователей возникают нелогичные ошибки или продолжает выполняться старый код, необходимо сбросить кэш:
Запустим клиентское приложение с параметром командной строки /ClearCache. Этот ключ очищает кэш метаданных текущего сеанса.
Если проблема сохраняется на терминальном сервере или локальных ПК, удалим временные файлы вручную из каталогов пользователя:
%LocalAppData%\1C\1cv8\
%AppData%\1C\1cv8\
При рассинхронизации кластера серверов выполним перезапуск службы сервера 1С:Предприятия во время технологического окна с очисткой каталога временных файлов сервера (папка snccntx в каталоге srvinfo).
Вариант 2. Точечное восстановление структуры через SQL
Если конфигуратор выдает ошибку «Нарушена целостность структуры конфигурации» или «Обнаружена незавершенная операция сохранения конфигурации», восстановим таблицы без полного отката базы из бэкапа:
Завершим все сеансы пользователей и остановим службу сервера 1С.
В среде управления СУБД (например, MS SQL Server Management Studio) откроем рабочую базу данных.
Очистим таблицу временного сохранения конфигурации:
TRUNCATE TABLE ConfigSave;
Удалим зависшие маркеры динамического обновления из основной таблицы конфигурации:
DELETE FROM Config
WHERE FileName IN ('commit', 'dynamicCommit', 'dbStruFinal', 'DynamicallyUpdated');
Если структура таблицы Config была повреждена полностью, восстановим только ее из резервной копии:
TRUNCATE TABLE Config;
INSERT INTO Config SELECT * FROM [ИмяАрхивнойБазы].[dbo].[Config];
Запустим службу 1С, откроем конфигуратор в монопольном режиме и выполним полное монопольное сохранение конфигурации базы данных.
Вариант 3. Откат конфигурации через командную строку
Если конфигуратор не удается открыть интерактивно, используем режим пакетного запуска для отката к стабильному состоянию:
Параметр /RollbackCfg отменяет изменения конфигурации и возвращает структуру к последней успешно сохраненной версии конфигурации базы данных.
Регламент безопасной работы и современные альтернативы
Если в силу специфики предприятия (например, круглосуточное производство или логистический комплекс) отказаться от обновлений в рабочее время невозможно, применим следующие правила:
Никогда не накатывать обновления подряд. Между динамическими сохранениями делайте паузу, чтобы все активные транзакции и фоновые процессы успели завершиться.
Отключать фоновые и регламентные задания перед выполнением динамического сохранения.
Использовать механизм расширений (патчей). Срочные исправления ошибок в коде модулей безопаснее выпускать в виде расширений с назначением «Исправление» (Hotfix). Они подключаются динамически, не повреждают системную таблицу Config и легко удаляются при возникновении проблем.
Настроить ночное автоматическое обновление. Изменения накапливаются в течение дня в конфигурации хранилища, а ночью запускается автоматический скрипт применения конфигурации базы данных:
Применять фоновое обновление базы данных. В современных релизах платформы механизм фонового обновления позволяет выполнять реструктуризацию таблиц СУБД в фоновом режиме во время работы пользователей, требуя кратковременного монопольного захвата базы только на финальной стадии применения (на несколько секунд).