Динамическое обновление 1С: что это и как применять

Динамическое обновление в 1С — это способ применить изменения конфигурации к работающей информационной базе без завершения сеансов пользователей и без остановки сервера. Изменения сначала сохраняются в отдельной области и вступают в силу для новых сеансов, а уже работающие пользователи продолжают работать на старой версии конфигурации до перезапуска своего сеанса.

Такой режим появился для ситуаций, когда остановить базу невозможно: круглосуточный обмен с сайтом, работа касс, фоновые задания, интеграции с внешними системами. Однако динамическое обновление — не универсальная замена обычному: оно подходит только для ограниченного набора изменений и требует последующего «обычного» обновления, чтобы завершить процесс.

Ниже разобрано, какие именно изменения допускаются, как выполнить динамическое обновление пошагово, как проверить результат и в каких случаях этот режим применять нельзя.

Что такое динамическое обновление простыми словами

При обычном обновлении конфигурации базы данных платформа требует монопольного доступа: все пользователи выходят, фоновые задания останавливаются, выполняется реструктуризация таблиц, и только после этого база снова доступна. При динамическом обновлении платформа сохраняет новую версию конфигурации рядом со старой и не трогает структуру данных.

Технически это работает так: изменённая конфигурация записывается в базу, но физическая реструктуризация таблиц не выполняется. Каждый новый сеанс при старте получает уже обновлённую конфигурацию, а сеансы, запущенные до обновления, продолжают работать со старой версией, загруженной в их память. Постепенно, по мере перезахода пользователей, старая версия «вымирает» естественным образом.

Важно понимать, что динамическое обновление — это не завершённый процесс, а промежуточное состояние. База остаётся в режиме «ожидает обновления», пока не будет выполнено обычное обновление конфигурации базы данных, которое применит накопленные структурные изменения.

Какие изменения допускаются, а какие — нет

Платформа сама анализирует изменения и при попытке обновить либо разрешает динамический режим, либо сообщает, что он невозможен. Понимать границы полезно заранее, чтобы не планировать невозможное.

Как правило, динамическое обновление допустимо для изменений, которые не затрагивают структуру хранимых данных: правки в модулях (общих, объектов, форм), изменения макетов, форм, шаблонов, ролей в части прав на существующие объекты, а также добавление новых объектов метаданных — справочников, документов, регистров, отчётов, обработок.

Динамическое обновление невозможно, если изменения затрагивают структуру существующих данных: добавление или удаление реквизитов у существующих объектов, изменение типов и длин полей, изменение состава измерений и ресурсов регистров, перенумерация, изменение иерархии и другие модификации, требующие реструктуризации таблиц.

Как выполнить динамическое обновление пошагово

Процедура выполняется в конфигураторе и занимает обычно несколько минут. Перед началом убедитесь, что у вас есть актуальная резервная копия и права администратора.

1. 1
   Сделайте резервную копию базы: выгрузку в dt через конфигуратор или средствами СУБД для клиент-серверного варианта
2. 2
   Откройте конфигуратор и выполните загрузку изменённой конфигурации: Конфигурация → Загрузить конфигурацию из файла или обновление через поддержку
3. 3
   Выполните команду Конфигурация → Обновить конфигурацию базы данных
4. 4
   В окне со списком изменений платформа покажет, что возможен динамический режим — подтвердите динамическое обновление
5. 5
   Дождитесь завершения и сообщите пользователям, что изменения подхватятся при следующем входе в программу
6. 6
   Запланируйте обычное обновление конфигурации БД в нерабочее время для завершения процесса

После завершения динамического обновления проверьте состояние базы: откройте конфигуратор и посмотрите, не отображается ли признак ожидания обновления. Если конфигурация базы данных требует обновления, платформа будет напоминать об этом до тех пор, пока не выполнено обычное обновление.

Для клиент-серверных баз, где динамическое обновление выполняется часто, удобно автоматизировать процесс пакетным запуском конфигуратора с параметром /UpdateDBCfg и ключом динамического обновления. Это позволяет встроить процедуру в скрипты выкладки изменений.

designer.exe /S Server\Base /N Админ /P *** /UpdateDBCfg -Dynamic+ /DisableStartupDialogs

Что происходит с пользователями и сеансами

Главный практический эффект динамического обновления — разные версии конфигурации у разных сеансов одновременно. Пользователь, вошедший до обновления, работает по старой логике; вошедший после — по новой. Для большинства правок кода это безопасно, но есть нюансы.

Проблемы возникают, когда старая и новая логика по-разному обрабатывают одни и те же данные. Например, если в новой версии изменён алгоритм проведения документа, то документы, проведённые «старым» сеансом после обновления, будут оформлены по старым правилам. Поэтому критичные изменения бизнес-логики лучше применять, когда все пользователи перезайдут, либо через обычное обновление.

Фоновые и регламентные задания также продолжают работать на старой версии до перезапуска. На кластере серверов 1С сеансы фоновых заданий перезапускаются по своему расписанию, поэтому обновлённая логика подхватится не мгновенно.

Проверка результата и контрольные точки

После динамического обновления нужно убедиться, что изменения применились корректно и база находится в ожидаемом состоянии.

Отдельно проверьте работу ключевых сценариев, которых коснулись изменения: проведите тестовый документ, сформируйте отчёт, выполните обмен. Делать это стоит от нового сеанса, чтобы тестировалась именно обновлённая версия.

Типичные ошибки и ограничения

Опыт администрирования показывает, что большинство проблем с динамическим обновлением связано не с самим механизмом, а с неверными ожиданиями от него.

Ещё одно ограничение: динамическое обновление не применимо при обновлении типовых конфигураций на новый релиз в общем случае, поскольку релизы почти всегда содержат изменения структуры данных. Режим рассчитан в первую очередь на собственные доработки и точечные исправления.

Когда динамическое обновление оправдано, а когда — нет

Решение о режиме обновления стоит принимать исходя из характера изменений и требований к доступности базы.

Для регулярных доработок в круглосуточных базах разумно выстроить регламент: динамические обновления — в течение дня по мере необходимости, завершающее обычное обновление — ночью или в выходные по расписанию. Такой цикл сочетает доступность системы и корректное состояние конфигурации базы данных.

Частые вопросы