Динамическое обновление базы 1С: как обновить конфигурацию без остановки работы

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

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

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

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

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

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

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

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

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

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

Отдельно учитывайте типовые обновления от фирмы «1С». Крупные релизы почти всегда содержат изменения структуры данных и отложенные обработчики обновления, которые должны выполниться в монопольном режиме. Динамическое обновление здесь уместно только как первый шаг, после которого обязателен полноценный запуск обновления с завершением сеансов.

Подготовка: что сделать до запуска

Первый обязательный шаг — резервная копия. Для файловой базы достаточно скопировать файл 1Cv8.1CD при отсутствии активных записей либо выполнить выгрузку в dt через конфигуратор. Для клиент-серверной базы корректный способ — средства СУБД (MS SQL, PostgreSQL), а не копирование файлов каталога базы на работающем сервере. Динамическое обновление не отменяет рисков: если что-то пойдёт не так, откат возможен только из копии.

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

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

Пошаговое выполнение динамического обновления

Процедура в конфигураторе одинакова для файловых и клиент-серверных баз, различается только способ управления сеансами. Ниже — типовой порядок действий для обновления конфигурации, уже загруженной в основную конфигурацию (после «Обновить конфигурацию» из поддержки или загрузки cf).

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

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

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

"C:\Program Files\1cv8\<версия>\bin\1cv8.exe" DESIGNER /S"Сервер\ИмяБазы" /N"Администратор" /P"Пароль" /UpdateDBCfg -Dynamic+ /Out"C:\logs\update.log"

Ключ -Dynamic+ явно разрешает динамическое обновление, -Dynamic- — запрещает. Параметр /Out пишет журнал выполнения в файл, что обязательно при автоматизации: по журналу проверяют, не потребовалась ли реструктуризация вторым этапом.

Второй этап: реструктуризация после динамического обновления

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

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

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

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

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

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

Ограничения и альтернативы

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

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

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

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