← На главную

При переносе больших объемов данных (например, при переходе с одной редакции конфигурации на другую, как в случае с ЗУП 2.5 на ЗУП 3.1) процесс загрузки может занимать катастрофически много времени — иногда до нескольких суток. Разберем по шагам, выясним причину медленной работы и рассмотрим подробнее проверенные способы многократного ускорения обмена.

1. Оптимизация на уровне платформы и сервера

Первое, на что стоит обратить внимание — это среда, в которой происходит загрузка. Посмотрим на основные рекомендации по настройке базы и сервера.

1. Обеспечение монопольного доступа. Реальное ускорение можно получить только тогда, когда база находится в абсолютно монопольном доступе. Если загрузка выполняется в клиент-серверном варианте, необходимо исключить влияние фоновых заданий и других сеансов. При малом числе пользователей на сервере рекомендуем включать опцию "одна база на процесс" и заходить одним активным пользователем.
2. Использование транзакций. В типовой обработке "Универсальный обмен данными в формате XML" укажите количество элементов в одной транзакции (оптимально от 100 до 1000). Загрузка по одному объекту или, наоборот, одной огромной транзакцией перегружает СУБД. Порционная запись существенно экономит ресурсы.
3. Временный переход в файловый режим. Как показывает практика, выгрузка базы в файловый режим и запуск загрузки на локальном ПК с мощным процессором (важна высокая тактовая частота, а не количество ядер) и быстрым SSD-накопителем может ускорить процесс в несколько раз. После завершения загрузки базу можно вернуть на SQL-сервер.

2. Оптимизация правил обмена в Конвертации Данных (КД 2.0)

Сами правила часто содержат неоптимальную логику, заставляющую систему выполнять двойную работу. Проанализируем ситуацию с настройками КД.

1. Отказ от лишней перезаписи. Огромное количество времени уходит на перезапись уже существующих в базе объектов, если их реквизиты не менялись. Напишите программный код в обработчиках для сравнения значений свойств объекта из файла с объектом в базе. Записывайте объект только при реальном изменении.
2. Передача объектов по ссылкам. Проверьте настройки ПКС (правил конвертации свойств) ссылочного типа. Убедитесь, что для реквизитов выгружается только уникальный идентификатор (GUID), а не весь объект со всеми своими реквизитами. Также установите галочки "Не замещать существующие объекты в приемнике при загрузке" для справочников, которые уже полностью синхронизированы.
3. Иерархия ПВД (Правил Выгрузки Данных). Выстраивайте ПВД по принципу пирамиды: сначала выгружаются независимые справочники, затем зависимые объекты и только потом документы. Иначе КД будет создавать "ссылки-пустышки", которые затем будут повторно перезаписываться.
4. Кэширование загружаемых документов. Чтобы избежать многократной выгрузки и обработки одних и тех же ссылок (документов-оснований), можно использовать массив для хранения уже выгруженных данных в параметрах обмена:
   Скопировать код

   
   Если Не Отказ И Параметры.ЗагруженныеДокументы.Найти(Источник) = Неопределено Тогда
       Параметры.ЗагруженныеДокументы.Добавить(Источник);
   ИначеЕсли Не Отказ Тогда
       Если Параметры.Комментировать Тогда
           Сообщить("Уже выгружен: " + СокрЛП(Источник), СтатусСообщения.Информация);
       КонецЕсли;
       Отказ = Истина;
   КонецЕсли;
   

3. Настройка конфигурации-приемника

Иногда тормозит не сама Конвертация Данных, а бизнес-логика новой базы. Рассмотрим решения на стороне конфигурации, принимающей данные.

1. Отключение "тяжелых" подписок на события. При загрузке автоматически устанавливается свойство ОбменДанными.Загрузка = Истина. Однако, если в базе добавлены пользовательские подписки или сложный код "ПередЗаписью", в котором забыли поставить проверку на этот флаг, система будет выполнять расчет итогов и бизнес-логику для каждого элемента. Временно закомментируйте или программно отключите такие подписки.
2. Индексирование полей поиска. Если поиск в правилах идет не по GUID, а по строковым или числовым полям (Код, ИНН, Артикул), убедитесь, что эти реквизиты проиндексированы в базе. Отсутствие индекса приводит к полному сканированию таблиц (Table Scan).
3. Отложенное проведение и пересчеты (на примере ЗУП). В конфигурациях ЗУП при записи данных часто вызываются тяжелые алгоритмы (например, пересчет планового ФОТ или кадровой расстановки). Найдите тяжелые процедуры, например УправлениеШтатнымРасписанием.ПрименитьИзменениеНастроекШтатногоРасписания, закомментируйте этот код на время обмена, а после загрузки вызовите процедуру единоразово для всей базы.
4. Разделение логических этапов. Если в исторической базе были ошибки учета (например, неверная привязка к филиалам), не пытайтесь исправить это "на лету" в процессе загрузки через правила. Загрузите данные "как есть", а исправления внесите отдельной обработкой в уже загруженной новой базе до допуска пользователей.

4. Инструменты диагностики и альтернативные подходы

Посмотрим, какие дополнительные инструменты можно применить, если классические методы исчерпаны.

1. Замер производительности. В "Универсальном обмене XML" включите режим отладки, чтобы сгенерировать модуль правил как внешнюю обработку. Запустите ее загрузку через отладчик с включенным замером производительности. Это покажет с точностью до миллисекунды, какая процедура тормозит загрузку.
2. Переход на JSON или свой обмен. Если XML-парсер не справляется с объемом, рассмотрите вариант написания собственного обмена на основе формата JSON, который обрабатывается значительно быстрее.
3. Использование планов обмена. Если перенос носит регулярный характер, используйте штатные механизмы ПланыОбмена для регистрации изменений, чтобы выгружать только новые объекты, не перегружая файлы обмена историческими данными.

Комбинируя монопольный режим, настройку транзакций и аккуратную доработку ПКО на предмет проверок перезаписи, вы сможете ускорить загрузку данных в десятки раз и успешно завершить даже самые масштабные проекты по переносу баз.