← На главную

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

Причина поведения платформы: составные ссылочные типы

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

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

Ограничение оптимизированной реструктуризации (v2) для расширений

Многие специалисты рассчитывают на включенный механизм быстрой реструктуризации UpdateDBCfg=v2, который на уровне платформы позволяет изменять составные типы без полного физического перезаписывания данных. Однако важно учитывать ключевое архитектурное ограничение платформы 1С: механизм v2 работает исключительно при обновлении основной конфигурации базы данных. При установке, изменении структуры или удалении расширений платформа всегда принудительно переключается на классический механизм реструктуризации v1.

В режиме v1 платформа выполняет следующие операции:

1. Создает новую физическую временную таблицу (например, _InfoRg...X1) с обновленной структурой колонок и типов.
2. Построчно переносит все данные из исходной таблицы в новую.
3. Переносит связанные данные из вспомогательных таблиц (в СУБД PostgreSQL данные реквизита ХранилищеЗначения, где хранятся сжатые XML-версии объектов, лежат в таблицах TOAST).
4. Заново перестраивает все индексы таблицы.
5. После завершения переноса подменяет таблицы и удаляет старую копию.

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

Что происходит при принудительном завершении процесса

Если процесс реструктуризации длится слишком долго, возникает соблазн снять зависший сеанс в кластере серверов 1С или перезапустить службу. Выясним последствия такого действия:

1. На этапе копирования данных: до нажатия финальной кнопки применения изменений данные копируются вне единой блокирующей транзакции. Если оборвать процесс на этом этапе, сами рабочие данные не пострадают, однако в базе СУБД останутся висеть недозаполненные временные таблицы с постфиксами X1, X2, которые продолжат занимать гигабайты дискового пространства до ручной очистки.
2. На этапе фиксации и переименования таблиц: если прервать операцию в момент подмены имен таблиц и записи новых метаданных в таблицы конфигурации, база может оказаться в поврежденном или несогласованном состоянии, что потребует восстановления из резервной копии.

Способы решения проблемы и ускорения реструктуризации

Способ 1. Очистка и сжатие регистра ВерсииОбъектов

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

1. Перейдем в раздел Администрирование — Общие настройки — История изменений.
2. Выполним удаление устаревших версий объектов, указав допустимый срок хранения (например, оставить версии только за последние 1–3 месяца).
3. Настроим расписание регламентного задания автоматической очистки устаревших версий, чтобы не допускать повторного разрастания.
4. Отключим версионирование для часто меняющихся или вспомогательных документов, по которым аудит правок не требуется.

Важное замечание для баз на PostgreSQL: штатное удаление записей через интерфейс 1С или оператор DELETE не освобождает физическое место на диске из-за механизма MVCC (многоверсионности). Чтобы платформа 1С не вычитывала миллионы «мертвых» строк при последующей реструктуризации, после очистки записей необходимо обязательно выполнить обслуживание таблицы на уровне СУБД с помощью команды VACUUM FULL или утилиты pg_repack.

Способ 2. Встраивание метаданных в основную конфигурацию вместо расширения

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

1. В основной конфигурации механизм быстрой реструктуризации UpdateDBCfg=v2 отработает штатно.
2. Платформа не станет физически копировать сотни гигабайт таблицы ВерсииОбъектов, а лишь обновит описатели типов метаданных.
3. В результате процедура применения изменений займет не несколько часов, а всего пару минут.

Способ 3. Оптимизация параметров PostgreSQL на время регламентных работ

Если структуру расширения изменить нельзя, а данные версионирования необходимо сохранить в полном объеме, сократим время выполнения реструктуризации v1 за счет временной перенастройки параметров СУБД на технологическое окно:

1. Обязательно создадим полную резервную копию базы данных перед началом работ.
2. Увеличим объем памяти для построения индексов, установив параметр maintenance_work_mem в значение от нескольких гигабайт (в зависимости от свободной оперативной памяти сервера).
3. Включим параллельное построение индексов с помощью параметра max_parallel_maintenance_workers (например, задав 4 или 6 воркеров).
4. Временно отключим синхронную запись транзакционного лога на диск: synchronous_commit = off. Это существенно снизит задержки дискового ввода-вывода при массовой вставке строк.
5. Увеличим параметры checkpoint_timeout (например, до 30–60 минут) и max_wal_size, чтобы процесс копирования TOAST-данных не прерывался частыми сбросами контрольных точек на диск.
6. После успешного завершения реструктуризации вернем все скорректированные параметры конфигурационного файла postgresql.conf к стандартным рабочим значениям и перезапустим СУБД.

Также убедимся, что на дисковом накопителе сервера СУБД доступно как минимум 120–150% свободного места от текущего размера таблицы ВерсииОбъектов вместе с индексами, иначе в процессе копирования свободное место исчерпается, и реструктуризация завершится аварийной ошибкой.