← На главную

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

Причина реструктуризации: составной тип «ДокументСсылка»

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

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

Рассмотрим, в каких объектах чаще всего встречается тип «все документы»:

1. Регистры накопления — в реквизитах и измерениях партионного учета (например, реквизит ДокументДвижения или ДокументОприходования).
2. Критерии отбора — таблицы критериев отбора перестраиваются, если в состав типов проверяемых реквизитов входит общий тип ссылки на документы.
3. Последовательности документов — изменение общего состава документов конфигурации может затрагивать механизмы регистрации границ последовательностей.
4. Регистры расчета и сведений — реквизиты-регистраторы, основания перерасчетов и периоды действия с неограниченным типом ссылки.

Влияние на рабочую базу данных и возможные риски

Выясним, чем опасна реструктуризация на рабочей («живой») информационной базе и как она влияет на данные:

1. Сохранность данных: сама по себе процедура добавления типа в составной ссылочный реквизит не удаляет и не искажает существующие записи. Значения ссылок в существующих строках остаются неизменными, дополняется лишь диапазон допустимых типов.

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

3. Нагрузка на дисковую подсистему и журнал транзакций: перестроение тяжелых таблиц приводит к лавинообразному росту журнала транзакций (LDF в MS SQL Server или WAL в PostgreSQL) и активному использованию базы tempdb. При нехватке свободного дискового пространства операция завершится критической ошибкой СУБД с последующим откатом транзакции.

4. Особенности в распределенных информационных базах (РИБ): при отправке файла обновления в подчиненные узлы каждый периферийный узел при чтении сообщения выполнит точно такую же реструктуризацию затронутых таблиц.

Рекомендации по оптимизации и безопасному обновлению

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

1. Избегайте типа «все документы» в собственных объектах: при создании новых реквизитов, измерений и ресурсов не выбирайте универсальный тип ДокументСсылка. Указывайте только строгий перечень тех документов, которые действительно могут храниться в реквизите.
2. Используйте объект «Определяемый тип»: в современных конфигурациях для составных типов рекомендуется создавать ОпределяемыйТип с фиксированным списком ссылок. При таком подходе добавление нового документа не вызовет реструктуризацию таблиц до тех пор, пока новый документ явно не будет добавлен в состав определяемого типа.
3. Тестируйте обновление на копии базы: перед применением изменений в рабочей среде обязательно выполните обновление на актуальной копии базы данных с замером точного времени реструктуризации.
4. Контролируйте свободное место на дисках: убедитесь, что на сервере СУБД доступно дисковое пространство, превышающее в 1,5–2 раза объем самых больших перестраиваемых таблиц базы.