Администрирование · 10 мин
Динамическое обновление 1С: как работает и когда его безопасно применять
Как работает динамическое обновление конфигурации 1С: механизм, пошаговый порядок, ограничения, типичные ошибки и безопасные альтернативы для рабочих баз.
Динамическое обновление — это режим конфигуратора 1С, при котором изменения конфигурации применяются к информационной базе без отключения пользователей. Платформа создаёт новую версию конфигурации базы данных и переключает на неё сеансы пользователей при их следующем обращении к серверу, не прерывая текущую работу. Это удобно для мелких доработок в разгар рабочего дня, но у механизма есть жёсткие ограничения, игнорирование которых приводит к ошибкам у пользователей и повреждению данных.
Механизм доступен только в клиент-серверном варианте работы с СУБД (MS SQL Server, PostgreSQL и других поддерживаемых). В файловых базах динамическое обновление невозможно — платформа предложит только монопольный режим. Кроме того, динамически применяются далеко не все изменения: если правки затрагивают структуру данных, платформа потребует обычное обновление с завершением сеансов.
Понимание того, как именно платформа выполняет динамическое обновление, помогает администратору заранее оценить, пройдёт ли конкретная доработка «на лету», какие данные придётся обрабатывать отдельно и как проверить, что обновление завершилось корректно.
Как платформа выполняет динамическое обновление
Когда администратор запускает динамическое обновление, сервер 1С формирует новую версию конфигурации базы данных, не разрушая текущую. Активные сеансы продолжают работать со старой версией конфигурации, а новые сеансы подключаются уже к обновлённой. Переключение происходит прозрачно: пользователь не замечает момента смены версии.
Изменения структуры метаданных, которые не требуют реструктуризации таблиц (например, добавление нового объекта метаданных без изменения существующих), применяются сразу. Если же изменения затрагивают существующие таблицы — добавление реквизита в справочник, изменение типа поля — платформа регистрирует необходимость реструктуризации и выполняет её в фоновом режиме либо откладывает до монопольного обновления, в зависимости от характера правок и настроек.
Ключевой момент: одновременно в базе существуют две версии конфигурации. Это создаёт расход памяти на сервере и потенциальный источник конфликтов, если старая и новая логика по-разному обрабатывают одни и те же данные. Поэтому динамическое обновление рассчитано на короткий переходный период, а не на постоянную работу в «двойном» состоянии.
Какие изменения можно применить динамически, а какие — нет
Безопасно динамически применяются изменения программного кода: правки модулей, форм, макетов, ролей, новые отчёты и обработки. Также обычно проходят добавление новых объектов метаданных и изменение свойств, не влияющих на физическую структуру таблиц.
Невозможны или крайне нежелательны динамически изменения, требующие реструктуризации существующих данных: удаление реквизитов, изменение типов полей, изменение состава измерений регистров, сокращение длины строковых полей. Платформа либо откажется выполнять такое обновление динамически, либо выполнит его с отложенной реструктуризацией, что требует последующего контроля.
Что обновлять динамически, а что — монопольно
Подходит для динамического обновления. Риск минимален, пользователи не заметят перехода.
Обычно применяется динамически, но новые объекты недоступны старым сеансам до их перезапуска.
Требует реструктуризации. Динамически не выполняется либо выполняется с отложенной обработкой — безопаснее монопольный режим.
Только монопольное обновление. Динамическое применение грозит ошибками у работающих пользователей.
Пошаговый порядок динамического обновления
Перед началом убедитесь, что база работает в клиент-серверном режиме и у вас есть свежая резервная копия. Даже «безопасное» динамическое обновление без бэкапа — неоправданный риск: откатить применённую конфигурацию базы данных штатными средствами нельзя.
Загрузите или внесите изменения в конфигурацию, затем в конфигураторе откройте «Конфигурация → Обновить конфигурацию базы данных». Если платформа определит, что изменения допускают динамическое применение, в диалоге появится соответствующий вариант. Выберите его и подтвердите запуск.
После завершения проверьте журнал регистрации на наличие ошибок и убедитесь, что фоновые задания обработки данных (если они были запланированы) выполнились успешно. Попросите нескольких пользователей перезапустить сеансы и проверить изменённый функционал.
- 1Сделайте резервную копию базы средствами СУБД или выгрузку dt
- 2Внесите изменения в конфигурацию и выполните проверку конфигурации
- 3Откройте «Конфигурация → Обновить конфигурацию базы данных»
- 4Выберите динамическое обновление, если платформа его предлагает
- 5Дождитесь завершения и проверьте журнал регистрации на ошибки
- 6Проконтролируйте выполнение отложенных процедур обработки данных
- 7Попросите пользователей перезапустить сеансы и проверьте работу функционала
Ограничения и риски механизма
Главное ограничение — режим работает только на клиент-серверной архитектуре. Второе существенное ограничение: пользователи со старыми сеансами продолжают работать по старой логике. Если новая версия конфигурации меняет правила записи данных, старые сеансы могут записать данные в устаревшем формате, что приведёт к рассогласованию.
Динамическое обновление увеличивает нагрузку на сервер: поддерживаются две версии конфигурации, а отложенная реструктуризация выполняется параллельно с работой пользователей. На больших базах это может заметно снизить отзывчивость системы. Также нельзя запускать второе динамическое обновление, пока не завершилось предыдущее — платформа это заблокирует или поведёт себя непредсказуемо.
Отдельный риск — фоновые задания. Задания, запущенные до обновления, работают со старым кодом. Если логика задания изменилась, оно может отработать некорректно. Рекомендуется после обновления перезапустить регламентные и фоновые задания.
Как проверить, что обновление прошло корректно
Первичный контроль — журнал регистрации: отфильтруйте события за период обновления и убедитесь в отсутствии ошибок реструктуризации и фоновых заданий. Затем проверьте, что новые сеансы получают обновлённую версию конфигурации — это видно по поведению изменённого функционала у пользователя, который перезапустил клиент.
Если обновление включало отложенные процедуры обработки данных, проверьте их статус. В типовых конфигурациях для этого есть специальные инструменты (например, раздел «Результаты обновления программы»). Незавершённые процедуры означают, что часть данных ещё не обработана, и некоторые функции могут работать некорректно.
Как проверить результат
Нет ошибок реструктуризации и сбоев фоновых заданий
Ошибки обновления конфигурации или обрыв фоновых процедур
После перезапуска сеанса доступен новый функционал
Изменения не видны даже после перезапуска клиента
Все процедуры завершены успешно
Процедуры зависли или завершились с ошибкой
Задания выполняются по расписанию без ошибок
Задания падают с ошибками после обновления
Типичные ошибки администраторов
Самая распространённая ошибка — обновление без резервной копии. Второе место занимает попытка динамически применить изменения структуры данных в надежде, что «платформа справится». Третья типичная проблема — игнорирование старых сеансов: пользователи сутками не перезапускают клиент и продолжают работать по устаревшей логике.
Альтернативы: когда лучше монопольное обновление
Монопольное обновление остаётся основным способом для релизов, затрагивающих структуру данных, и для крупных обновлений типовых конфигураций. Оно требует завершения всех сеансов, но гарантирует целостность: реструктуризация выполняется последовательно, без параллельной работы пользователей.
Для минимизации простоя используют обновление через копию базы: релиз сначала разворачивают и тестируют на копии, отрабатывают отложенные обработчики, а затем повторяют на рабочей базе по проверенному сценарию. Это сокращает время простоя и снижает вероятность сюрпризов.
Как выбрать способ обновления
Частые вопросы о динамическом обновлении 1С
Почему платформа не предлагает динамическое обновление?
Чаще всего причина в том, что изменения требуют реструктуризации существующих таблиц или база работает в файловом режиме. Также вариант недоступен, если предыдущее динамическое обновление ещё не завершено.
Можно ли отменить динамическое обновление после запуска?
Штатной отмены нет. Применённую конфигурацию базы данных можно заменить только восстановлением из резервной копии, поэтому бэкап перед обновлением обязателен.
Заметят ли пользователи момент обновления?
Нет, сеансы не прерываются. Но пользователи со старыми сеансами не увидят изменений до перезапуска клиента, а при изменении логики записи данных старые сеансы могут работать некорректно.
Что делать, если после обновления падают фоновые задания?
Перезапустите фоновые и регламентные задания — запущенные до обновления задания используют старый код. Если ошибки повторяются, смотрите текст ошибки в журнале регистрации и проверяйте совместимость нового кода с данными.
Подходит ли динамическое обновление для перехода на новый релиз типовой конфигурации?
Как правило, нет. Релизы типовых конфигураций почти всегда содержат изменения структуры данных и отложенные обработчики, поэтому выполняются монопольно, желательно после тестирования на копии базы.
Влияет ли динамическое обновление на производительность?
Да. Пока существуют две версии конфигурации и идёт отложенная реструктуризация, нагрузка на сервер выше обычной. На больших базах обновление лучше запускать в периоды низкой активности.
Что важно запомнить
Динамическое обновление — инструмент для мелких правок кода в клиент-серверных базах, а не универсальная замена монопольному режиму. Всегда делайте резервную копию, проверяйте журнал регистрации и отложенные обработчики, перезапускайте сеансы и фоновые задания. Изменения структуры данных выполняйте монопольно после теста на копии.