Механизм динамического обновления (в среде разработчиков часто называемый «демоническим») — это функционал, позволяющий вносить изменения в программный код и формы без требования монопольного доступа к базе данных. На первый взгляд это кажется идеальным решением для систем с круглосуточным режимом работы, таких как розничные сети или крупные производства. Однако на практике этот инструмент таит в себе множество опасностей, способных привести к полной остановке работы предприятия и повреждению структуры базы данных. Проанализируем основные риски и разберем способы их минимизации.
Рассмотрим подробнее, как платформа 1С обрабатывает динамические изменения. Основная сложность заключается в том, что после применения обновления сеансы пользователей, уже находящихся в базе, продолжают работать со «старым» слепком конфигурации, хранящимся в их локальном кэше. Новые же сеансы подхватывают «свежую» версию метаданных. Выясним причину, по которой это критично: ситуация, когда часть пользователей выполняет алгоритмы по старой логике, а часть — по новой, неизбежно ведет к логическим ошибкам в данных.
Основные проблемы кэширования:
Метод объекта не обнаружен или Поле объекта не обнаружено.rphost хранят разные версии конфигурации. Пользователь может «прыгать» между ними, что вызывает непредсказуемое поведение программы.Для решения проблем с кэшем мы рекомендуем стандартную процедуру очистки временных файлов. Необходимо удалить содержимое папок в каталогах пользователя:
%AppData%\Roaming\1C\1Cv8
%LocalAppData%\1C\1Cv8
Разберем наиболее опасный сценарий — повреждение таблицы Config (или DBSchema). Это происходит, если в момент фиксации изменений произошел сетевой сбой, аварийное завершение работы конфигуратора или конфликт блокировок СУБД. В этом случае база данных может перестать открываться даже в режиме Конфигуратора, выдавая ошибку: «Внимание!!! При обновлении данных произошла ошибка. Повторить обновление?».
Проанализируем ситуацию восстановления для клиент-серверного варианта на MS SQL Server. Если база «легла» после динамического обновления, и вы не можете зайти в конфигуратор, воспользуйтесь следующими SQL-запросами для удаления признака незавершенного обновления:
-- Удаление признака фиксации изменений
DELETE FROM config WHERE FileName = 'commit';
-- Удаление признака реструктуризации
DELETE FROM config WHERE FileName = 'dbStruFinal';
Важно: Перед выполнением любых прямых запросов к базе данных SQL обязательно сделайте полную резервную копию! Эти действия позволяют «откатить» состояние конфигурации к моменту до начала неудачного обновления, что вернет возможность зайти в Конфигуратор монопольно.
Посмотрим на пример работы с распределенными информационными базами. Динамическое обновление в центральном узле крайне негативно сказывается на периферийных узлах. При обмене данными периферийная база получает изменения конфигурации, но из-за специфики динамического метода механизм сравнения и объединения может отработать некорректно. Это приводит к ошибке «Конфигурация ИБ не соответствует ожидаемой», после чего обмен блокируется полностью.
Чтобы избежать «плясок с бубном» при работе с РИБ, придерживайтесь правила: любые изменения метаданных в распределенной системе должны выполняться только в монопольном режиме с последующей передачей изменений через файл обмена.
Разберем ситуацию с фоновыми заданиями. Платформа 1С кэширует метаданные для фоновых процессов очень агрессивно. Если после динамического обновления не перезапустить службу 1C:Enterprise Server Agent, регламентные задания (например, обмены или расчеты) могут часами или даже днями работать на старом коде, игнорируя ваши исправления.
Аналогичная проблема характерна для Web- и HTTP-сервисов. Пул соединений web-сервера (IIS или Apache) не обновляется автоматически. В результате ваши внешние системы могут получать старые данные или выдавать ошибки, так как они обращаются к «зависшему» в памяти расширению web-сервера.
Рассмотрим специфический баг, упомянутый опытными разработчиками: при частом динамическом обновлении могут самопроизвольно «слетать» права доступа на новые или измененные объекты конфигурации. Даже если вы установили галочки в ролях, после динамического обновления они могут не примениться для части пользователей.
Посмотрим на решение, которое применяют в крупных компаниях: создание SQL-триггера для таблицы Config. Рассмотрим этот метод: администраторы настраивают триггер, который при любом изменении таблицы делает ее резервную копию в отдельную таблицу-архив. Это позволяет мгновенно восстановить структуру Config без полного восстановления всей базы из бэкапа весом в несколько терабайт.
Проанализировав все риски, мы можем сформулировать свод правил для минимизации ущерба:
Config возрастает. Лучше закрыть конфигуратор вручную.Config так глубоко.В заключение отметим: динамическое обновление — это инструмент экстренной хирургии, а не ежедневная практика. Если у вас есть возможность выгнать пользователей на 5 минут — всегда выбирайте монопольное обновление. Это сбережет ваши нервы, данные компании и время на восстановление системы после очередного «удачного» динамического патча.