← На главную

В процессе разработки и сопровождения конфигураций 1С разработчики регулярно вносят изменения в объекты метаданных. Однако далеко не каждое изменение приводит к физической перестройке таблиц в СУБД. Выясним, что именно вызывает процедуру реструктуризации, как она протекает на техническом уровне и какие существуют способы оптимизации этого процесса для крупных и высоконагруженных информационных баз.

В каких случаях возникает реструктуризация таблиц

Реструктуризация запускается тогда, когда внесенные изменения в конфигураторе затрагивают физическую структуру хранения данных в СУБД. Изменения экспортных процедур, форм или макетов не меняют структуру таблиц, поэтому при их обновлении возможно динамическое обновление без остановки работы базы. Если же меняется структура хранения, платформа вынуждена модифицировать физические таблицы СУБД.

Рассмотрим основные изменения метаданных, приводящие к реструктуризации конкретных таблиц:

1. Изменение состава реквизитов: добавление или удаление реквизитов у справочников, документов, адресации или табличных частей. Изменение реквизита внутри табличной части вызывает реструктуризацию физической таблицы этой табличной части.
2. Изменение параметров типов данных: изменение длины строки (особенно при пересечении порога в 1024 символа, когда поле меняет тип на текстовый блоб), изменение точности или длины чисел, смена состава типов в составном типе данных.
3. Изменение настроек индексации: установление или снятие флагов Индексировать и Индексировать с доп. упорядочиванием, а также изменение порядка измерений в регистрах.
4. Модификация состава регистраторов: удаление документа из списка регистраторов регистра сведений или накопления приводит к реструктуризации (при этом добавление нового регистратора чаще всего проходит без перестройки таблицы).
5. Изменение перечислений: удаление значений из состава перечисления.
6. Изменение иерархии: включение или отключение иерархии в справочнике, а также изменение типа иерархии (с иерархии групп и элементов на иерархию элементов).
7. Изменение параметров системных механизмов: изменение режима совместимости конфигурации, настройки планов обмена, разделения итогов в регистрах накопления и периодичности регистров сведений.

Как устроена классическая процедура реструктуризации

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

1. Создается новая временная таблица в СУБД с обновленной структурой колонок и индексов.
2. Данные из старой таблицы поочередно считываются и записываются в новую таблицу с преобразованием типов (при необходимости).
3. Старая таблица удаляется из базы данных.
4. Новая временная таблица переименовывается и получает имя исходной таблицы.

Разберем основные технические ограничения и особенности этого подхода:

1. Монопольный захват: процесс требует блокировки типа Sch-M (Schema Modification), что делает невозможной работу пользователей с изменяемыми объектами на время обновления.
2. Высокая нагрузка на диски: так как создается временная копия физической таблицы, системе требуется до двухкратного запаса свободного дискового пространства. При этом генерируется огромная нагрузка на журнал транзакций СУБД и служебную базу данных TempDB (в случае MS SQL Server).
3. Последовательная обработка: объекты метаданных обрабатываются поочередно, что на базах размером в сотни гигабайт или терабайты может занимать длительное время.

Оптимизированная и фоновая реструктуризация в 1С 8.3

Для минимизации времени простоя в современных версиях платформы 1С:Предприятие 8.3 реализованы механизмы, упрощающие обновление крупных баз данных.

Оптимизированный механизм реструктуризации (для клиент-серверного режима на MS SQL Server и PostgreSQL) выполняет перенос и преобразование данных прямо на стороне СУБД помощью прямых SQL-запросов, не прогоняя каждую строку через сервер приложений 1С. Это сокращает время выполнения процедуры в разы.

Фоновая реструктуризация позволяет изменять структуру таблиц без прекращения работы пользователей. Процесс разделен на три последовательные фазы:

1. Фаза обработки: основные данные копируются и преобразуются в фоновом режиме. Изменения, вносимые пользователями во время этого процесса, записываются в специальную дельта-таблицу.
2. Фаза актуализации: накопленные в дельта-таблице изменения приводится к актуальному состоянию.
3. Фаза принятия изменений: выполняется кратковременный монопольный захват базы для финальной подмены таблиц.

Инженерные методы для высоконагруженных систем

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

1. Мягкая миграция (Soft Migration): вместо прямого изменения типа или удаления реквизита в конфигурацию добавляется новый реквизит. Заполнение нового поля выполняется фоновыми заданиями небольшой порционностью во время штатной работы пользователей. После успешного переноса данных в следующем релизе старое поле удаляется.
2. Прямая модификация структуры СУБД: администратор базы данных выполняет SQL-команду ALTER TABLE напрямую на стороне СУБД, после чего структура метаданных в 1С подгоняется под фактическое состояние без создания временных таблиц.
3. Оптимизация параметров СУБД: перед проведением масштабной реструктуризации на MS SQL Server модель восстановления базы переводится в режим Simple (Простая) для предотвращения бесконтрольного роста файла журнала транзакций (.ldf).