При работе с высоконагруженными системами 1С, функционирующими в режиме 24/7, любая задача по изменению метаданных превращается в серьезный вызов. Стандартная процедура добавления даже одного реквизита в табличную часть крупного документа может запустить процесс реструктуризации, который растянется на несколько часов. В условиях круглосуточной отгрузки такое «окно» простоя недопустимо. Проанализируем ситуацию и разберем все доступные способы решения этой задачи: от платформенных механизмов до архитектурных хитростей.
Прежде чем переходить к решениям, разберем механизм работы платформы. В стандартном режиме (особенно на старых версиях платформы, таких как 8.3.10) 1С при добавлении реквизита не просто выполняет команду ALTER TABLE на уровне СУБД. Процесс происходит гораздо сложнее: создается временная таблица с новой структурой, в нее построчно копируются все данные из старой таблицы, затем старая таблица удаляется, а новая переименовывается. На базах объемом в сотни гигабайт и терабайты, где таблицы документов содержат миллионы строк, этот процесс крайне ресурсоемок и медленен.
Рассмотрим возможности платформы 1С, которые появились в более поздних версиях (начиная с 8.3.11). Если у вас есть возможность обновить платформу, это будет самым правильным и безопасным путем. В новых версиях реализован оптимизированный механизм реструктуризации.
Как это работает: Платформа анализирует изменения и, если это возможно, дает команду СУБД выполнить прямое изменение структуры таблицы. Например, добавление колонки, допускающей значение NULL, в MS SQL Server происходит практически мгновенно, так как не требует физической перезаписи всех данных. Чтобы задействовать этот режим, в параметрах информационной базы необходимо установить режим совместимости или явно разрешить использование версии 2 механизма реструктуризации.
Проанализируем ситуацию с точки зрения корпоративного сегмента. Если ваша организация использует лицензии уровня КОРП, вам доступен механизм фонового обновления конфигурации базы данных. Это наиболее технологичный способ решения проблемы для режима 24/7.
Разберем процесс по шагам:
Выясним, как опытные администраторы обходят ограничения платформы, если обновление до КОРП невозможно. Этот метод считается опасным, но крайне эффективным. Он основан на «обмане» конфигуратора 1С.
Суть метода:
Если нам нужно добавить простой реквизит (например, строку или число), мы можем вручную добавить колонку в таблицу базы данных через SQL Management Studio, соблюдая правила именования 1С (например, _Fld1234). После этого, при добавлении реквизита в конфигураторе, платформа увидит, что физическая структура таблицы уже соответствует требуемой, и пропустит длительный этап копирования данных.
Важные предостережения:
_Document150_VT123) и имя нового поля.Посмотрим на ситуацию со стороны разработчика. Если мы не хотим трогать основную огромную таблицу, мы можем вообще отказаться от добавления реквизита непосредственно в документ. Вместо этого создадим вспомогательный объект.
Рассмотрим вариант с созданием Регистра сведений или отдельного справочника, который будет выступать в роли расширения табличной части. Структура такого регистра может быть следующей:
ДокументСсылка (Тип: Ссылка на наш документ).НомерСтроки (Тип: Число).Серия (Нужный нам новый реквизит).Разберем плюсы этого подхода:
Если вы все же решили идти путем стандартной реструктуризации, выясним, как можно ускорить работу SQL сервера. Существует несколько настроек, которые могут сократить время процесса в 2–3 раза:
1. Модель восстановления (Recovery Model):
Переведите базу данных в режим Simple перед обновлением. Это отключит детальное логирование транзакций в LDF файл, что существенно ускорит массовую запись данных.
2. Настройка TempDB:
Реструктуризация активно использует временную базу. Убедитесь, что TempDB расположена на самом быстром диске (лучше всего NVMe SSD) и имеет достаточное количество файлов данных (по числу ядер процессора).
3. Отключение индексов: Проанализируем индексы таблицы. Иногда имеет смысл вручную удалить некластерные индексы в SQL перед реструктуризацией и пересоздать их после. Это избавит систему от необходимости обновлять индексы при каждой вставке строки в новую таблицу.
Если вы выбрали путь использования регистра сведений вместо реструктуризации, разберем пример того, как можно записывать данные серии при проведении документа:
Процедура ПриЗаписиНаСервере(Отказ, ТекущийОбъект, ПараметрыЗаписи)
// Создаем набор записей для нашего вспомогательного регистра
НаборЗаписей = РегистрыСведений.ДополнительныеДанныеТЧ.СоздатьНаборЗаписей();
НаборЗаписей.Отбор.ДокументСсылка.Установить(ТекущийОбъект.Ссылка);
Для Каждого СтрокаТЧ Из ТекущийОбъект.Товары Цикл
НоваяЗапись = НаборЗаписей.Добавить();
НоваяЗапись.ДокументСсылка = ТекущийОбъект.Ссылка;
НоваяЗапись.НомерСтроки = СтрокаТЧ.НомерСтроки;
НоваяЗапись.Серия = СтрокаТЧ.Серия; // Предположим, поле на форме привязано к ТЧ
КонецЦикла;
НаборЗаписей.Записать();
КонецПроцедуры
Выбор метода зависит от ваших ресурсов и критичности простоя:
Помните, что в очень больших базах 1С архитектурная гибкость часто важнее, чем «красивое» дерево метаданных. Иногда хранение данных в связанном регистре — это не «неустойчивая конструкция», а осознанная необходимость для обеспечения высокой доступности системы.