Динамическое обновление конфигурации в среде разработчиков и администраторов 1С часто называют «демоническим». Этот эпитет оно заслужило из-за непредсказуемого поведения платформы, которое может привести к внезапному повреждению базы данных, рассинхронизации клиентских сеансов и потере внесенных изменений. Тем не менее в условиях круглосуточной работы пользователей (24/7) динамическое обновление остается единственным оперативным способом исправить критическую ошибку в коде без остановки бизнес-процессов.
В этой статье мы подробно разберем, как устроены механизмы динамического обновления, почему возникают сбои кэширования, как ведет себя платформа 8.3.12 и последующих версий, а также рассмотрим пошаговые инструкции по восстановлению поврежденной базы данных с помощью SQL-запросов.
Довольно часто разработчики сталкиваются с парадоксальной ситуацией: изменения в модулях были внесены, динамическое обновление успешно выполнено, но после перезапуска Конфигуратора весь новый код исчезает, возвращаясь к исходному состоянию. Давайте проанализируем, почему это происходит.
Причина кроется в рассинхронизации локального кэша метаданных Конфигуратора на компьютере разработчика и реального состояния таблиц базы данных в СУБД:
config под временными внутренними именами (версиями).dbNameCache и SICache в профиле пользователя операционной системы) не всегда успевает мгновенно обновить структуру измененных метаданных, особенно если разработчик производит несколько обновлений подряд или сразу запускает сеанс отладки.Чтобы избежать этой ловушки, возьмем за правило использовать ключ запуска Конфигуратора /ClearCache для принудительной очистки временных файлов метаданных перед началом работы, либо вручную очищать папки по пути %userprofile%\AppData\Local\1C\1Cv8\ при возникновении подозрений на некорректное поведение системы.
Начиная с релиза платформы 8.3.12, разработчики 1С добавили долгожданную функцию ожидания ответа от сервера приложений в случае его кратковременного зависания или перезапуска. Сеансы пользователей больше не обрываются мгновенно, если перезагружается рабочий процесс rphost. Однако у этого полезного механизма есть обратная сторона, которая существенно усложнила процесс динамического обновления:
rphost.exe не освобождали оперативную память, выделенную под хранение старых версий объектов конфигурации. Это приводило к лавинообразному потреблению ресурсов ОЗУ сервером приложений и его аварийной остановке.Метод объекта не обнаружен или Слишком много фактических параметров. Это происходит, когда измененный общий модуль уже обновился на сервере приложений, а клиентский кэш пользователя продолжает вызывать его по старой схеме.Для минимизации рисков разрушения конфигурации и обеспечения стабильной работы пользователей мы рекомендуем внедрить в повседневную практику следующие правила:
.cf на тестовой базе и загрузите его целиком в рабочую конфигурацию перед запуском обновления. Это снижает вероятность нарушения связей метаданных.Если нам необходимо застраховать себя перед динамическим обновлением, а времени на полный бэкап базы данных нет, мы можем настроить резервное копирование только двух ключевых таблиц СУБД: config (хранит основную конфигурацию базы данных) и configsave (хранит конфигурацию, редактируемую в данный момент в Конфигураторе).
Для создания быстрой резервной копии структуры конфигурации в СУБД Microsoft SQL Server выполним следующий SQL-скрипт:
SELECT * INTO config_backup_temp FROM config;
SELECT * INTO configsave_backup_temp FROM configsave;
Если динамическое обновление завершилось аварийно, и база данных перестала запускаться, мы сможем восстановить работоспособность конфигурации, вернув данные из созданных нами резервных таблиц:
TRUNCATE TABLE config;
INSERT INTO config SELECT * FROM config_backup_temp;
TRUNCATE TABLE configsave;
INSERT INTO configsave SELECT * FROM configsave_backup_temp;
DROP TABLE config_backup_temp;
DROP TABLE configsave_backup_temp;
Что делать, если динамическое обновление оборвалось из-за отключения электроэнергии, сбоя сети или падения службы сервера 1С, а база данных теперь выдает ошибку «Нарушена целостность структуры конфигурации» или «Обнаружена незавершенная операция сохранения»?
Для восстановления целостности метаданных в клиент-серверном режиме работы базы данных мы можем применить очистку незавершенных транзакций обновления напрямую в СУБД. Проанализируем пошаговый алгоритм решения этой проблемы.
Выполним следующий пакет SQL-запросов для удаления незавершенных версий конфигурации и сброса флагов динамического обновления:
-- Шаг 1. Очищаем таблицу редактируемой конфигурации
DELETE FROM configsave;
-- Шаг 2. Удаляем маркеры незавершенной транзакции обновления из основной таблицы
DELETE FROM config WHERE FileName = 'commit';
DELETE FROM config WHERE FileName = 'dynamicCommit';
DELETE FROM config WHERE FileName = 'dbStruFinal';
После выполнения этих запросов системные блокировки будут сняты. Теперь мы можем открыть базу данных в режиме Конфигуратора и выполнить стандартную процедуру проверки: меню Конфигурация — Обновить конфигурацию базы данных (или нажать клавишу F7), чтобы платформа пересобрала кэш и сопоставила таблицы СУБД.
При использовании динамического обновления важно помнить, что база данных временно переходит в режим сосуществования двух версий конфигурации одновременно. Старые сеансы пользователей продолжают выполнять код по алгоритмам, загруженным до обновления, а новые сеансы начинают исполнять измененный код. Это рождает неочевидные архитектурные риски:
В современных версиях платформы 1С:Предприятие (начиная с релизов 8.3.15 и выше) разработчики все чаще отказываются от использования классического динамического обновления в пользу более безопасных архитектурных решений:
config.Подводя итог, отметим: динамическое обновление — это мощный, но опасный инструмент быстрого реагирования. Понимание принципов кэширования метаданных и умение работать с таблицами конфигурации напрямую через СУБД позволят вам минимизировать время простоя системы при любых непредвиденных сбоях.