Динамическое обновление конфигурации, часто называемое обновлением «на лету», является крайне удобным инструментом для оперативного исправления ошибок в программном коде без прерывания работы пользователей. Однако этот механизм таит в себе множество подводных камней, которые могут привести к критическим сбоям в работе системы. Разберем подробно, какие риски существуют, как работает этот механизм изнутри и что делать, если после нажатия кнопки «Обновить динамически» база перестала запускаться.
Для того чтобы понимать природу ошибок, проанализируем, как платформа 1С:Предприятие обрабатывает динамические изменения. В отличие от монопольного обновления, при динамическом платформа не замещает основную конфигурацию в таблице Config мгновенно для всех. Вместо этого изменения записываются в промежуточную таблицу ConfigSave, а в системной таблице DBSchema создается соответствующая отметка о наличии новой версии метаданных.
Рассмотрим ситуацию, когда в процессе записи этих изменений происходит сбой: обрыв сетевого соединения с сервером баз данных или скачок напряжения. В этом случае база может войти в состояние «рекурсивного обновления». Пользователь видит бесконечное предложение обновиться, но процесс не завершается. Для исправления такой ситуации часто недостаточно просто перезапустить сервер. Разберем алгоритм «лечения» на уровне SQL-запросов (данный метод требует крайней осторожности и наличия бэкапа):
Сначала нам необходимо очистить таблицу с временными изменениями, которые не смогли примениться корректно:
DELETE FROM ConfigSave;
UPDATE DBSchema SET Version = 0;
После выполнения этих манипуляций конфигуратор «забудет» о неудачной попытке динамического обновления, и вы сможете попробовать обновиться снова, но уже в монопольном режиме.
Одной из самых распространенных проблем является некорректная работа локального кэша на компьютерах пользователей. Выясним причину: когда программный код (например, модуль формы или общий модуль) обновляется динамически, платформа должна уведомить все активные сеансы о том, что нужно перечитать метаданные. Однако на практике локальный кэш AppData часто удерживает старые версии файлов.
В результате возникают следующие ситуации:
Единственным надежным способом решения этой проблемы является полная очистка кэша. Проанализируем, как это сделать массово. Самый простой способ — изменить путь к базе в списке баз или использовать скрипты для удаления содержимого папок в каталоге пользователя:
rd /s /q "%LocalAppData%\1C\1Cv8"
rd /s /q "%AppData%\1C\1Cv8"
В современных релизах платформы (начиная с 8.3.15) динамическое обновление основной конфигурации часто вступает в жесткий конфликт с активными расширениями. Проанализируем ситуацию: если ваше расширение заимствует метод из общего модуля, который вы решили обновить динамически, связь между ними может разорваться. Система выдаст критическую ошибку Объект не найден прямо во время работы пользователя.
Особенно это актуально для высоконагруженных систем. Иногда после динамического обновления расширения просто перестают применяться (эффект «отваливания»), и их функционал пропадает до тех пор, пока все пользователи не перезапустят свои сеансы.
При динамическом обновлении сервер 1С (процесс rphost) вынужден держать в оперативной памяти одновременно несколько версий конфигурации: старую (для тех, кто еще не перезашел) и новую (для новых подключений). Посмотрим на последствия:
На последних релизах платформы (например, 8.3.26.1498) зафиксированы случаи, когда добавление новых форм при динамическом обновлении приводит к тому, что база перестает запускаться вовсе, а конфигуратор открывается с огромным трудом. Также замечены проблемы с регламентными заданиями. После динамического обновления система иногда теряет связь с сеансом фонового задания, выдавая ошибку Сеанс отсутствует или удален. В этом случае регламентные задания просто перестают выполняться, пока не будет перезапущена служба 1C:Enterprise Server.
Рассмотрим редкий, но крайне опасный случай, когда динамическое обновление затрагивает механизмы проведения документов. Бывали ситуации, когда из-за рассинхронизации версий кода у разных пользователей «повалились» проводки или некорректно рассчитались бухгалтерские итоги. Это происходит, если один пользователь проводит документ, используя старую логику модуля, а другой — уже новую, при этом оба обращаются к одним и тем же таблицам итогов. Исправление таких последствий требует полного пересчета итогов, что невозможно сделать без выгона всех пользователей.
Подведем итог и составим план действий для минимизации рисков при работе с динамическим обновлением:
Если...Тогда).Помните, что хотя в 99% случаев динамическое обновление проходит успешно, оставшийся 1% может парализовать работу всей компании на несколько часов из-за необходимости восстановления базы из копии или ручной очистки SQL-таблиц.