Динамическое обновление в среде разработчиков 1С часто называют «демоническим». Этот механизм позволяет вносить изменения в программный код без выгона пользователей из базы, что кажется идеальным решением для крупных организаций. Однако за удобством скрываются серьезные технические риски: от банальной очистки кэша до полной потери работоспособности базы данных. Разберем подробно, как работает этот механизм, какие опасности он таит и как реанимировать систему, если что-то пошло не так.
В отличие от стандартного обновления, динамическое не заменяет основную конфигурацию мгновенно. Платформа 1С 8.3 использует таблицу Config в базе данных SQL для хранения версий метаданных. При динамическом обновлении создаются новые записи, помеченные как «динамические», а старые остаются активными для текущих сеансов пользователей.
Проанализируем основные проблемы этого процесса. Главная сложность заключается в так называемой «цепочке версий». Если мы выполняем динамические обновления многократно, не проводя «полное» (монопольное) обновление, в таблице Config накапливается критическое количество версий одного и того же объекта. Это кратно увеличивает риск того, что платформа «запутается» в актуальности метаданных. Рассмотрим типичные последствия:
Выясним, что делать, если после нажатия кнопки «Принять изменения» база перестала открываться или конфигуратор ведет себя неадекватно. Если у нас есть доступ к консоли MS SQL Server, мы можем очистить информацию о незавершенном или сбойном динамическом обновлении. Рассмотрим последовательность SQL-запросов, которые помогают в 99% случаев «оживить» базу без восстановления из бэкапа (хотя наличие бэкапа перед любым обновлением строго обязательно).
Выполним следующие команды для очистки системных таблиц конфигурации:
delete from [ИмяВашейБазы].[dbo].[Config] where FileName = 'commit'
delete from [ИмяВашейБазы].[dbo].[Config] where FileName = 'dbStruFinal'
delete from [ИмяВашейБазы].[dbo].[Config] where FileName = 'DynamicallyUpdated'
delete from [ИмяВашейБазы].[dbo].[Config] where FileName = 'dynamicCommit'
delete from [ИмяВашейБазы].[dbo].[ConfigSave]
Разберем, за что отвечают эти строки. Удаление записей DynamicallyUpdated и dynamicCommit сообщает платформе, что динамических изменений больше нет, и она должна ориентироваться на последнюю стабильную версию. Очистка таблицы ConfigSave удаляет временные изменения, которые не были приняты окончательно. После выполнения этих скриптов рекомендуется перезапустить службу сервера 1С:Предприятие для полной очистки серверного кэша.
Иногда база открывается, но ведет себя странно: старый код продолжает работать параллельно с новым. Это происходит из-за того, что 1С сохраняет части конфигурации в локальном кэше на компьютере пользователя и в серверном кэше snccntxt. Посмотрим на алгоритм действий в такой ситуации:
srvinfo (за исключением файлов лицензий и логов).Чтобы минимизировать риски, проанализируем и внедрим в свою практику несколько правил, которые выработаны годами эксплуатации платформы 8.3:
Правило «1+1»: Если вы сделали одно динамическое обновление, постарайтесь при первой же возможности (например, в обеденный перерыв или вечером) сделать одно обычное «жесткое» обновление. Это схлопнет цепочку версий в таблице Config и предотвратит её разрастание.
Контроль фоновых заданий: Перед обновлением проверим, не запущены ли тяжелые регламентные задания. Динамическое обновление в момент работы фонового процесса, использующего те же объекты метаданных, — верный путь к повреждению конфигурации.
Работа с расширениями: Помним, что расширения в 8.3 также обновляются динамически. Однако, если расширение меняет структуру данных (добавляет реквизиты), динамическое обновление невозможно. Старайтесь использовать расширения для исправления кода, а не для изменения логики хранения данных в оперативных исправлениях.
В последних релизах платформы фирма 1С значительно улучшила механизмы контроля транзакций. Теперь вероятность того, что база «рассыплется» из-за обрыва связи между конфигуратором и сервером, ниже, но она не нулевая. Проанализируем ситуацию с лицензированием: после динамического обновления в 8.3 иногда возникают «фантомные» сеансы. Это происходит из-за того, что сервер перестает корректно сопоставлять выданные лицензии с новыми версиями сеансов. Лечится это, к сожалению, только перезапуском службы сервера.
Подведем итог: Динамическое обновление — это мощный, но опасный инструмент. Используем его только для экстренных правок (hot-fix) в программном коде. Для любых изменений метаданных (добавление реквизитов, изменение типов, удаление объектов) используем только монопольный режим. И всегда, абсолютно всегда, создаем бэкап перед нажатием кнопки обновления, даже если «просто поменяли одну запятую в комментарии».