Обновление конфигурации без выгона пользователей: что происходит внутри 1С

Динамическое обновление в 1С — это запись изменённой конфигурации в базу данных, пока в ней работают пользователи. Запускается оно в конфигураторе командой Конфигурация → Обновить конфигурацию базы данных (F7): если монопольно заблокировать базу не удалось, платформа предлагает применить изменения динамически.

Новая версия становится доступна только новым сеансам. Те, кто уже работает, остаются на старой версии, пока не перезапустят программу. Так работает механизм в 1С:Предприятии 8.3 и в файловом, и в клиент-серверном варианте.

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

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

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

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

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

Что можно обновить динамически, а что — нет

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

Если в изменениях есть хотя бы одно «структурное», платформа динамическое обновление не выполнит и потребует монопольный режим. Для клиент-серверной базы есть третий путь — фоновое обновление (о нём ниже).

Динамическое обновление в конфигураторе: пошагово

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

1. Внесите изменения в основную конфигурацию и сохраните её (Ctrl+S).
2. Сделайте резервную копию: выгрузку в .dt или копию средствами СУБД. Без копии динамическое обновление в рабочей базе не запускайте.
3. Нажмите F7 или выберите Конфигурация → Обновить конфигурацию базы данных.
4. Платформа попытается установить монопольный режим. Если в базе есть другие сеансы, появится вопрос о динамическом обновлении. Подтвердите его.
5. Если изменения требуют реструктуризации, вместо вопроса будет сообщение о невозможности обновления без монопольного режима. Отмените операцию и планируйте окно обслуживания.
6. После успешного обновления разошлите пользователям просьбу перезапустить 1С. Пока они этого не сделают, работают по старой логике.

Запуск из командной строки

Для регламентных скриптов параметр задают явно. Режим -Dynamic+ разрешает динамическое обновление, -Dynamic- запрещает его:

"C:\Program Files\1cv8\8.3.xx.xxxx\bin\1cv8.exe" DESIGNER /S "srv1c\buh" /N "Администратор" /P "пароль" /UpdateDBCfg -Dynamic+ /Out "C:\logs\update.log"

С -Dynamic- скрипт честно упадёт, если в базе кто-то есть. Для ночных регламентов это лучше: вы узнаете о проблеме из лога, а не от пользователей утром.

Фоновое обновление: когда нужна реструктуризация

В клиент-серверном варианте платформа 8.3 умеет выполнять реструктуризацию в фоне. Пользователи работают, сервер готовит новые таблицы. Монопольный режим нужен только на короткое время в конце, чтобы переключиться на новую структуру.

Параметры командной строки для этого режима:

Практическая схема для большой базы:

1. Днём запускаете -BackgroundStart — сервер начинает перестраивать данные.
2. Если нагрузка мешает работе, ставите паузу через -BackgroundSuspend, вечером продолжаете.
3. Ночью, когда пользователей нет, выполняете -BackgroundFinish.

Вместо многочасового окна простоя получается короткое — на завершающий шаг.

Три режима обновления: что выбрать

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

Сервис обновлений в режиме 1С:Предприятия

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

В типовых конфигурациях на БСП (БП 3.0, ЗУП 3.1, УТ 11 и другие) обновление настраивается в разделе Администрирование → Интернет-поддержка и сервисы. Там подключают интернет-поддержку (логин и пароль портала 1С) и включают автоматическую проверку обновлений.

Цепочка выглядит так:

1. Программа по расписанию обращается к серверам обновлений 1С и сравнивает свой релиз с актуальным.
2. Найдено обновление — администратору показывается оповещение.
3. Помощник обновления скачивает файлы, при необходимости — несколько промежуточных релизов подряд.
4. Установка выполняется при завершении работы или в назначенное время. Перед ней программа блокирует вход и завершает сеансы.
5. При первом запуске после установки выполняются обработчики обновления данных. Часть из них работает отложенно, в фоне, уже при работе пользователей.

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

Если интернета на сервере нет

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

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

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

Здесь чаще всего и возникают вопросы в отдел ИТ.

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

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

Ошибки при обновлении и их диагностика

Журнал регистрации — главный источник фактов. Открывается в конфигураторе через Администрирование → Журнал регистрации или в режиме предприятия в разделе Администрирование → Обслуживание. Отбирайте по периоду обновления и уровню «Ошибка».

Как обновлять на ходу и не потерять данные

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

Перед обновлением

• ✅ Свежая резервная копия: .dt для файловой базы, бэкап средствами СУБД для серверной.
• ✅ Изменения сначала проверены на копии рабочей базы, а не только в конфигураторе разработчика.
• ✅ В изменениях нет правок проведения документов, которые сейчас массово вводятся. Такие правки лучше применять после закрытия рабочего дня.

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

• ❌ Закрытие месяца , расчёт зарплаты, регламентные обработки в процессе.
• ❌ Правки, которые меняют формат данных в реквизитах типа «Строка» или «Хранилище значения»: старые сеансы будут писать данные в прежнем формате.
• ❌ Изменения прав ролей, если нужно срочно отозвать доступ: в старых сеансах права действуют до перезапуска. Для срочного отзыва сеанс пользователя придётся завершить.

После обновления

• ✅ Предупредить пользователей о перезапуске.
• ✅ Проверить журнал регистрации на ошибки в первые 15–30 минут.
• ✅ Если правки затронули проведение — перепровести документы, введённые старыми сеансами за это время.

Хранилище конфигурации и обновление

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

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