Каждый разработчик крупных информационных систем на платформе 1С рано или поздно сталкивается с ситуацией, когда обычное добавление одного нового реквизита в документ или справочник превращается в многочасовое ожидание завершения обновления базы данных. Особенно остро эта проблема стоит в высоконагруженных системах, работающих в режиме 24/7 (например, в медицинских учреждениях, крупных торговых сетях или на промышленных предприятиях), где технологическое окно для обслуживания базы жестко ограничено.
В этой статье мы подробно разберем, почему стандартный механизм реструктуризации платформы 1С может работать медленно, и рассмотрим все возможные пути решения этой проблемы: от архитектурных изменений в метаданных до тонкой настройки СУБД и "хитрых" низкоуровневых манипуляций с таблицами SQL.
Давайте разберем по шагам, что происходит под капотом СУБД при классической реструктуризации (так называемой версии v1), когда вы добавляете новый реквизит в существующую таблицу метаданных:
INSERT INTO создает колоссальную нагрузку на дисковую подсистему и процессор сервера.Если таблица содержит миллионы записей, а база эксплуатируется уже более 10 лет, этот процесс гарантированно приведет к простою системы. Ниже мы детально проанализируем, как решить эту проблему различными методами.
---
Начиная с версии платформы 8.3.11, разработчики 1С представили оптимизированную версию механизма реструктуризации базы данных (v2). Этот инструмент доступен как на лицензиях уровня ПРОФ, так и на КОРП.
В отличие от старого построчного копирования, механизм v2 пытается выполнить изменения "на месте" с помощью SQL-команд быстрого изменения структуры, таких как ALTER TABLE ADD COLUMN. Для СУБД добавление колонки, допускающей значение NULL, выполняется практически мгновенно на уровне изменения метаданных таблицы СУБД, без физической перезаписи строк данных.
Для того чтобы задействовать этот механизм, выполним следующие шаги по его настройке:
Шаг 1. Установка Java Runtime Environment (JRE)
Для работы нового оптимизатора на сервере приложений 1С обязательно должна быть установлена Java 8. Обратите внимание на разрядность: если служба сервера 1С работает в 64-битной архитектуре, то и JRE необходимо устанавливать строго 64-битную.
Шаг 2. Настройка конфигурационного файла conf.cfg
Нам потребуется прописать специальный параметр, указывающий платформе использовать новый механизм при обновлении. Откроем конфигурационный файл conf.cfg, расположенный в каталоге установки платформы (например, C:\Program Files\1cv8\conf\conf.cfg) на сервере и на компьютере разработчика, с которого запускается обновление, и добавим туда строку:
UpdateDBCfg=v2
Шаг 3. Использование параметров командной строки
Если обновление конфигурации базы данных выполняется в автоматическом режиме через скрипты автоматизации (CI/CD), мы можем явно передать платформе параметр принудительного использования нового режима:
1cv8.exe DESIGNER /F "ПутьКБазе" /N "Администратор" /P "Пароль" /UpdateDBCfg -v2
В современных релизах платформы (начиная с 8.3.18) версию механизма реструктуризации можно также переключить визуально в свойствах информационной базы прямо в диалоговом окне обновления конфигурации в Конфигураторе.
Важное ограничение: Механизм v2 работает максимально быстро только тогда, когда изменения тривиальны (например, добавление нового реквизита примитивного типа). Если вы меняете тип существующей колонки или делаете тип составным, СУБД все равно запустит длительную перезапись данных таблицы.
---
Если бизнес-процессы вашей организации не позволяют блокировать работу пользователей даже на полчаса, лучшим решением станет изменение архитектуры хранения данных. Вместо добавления реквизитов непосредственно в тяжелую таблицу документа мы вынесем их в подчиненный регистр сведений.
Рассмотрим этот подход подробнее:
ДополнительныеСведенияДокументов).ДокументСсылка.ИмяВашегоДокумента).При таком подходе добавление новых полей в регистр сведений не затронет основную многомиллионную таблицу документов. Сама структура документа останется неизменной, а значит, обновление пройдет мгновенно. Давайте посмотрим на пример реализации чтения и записи таких данных на форме документа.
В модуле формы документа напишем следующий код:
&НаСервере
Процедура ПриЧтенииНаСервере(ТекущийОбъект)
// Читаем дополнительные реквизиты из нашего регистра сведений
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ДополнительныеСведения.НовыйПараметр1 КАК НовыйПараметр1,
| ДополнительныеСведения.НовыйПараметр2 КАК НовыйПараметр2
|ИЗ
| РегистрСведений.ДополнительныеСведенияДокументов КАК ДополнительныеСведения
|ГДЕ
| ДополнительныеСведения.Документ = &Документ";
Запрос.УстановитьПараметр("Документ", ТекущийОбъект.Ссылка);
Выборка = Запрос.Выполнить().Выбрать();
Если Выборка.Следующий() Тогда
ЭтотОбъект.НовыйПараметр1 = Выборка.НовыйПараметр1;
ЭтотОбъект.НовыйПараметр2 = Выборка.НовыйПараметр2;
КонецЕсли;
КонецПроцедуры
&НаСервере
Процедура ПередЗаписьюНаСервере(Отказ, ТекущийОбъект, ПараметрыЗаписи)
// Записываем измененные данные обратно в регистр сведений при сохранении документа
НаборЗаписей = РегистрыСведений.ДополнительныеСведенияДокументов.СоздатьНаборЗаписей();
НаборЗаписей.Отбор.Документ.Установить(ТекущийОбъект.Ссылка);
НоваяСтрока = НаборЗаписей.Добавить();
НоваяСтрока.Документ = ТекущийОбъект.Ссылка;
НоваяСтрока.НовыйПараметр1 = ЭтотОбъект.НовыйПараметр1;
НоваяСтрока.НовыйПараметр2 = ЭтотОбъект.НовыйПараметр2;
НаборЗаписей.Записать(Истина);
КонецПроцедуры
Для конфигураций, построенных на базе Библиотеки Стандартных Подсистем (БСП), аналогичный функционал уже реализован "из коробки" под названием "Дополнительные реквизиты и сведения". Использование механизмов БСП позволяет пользователям добавлять свойства объектам вообще без изменения метаданных в конфигураторе.
---
Если мы вынуждены проводить штатную реструктуризацию большой таблицы, мы можем временно перенастроить параметры сервера базы данных SQL, чтобы максимально ускорить операции ввода-вывода и задействовать все аппаратные мощности сервера на период технологического окна.
Рассмотрим две ключевые настройки для MS SQL Server:
Параметр параллелизма MAXDOP (Max Degree of Parallelism)
В обычной продуктивной работе для 1С рекомендуется устанавливать значение параллелизма MAXDOP = 1, чтобы тяжелые и неоптимальные запросы отдельных пользователей не парализовали все доступные ядра процессора. Однако при выполнении реструктуризации нам, наоборот, нужно выжать максимум из многопоточности.
Перед запуском обновления конфигурации выполним следующий SQL-запрос для задействования всех ядер процессора сервером SQL:
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'max degree of parallelism', 0; -- 0 означает использование всех доступных ядер
RECONFIGURE;
После завершения реструктуризации крайне важно вернуть этот параметр в исходное значение 1 (или иное рекомендованное для вашей СУБД значение), чтобы избежать проблем с конкурентным доступом пользователей в рабочее время.
Перевод СУБД в простую модель восстановления (Simple Recovery Model)
По умолчанию крупные базы данных работают в полной модели восстановления (FULL), фиксируя каждую транзакцию в лог-файле транзакций (.ldf). При реструктуризации миллионов записей файл транзакций мгновенно раздувается до гигантских размеров, перегружая диски.
На время выполнения реструктуризации переведем базу в режим SIMPLE, который сводит к минимуму ведение логов транзакций:
ALTER DATABASE [ИмяВашейБазыДанных] SET RECOVERY SIMPLE;
По завершении процедуры обновления обязательно вернем базу в исходный режим и сразу же создадим полную резервную копию:
ALTER DATABASE [ИмяВашейБазыДанных] SET RECOVERY FULL;
---
Этот метод является неофициальным, требует от системного администратора и разработчика предельной концентрации и понимания структуры СУБД 1С. Однако он позволяет обновить конфигурацию с тяжелой реструктуризацией таблицы объемом в сотни гигабайт буквально за 5 минут.
Суть метода заключается в обмане платформы 1С: мы подсовываем ей пустую таблицу-пустышку вместо реальной тяжелой таблицы, платформа мгновенно выполняет реструктуризацию на пустых данных, после чего мы возвращаем реальные данные на место, обновив их структуру средствами самой СУБД.
Проанализируем этот процесс по шагам на примере таблицы документа _Document123 и нового реквизита _Fld9999:
Шаг 1. Переименование оригинальной таблицы в СУБД
В консоли MS SQL Server переименовываем нашу реальную заполненную таблицу в резервное имя:
EXEC sp_rename '_Document123', '_Document123_temp';
Шаг 2. Создание пустой таблицы-заглушки
Создаем абсолютно пустую таблицу с оригинальным именем, копируя структуру оригинальной таблицы (без индексов и данных):
SELECT TOP 0 * INTO _Document123 FROM _Document123_temp;
Шаг 3. Запуск обновления в конфигураторе 1С
Запускаем обновление конфигурации базы данных в Конфигураторе 1С. Платформа видит, что таблица _Document123 пуста. Она мгновенно добавляет в ее метаданные новую колонку _Fld9999 и успешно завершает процесс реструктуризации.
Шаг 4. Добавление новой колонки в реальную таблицу СУБД
Пока 1С считает, что все готово, мы средствами СУБД добавляем новую колонку в нашу реальную таблицу _Document123_temp, сохраненную на шаге 1. Поскольку колонка допускает значение NULL, SQL Server выполнит эту операцию за доли секунды без перезаписи страниц памяти:
ALTER TABLE _Document123_temp ADD _Fld9999 NVARCHAR(100) NULL;
Шаг 5. Обратная замена таблиц
Удаляем временную пустую таблицу _Document123, которую создала платформа 1С, и возвращаем на ее место нашу обновленную реальную таблицу:
DROP TABLE _Document123;
EXEC sp_rename '_Document123_temp', '_Document123';
В результате этих действий структура базы данных полностью соответствует конфигурации 1С, при этом тяжелого копирования данных внутри SQL-сервера не происходило вообще. Этот трюк экономит часы простоя информационной системы.
Внимание: Перед проведением подобных операций на работающей базе данных обязательно сделайте полную резервную копию и предварительно отработайте всю последовательность шагов на тестовой копии вашей базы данных!
---
Проблема долгой реструктуризации больших таблиц в 1С успешно решается как стандартными административными путями, так и изменением архитектуры разработки. Внедрение механизма оптимизации реструктуризации v2 совместно с правильной архитектурой метаданных (вынос изменяемых свойств в регистры сведений или использование механизмов JSON) позволяет навсегда забыть о многочасовых простоях и жалобах со стороны пользователей информационной системы.