← На главную

Переход с редакции "Управление торговлей 10.3" на "Управление торговлей 11" — это сложный технологический процесс, который часто сопровождается проблемами производительности, особенно если база данных содержит сотни тысяч элементов справочников. Рассмотрим ситуацию, когда выгрузка из исходной базы проходит успешно, но при загрузке в новую базу процесс "зависает" на определенном этапе (например, на 200 000 из 300 000 позиций номенклатуры), журнал регистрации молчит, а обработка визуально продолжает "крутиться".

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

1. Диагностика зависания через Отладчик

Прежде чем менять настройки сервера или разбивать данные на части, необходимо понять: действительно ли программа "зависла" в бесконечном цикле или она просто очень медленно обрабатывает тяжелый запрос.

Как советуют опытные специалисты, первым делом попробуем выяснить, что именно выполняет система в момент "зависания". Для этого нам потребуется Конфигуратор базы-приемника (УТ 11).

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

После остановки исполнения кода конфигуратор откроет модуль на той строке, которая выполнялась в данный момент. Проанализируем, где мы остановились:

• Если мы попадаем в один и тот же цикл при многократном нажатии "Продолжить" и "Остановить" — скорее всего, имеет место ошибка в алгоритме правил конвертации (зацикливание).
• Если мы попадаем в процедуры записи объектов, проведения документов или расчета итогов — система работает, но ей не хватает ресурсов или транзакция слишком велика.

2. Проблема "одной большой транзакции" и управление памятью

Одной из самых частых причин, почему загрузка 300 000 элементов номенклатуры "вешает" сервер, является попытка системы записать все эти данные в рамках одной транзакции или накопление данных в оперативной памяти.

Штатный помощник перехода часто пытается загрузить огромный пакет данных целиком. Это приводит к тому, что процесс rphost на сервере 1С начинает потреблять всю доступную оперативную память, уходит в файл подкачки (swap), и скорость работы падает практически до нуля.

Решение: Использование обработки «Универсальный обмен данными в формате XML»

Вместо встроенного помощника перехода рекомендуем использовать стандартную обработку УниверсальныйОбменДаннымиXML. Она предоставляет гибкие настройки управления транзакциями.

Рассмотрим порядок действий:

1. Откройте обработку в базе-приемнике.
2. На вкладке настроек найдите опцию "Записывать объекты в транзакции" (или "Количество объектов в транзакции").
3. Установите значение от 100 до 1000.

Это заставит систему фиксировать транзакцию и освобождать оперативную память каждые 100-1000 объектов. Скорость загрузки при этом может вырасти в разы, а риск переполнения памяти исчезнет.

3. Отключение фоновых процессов и индексации

УТ 11, в отличие от УТ 10.3, насыщена регламентными заданиями и механизмами отложенного обновления. Когда вы загружаете поток данных, система пытается сразу же их индексировать (например, обновлять индекс полнотекстового поиска, рассчитывать доступность товаров и т.д.). Это создает блокировки таблиц СУБД.

Перед началом массивной загрузки выполним следующие действия в базе УТ 11:

1. Перейдите в НСИ и администрирование -> Обслуживание -> Регламентные операции.
2. Временно отключите все Регламентные задания.
3. Особое внимание обратите на задания, связанные с полнотекстовым поиском, обновлением агрегатов и отложенным обновлением прав доступа.

Важно: Не забудьте включить регламентные задания обратно после завершения переноса данных.

4. Загрузка данных частями

Если памяти сервера недостаточно даже при использовании разбиения на транзакции, эффективным методом является порционная загрузка данных. Выгружать всё сразу (справочники + остатки) — рискованная стратегия для больших баз.

Разделим процесс на этапы:

1. Сначала выгружаем и загружаем только основные справочники (Виды номенклатуры, Номенклатура, Контрагенты).
2. При выгрузке номенклатуры можно использовать отборы. Например, выгружать по группам (папкам) или видам номенклатуры. Если у вас 300 000 позиций, попробуйте выгружать по 50 000.
3. Только после успешной загрузки НСИ переходим к выгрузке остатков.

Такой подход позволяет локализовать проблему. Если загрузка "споткнется" на конкретной группе товаров, вы быстрее найдете проблемный элемент (например, "битую" ссылку или спецсимволы в названии).

5. Настройки СУБД (MS SQL Server)

Если вы используете клиент-серверный вариант работы, "зависание" на несколько дней может быть связано с разрастанием журнала транзакций.

Проверим настройки SQL Server:

• Модель восстановления (Recovery Model): На время первоначальной загрузки рекомендуется переключить базу данных в режим Simple (Простая). Это предотвратит бесконечный рост лога транзакций (.ldf файла).
• Автоувеличение файлов (Autogrowth): Убедитесь, что шаг приращения файлов базы данных и лога установлен в фиксированное значение (например, 100-500 МБ), а не в процентах. Частые операции расширения файла тормозят запись.

6. Проверка оборудования

Не стоит исключать и аппаратный фактор. УТ 11 значительно требовательнее к ресурсам, чем УТ 10.3. Компьютер или сервер, на котором "летала" 10.3, может оказаться "узким местом" для 11-й версии.

Обратите внимание на:

• Дисковую подсистему: Для УТ 11 наличие SSD дисков (желательно NVMe) является практически обязательным требованием для комфортной работы и быстрой загрузки данных.
• Оперативную память: Процессы rphost на сервере 1С должны иметь достаточный запас памяти.

7. Альтернативные методы обмена

Если стандартный XML-обмен через COM-соединение или файл продолжает сбоить на огромных объемах, можно рассмотреть альтернативные варианты (хотя это требует навыков программирования):

• Использование планов обмена и регистрации изменений для порционной выгрузки.
• Выгрузка в текстовые форматы (JSON/CSV) и написание собственной простой обработки загрузки, которая создает элементы без лишних проверок, свойственных универсальному обмену.

Резюме

Если загрузка зависает:

1. Используем отладчик, чтобы исключить зацикливание кода.
2. Используем обработку УниверсальныйОбменДаннымиXML с настройкой записи в транзакции (по 100-1000 элементов).
3. Отключаем фоновые задания и индексацию в базе-приемнике.
4. Разбиваем выгрузку на логические части (по группам номенклатуры).
5. Проверяем настройки SQL Server (Simple Recovery Model).