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

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

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

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

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

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

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

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

Главные риски: чем плохо динамическое обновление

Рассинхронизация версий конфигурации между сеансами

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

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

Устаревший кэш и ошибки на клиенте

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

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

Отложенная реструктуризация и риск для данных

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

Отдельный риск — запись данных по старой структуре. Если изменился тип реквизита или состав измерений регистра, а таблица ещё не перестроена, обработчики, рассчитанные на новую структуру, могут работать некорректно. В худшем случае это приводит к частично записанным данным, которые придётся восстанавливать вручную.

Фоновые задания и обмены

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

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

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

Относительно безопасные случаи:

• добавление новых объектов: справочников, документов, отчётов, обработок;
• изменение кода модулей без изменения структуры данных;
• правка форм, макетов, печатных форм;
• добавление новых реквизитов в существующие объекты (платформа обычно относит это к совместимым изменениям, но проверять окно реструктуризации обязательно);
• изменение прав, ролей, настроек интерфейса.

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

Сравнение вариантов

Динамическое обновление

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

Монопольное обновление

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

Отложенное обновление через планировщик

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

Как проверить, что обновление прошло корректно

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

• окно реструктуризации при обновлении было пустым или все отложенные изменения завершены вторым этапом;
• все пользователи перезапустили сеансы — проверить по списку активных сеансов в консоли кластера или в режиме «Администрирование — Активные пользователи»;
• фоновые задания перезапущены и выполняются без ошибок в журнале регистрации;
• ключевые операции (проведение документа, формирование регламентированного отчёта, обмен) выполняются без ошибок;
• при файловой базе — тестирование и исправление не требуется по результатам контрольной проверки.

Контрольные точки

Как проверить результат

Список активных сеансов после обновления

Норма

Все сеансы запущены после момента обновления

Тревожный признак

Есть сеансы, открытые до обновления — они работают со старым кэшем

Журнал регистрации за час после обновления

Норма

Нет ошибок несоответствия версий метаданных и падений фоновых заданий

Тревожный признак

Повторяющиеся ошибки у отдельных пользователей или заданий

Состояние реструктуризации

Норма

Отложенных изменений нет, конфигурация БД соответствует конфигурации поставщика

Тревожный признак

Платформа снова предлагает выполнить реструктуризацию при следующем обновлении

Безопасный порядок обновления рабочей базы

Если обновление содержит реструктуризацию, правильная последовательность выглядит так. Сначала делается резервная копия — для клиент-серверной базы средствами СУБД, для файловой — копирование каталога или выгрузка в dt. Затем пользователям отправляется оповещение, активные сеансы завершаются, блокируются новые подключения и регламентные задания.

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

1. 1
   Сделайте резервную копию базы и убедитесь, что она восстанавливается
2. 2
   Оповестите пользователей и завершите активные сеансы
3. 3
   Заблокируйте новые подключения и регламентные задания
4. 4
   Выполните обновление конфигурации БД в монопольном режиме, примите реструктуризацию
5. 5
   Дождитесь выполнения обработчиков обновления данных
6. 6
   Проверьте журнал регистрации и ключевые операции
7. 7
   Снимите блокировку и разрешите вход пользователям

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

Большинство проблем с динамическим обновлением возникает не из-за самого механизма, а из-за нарушения дисциплины его применения. Характерные просчёты повторяются от проекта к проекту.

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

Что делать, если динамическое обновление уже вызвало проблемы

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

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

При подозрении на порчу данных (документы не проводятся, регистры содержат записи с неожиданными значениями) работу базы следует остановить, выполнить «Тестирование и исправление» в режиме только проверки, оценить масштаб и при необходимости восстановить резервную копию, сделанную до обновления. Самостоятельные правки данных напрямую в таблицах СУБД недопустимы — это почти гарантированно усугубит проблему.

Маршрут решения

Как выбрать действие

Обновление меняет только код, формы или добавляет новые объектыДинамическое обновление допустимо, после него попросите пользователей перезайти

В окне реструктуризации есть хотя бы одна таблицаТолько монопольное обновление после резервной копии

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

Реструктуризация осталась незавершённойКак можно скорее выполните второй этап в монопольном режиме до следующего обновления

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

Можно ли вообще отказаться от динамического обновления?

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

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

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

Что будет, если не выполнить второй этап реструктуризации?

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

Можно ли динамически обновить конфигурацию в файловой базе?

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

Как понять заранее, потребует ли релиз реструктуризации?

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

Динамическое обновление влияет на производительность базы?

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