← На главную

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

Чем фоновое обновление отличается от динамического обновления

Нередко разработчики путают фоновое обновление конфигурации базы данных с так называемым динамическим обновлением («обновлением на лету»). Рассмотрим принципиальную разницу между ними:

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

Механизм работы: три фазы фонового обновления

Проанализируем поэтапный процесс фоновой реструктуризации, заложенный в платформу 1С:

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

Когда целесообразно применять фоновое обновление

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

1. Жесткие рамки технологического окна (SLA): Если регламент доступности системы позволяет прервать работу пользователей максимум на 10–15 минут, а стандартное обновление базы занимает 4–8 часов из-за огромного объема данных.
2. Изменение структуры гигантских таблиц: Добавление, удаление или изменение типа реквизитов и измерений в многомиллионных таблицах (регистры бухгалтерии, накопления, сведений, документы с тяжелыми табличными частями).
3. Круглосуточный режим работы предприятия: Распределенные филиалы в разных часовых поясах, непрерывные логистические склады, интернет-магазины и кассовые узлы, где остановка базы влечет прямые финансовые убытки.

Системные требования и ограничения механизма

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

1. Клиент-серверный вариант: Механизм поддерживается исключительно в клиент-серверной архитектуре и не работает в файловых базах.
2. Режим совместимости: База данных должна работать без режима совместимости либо с режимом совместимости не ниже версии 8.2.14 (рекомендуется актуальный режим платформы 8.3).
3. Блокировка разработческих операций: Во время выполнения фонового обновления в базе запрещено запускать обычное обновление, менять конфигурацию, выполнять отладку и реконфигурацию агрегатов.
4. Временные рамки: Процесс можно временно приостанавливать, однако хранить незавершенное состояние более регламентированного срока (как правило, до 48 часов) не рекомендуется из-за лавинообразного накопления дельты изменений.

Возможные проблемы и риски фоновой реструктуризации

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

1. Экстремальная нагрузка на дисковую подсистему и процессор: Параллельное копирование терабайтных таблиц и работа служебных триггеров генерируют огромный поток I/O-операций. Если диски СУБД уже загружены на 70–80%, пользователи столкнутся с резким падением быстродействия базы (зависание проведения документов, долгие отчеты).
2. Дефицит дискового пространства и разрастание логов: Из-за одновременного существования старых и теневых таблиц, а также непрерывного логирования операций, база данных и журналы транзакций (файлы LDF в MS SQL или WAL в PostgreSQL) требуют дополнительно от 1.5 до 2 объемов реструктурируемых таблиц. Переполнение диска приведет к аварийной остановке всей СУБД.
3. Затягивание фазы актуализации: Если в обновляемые объекты идет непрерывная высокоинтенсивная запись (например, массовый обмен данными или групповое перепроведение), фаза актуализации может длиться бесконечно, так как поток новых записей будет опережать скорость их переноса.
4. Конфликты блокировок и взаимные блокировки (Deadlocks): Наложение фоновых транзакций переноса данных на тяжелые пользовательские транзакции может приводить к тайм-аутам блокировок и ошибкам параллельной записи.
5. Сложности с монопольным захватом на финальном шаге: Для выполнения третьей фазы база должна быть полностью освобождена. Если в системе выполняется длительное регламентное задание (расчет себестоимости, закрытие месяца или перестроение индексов полнотекстового поиска), войти в монопольный режим не удастся до его принудительного или естественного завершения.

Практические рекомендации по проведению фонового обновления

Чтобы обновление прошло без сбоев и потери данных, придерживаемся следующего алгоритма подготовки:

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