Работа с высоконагруженными системами на платформе 1С:Предприятие 8.3, объем которых превышает 1 терабайт, накладывает серьезные ограничения на процесс обновления конфигурации. Стандартные механизмы реструктуризации, запускаемые через Конфигуратор, могут выполняться днями и даже неделями, что абсолютно неприемлемо для бизнеса с режимом работы 24/7. Разберем детально, почему это происходит и какие инструменты существуют для решения этой задачи.
Казалось бы, добавление абсолютно нового РегистрНакопления не должно занимать много времени, ведь таблица пуста. Однако проанализируем ситуацию глубже. Основная проблема кроется не в самом регистре, а в его регистраторах. Когда мы назначаем существующие документы (например, «Реализация товаров и услуг» или «Поступление товаров и услуг») регистраторами для нового объекта, платформа инициирует изменения в структурах таблиц этих документов.
Рассмотрим подробнее техническую сторону: в СУБД таблицы документов-регистраторов могут содержать сотни миллионов записей. При обновлении конфигурации SQL Server вынужден перестраивать индексы этих таблиц, чтобы обеспечить корректную работу ссылочной целостности и механизмов проведения по новому регистру. Если в базе хранятся Binary Large Objects (BLOB) — картинки, скан-копии документов или другие тяжелые данные — любая модификация таблицы заставляет SQL Server физически перезаписывать огромные объемы данных на диске.
Одним из наиболее эффективных современных способов сокращения времени простоя является использование консольной утилиты платформы. Начиная с последних версий 8.3, разработчики 1С предоставили оптимизированный алгоритм обновления конфигурации базы данных. Выясним, в чем его преимущества.
Ранее расчет изменений и сравнение метаданных могли занимать часы. В режиме v2 этот процесс значительно ускорен. Для запуска процесса на боевой базе проанализируем следующую команду:
ibcmd.exe db update --db-path="C:\Base1C" --db-user="Admin" --v2
Или через исполняемый файл платформы:
1cv8.exe /IBConnectionString "..." /UpdateDBCfg -v2
Использование этого флага позволяет системе задействовать более совершенные алгоритмы сопоставления объектов метаданных с таблицами СУБД, что на базах объемом 200 ГБ — 1 ТБ дает ощутимый прирост производительности уже на этапе подготовки к реструктуризации.
Если в процессе анализа выяснилось, что база раздута из-за хранения изображений или файлов непосредственно в таблицах SQL, это станет «бутылочным горлышком». Проанализируем ситуацию: любая реструктуризация таблицы, содержащей колонку с типом ХранилищеЗначения, превращается в многочасовое копирование данных.
Решение: Перед проведением глобальных изменений структуры рекомендуется выполнить вынос файлов из базы данных в Тома хранения файлов на диске. Это превращает «тяжелую» таблицу в «легкую», где вместо мегабайтных массивов данных хранятся лишь короткие строковые пути к файлам. После такой подготовки время реструктуризации сокращается в десятки раз.
Для критически больших таблиц (сотни гигабайт на одну таблицу) опытные администраторы применяют метод временного исключения данных из процесса реструктуризации. Посмотрим на этот алгоритм пошагово:
INSERT INTO ... SELECT.Важно: Данный метод требует глубокого понимания структуры таблиц 1С (имен полей типа _Fld) и должен выполняться только после успешного тестирования на копии!
Зачастую время выполнения операции упирается в настройки сервера базы данных. Проанализируем параметры, которые помогут нам ускорить процесс:
TempDB возрастает колоссально. Убедимся, что TempDB расположена на самых быстрых SSD/NVMe дисках и разделена на несколько файлов.Simple. Это предотвратит бесконтрольный рост лога транзакций (LDF) и снизит нагрузку на дисковую подсистему.Не забудем про встроенный механизм платформы — Фоновая реструктуризация. Она позволяет выполнять основную часть работы без отключения пользователей. Система создает временные таблицы и постепенно переносит данные, отслеживая текущие изменения. Рассмотрим, как это помогает: блокировка базы происходит только в самом конце процесса для финализации изменений, что сокращает время фактического простоя с дней до минут.
Однако помните, что фоновая реструктуризация создает дополнительную нагрузку на сервер во время работы пользователей, поэтому планируйте ее запуск в периоды минимальной активности.
Проанализировав все доступные методы, мы видим, что проблема «недельной» реструктуризации решаема. Основной залог успеха — это комбинированный подход: использование updatedbcfg v2, подготовка данных (вынос файлов) и грамотная настройка СУБД. Всегда проводите полный цикл тестирования на копии, идентичной по объему и производительности дисковой подсистемы боевой базе, чтобы точно спрогнозировать технологическое окно.