← На главную

Переход с редакции ПРОФ на КОРП в программе «1С:Зарплата и управление персоналом» — это не просто смена названия конфигурации, а глубокая техническая трансформация данных. На базах объемом свыше 100 Гб этот процесс часто превращается в проблему: прогресс-бар замирает на начальных этапах, а журнал регистрации фиксирует единичные записи в минуту. Рассмотрим подробнее, почему это происходит и как довести обновление до конца в разумные сроки.

Анализируем причины замедления реструктуризации

Проанализируем ситуацию: в ЗУП КОРП используется более сложная архитектура хранения данных, чем в ПРОФ. Основная нагрузка при переходе ложится на трансформацию справочника Подразделения и связанных с ним регистров. В КОРП-версии введена концепция управленческой структуры, которая требует пересчета всей иерархии подразделений и позиций штатного расписания. Если в вашей базе более 10 000 подразделений (включая архивные), стандартные алгоритмы 1С начинают выполнять тяжелые рекурсивные запросы к базе данных.

Разберем, на каких этапах система чаще всего «спотыкается»:

1. Заполнение новых измерений в регистрах: Регистры Подразделения сотрудников и Место позиции штатного расписания в структуре начинают заполняться с нуля. При большом объеме данных SQL-серверу приходится выполнять гигантское количество операций JOIN.
2. Устаревшая статистика: Если обслуживание базы (Update Statistics) не проводилось непосредственно перед обновлением, планировщик SQL может выбрать неоптимальный план выполнения запроса, что замедляет работу в сотни раз.
3. Индексация: При массовой вставке записей индексы сильно фрагментируются, что приводит к деградации производительности дисковой подсистемы.

Шаг 1: Срочное обслуживание базы данных SQL

Как показывает практика, в 90% случаев проблема решается на уровне СУБД. Даже если ваши администраторы уверяют, что регламентные задания настроены, в процессе тяжелого обновления штатные расписания обслуживания могут не справляться или не запускаться из-за блокировок.

Проанализируем необходимые действия на стороне SQL Server:

• Обновление статистики (Update Statistics): Это критически важно. Выполним полную проверку статистики для всех таблиц, задействованных в обновлении. Это позволит SQL-серверу «увидеть» реальное распределение данных в новых таблицах КОРП.
• Перестроение индексов (Rebuild Index): Если процесс уже идет крайне медленно, попробуем запустить дефрагментацию индексов для наиболее нагруженных регистров сведений.

Посмотрим на пример того, как обслуживание меняет ситуацию: после принудительного запуска обновления статистики скорость появления записей в журнале регистрации обычно возрастает с 1-2 записей в минуту до сотен и тысяч, так как SQL перестает «тупить» при поиске связей между сотрудниками и их позициями.

Шаг 2: Оптимизация настроек SQL-сервера

Выясним причину, по которой сервер может не использовать все свои ресурсы. Для выполнения разовых тяжелых операций по реструктуризации данных рекомендуется изменить некоторые глобальные настройки СУБД.

Параметр MAXDOP (Max Degree of Parallelism): Для баз 1С рекомендуется устанавливать MAXDOP = 1. Однако при очень длительных процессах реструктуризации (когда данные не просто меняются, а пересчитываются заново) временная установка MAXDOP = 0 (использование всех ядер для одного запроса) иногда может ускорить процесс, если дисковая подсистема позволяет. Но будьте осторожны: для постоянной работы 1С значение должно быть равно 1 или числу ядер в одном NUMA-узле.

Модель восстановления (Recovery Model): Обязательно проверим, чтобы модель восстановления базы была установлена в Simple. В режиме Full журнал транзакций (файл .ldf) при переходе на КОРП может мгновенно разрастись до сотен гигабайт, забив всё свободное место на диске и остановив процесс.

Шаг 3: Настройка сервера 1С и технологического журнала

Если обслуживание БД не помогло, перейдем к анализу работы сервера приложений. Разберем по шагам, как локализовать проблему:

1. Проверка ресурсов: Посмотрим через монитор ресурсов Windows, хватает ли серверу 1С оперативной памяти и не упирается ли процессор в 100%. Если SQL и 1С разнесены по разным физическим серверам, попробуем временно развернуть их на одной машине (Shared Memory), чтобы исключить сетевые задержки.
2. Технологический журнал (ТЖ): Настроим сбор ТЖ для событий DBMSSQL и EXCP. Это позволит увидеть конкретный SQL-запрос, на котором «висит» система. Если мы увидим бесконечное выполнение одного и того же запроса, это повод обратиться к отладчику.
3. Отладка в тестовой копии: Запустим обновление в копии базы под отладкой. Используем замер производительности, чтобы найти «узкое место» в коде. Часто это оказываются неоптимизированные циклы в процедурах ОбработкаОбновления.

Шаг 4: Дополнительные меры оптимизации

Существует несколько специфических настроек, которые могут значительно ускорить процесс на базах в 130 Гб и выше:

Очистка версионирования объектов: Перед началом перехода проанализируем размер регистра ВерсииОбъектов. Если он занимает значительную часть базы, его стоит очистить. Система при переходе на КОРП пытается обрабатывать метаданные всех версий, что создает колоссальную нагрузку.

Отключение полнотекстового поиска: Рассмотрим возможность полного отключения индексации полнотекстового поиска на время миграции. Попытки системы обновлять индекс ППС параллельно с массовым изменением данных в таблицах создают лишние блокировки.

Перенос TempDB: Поскольку переход с ПРОФ на КОРП активно использует временные таблицы для сопоставления подразделений, перенесем базу TempDB на самый быстрый доступный диск (NVMe или RAM-диск).

Резюме решения

Если вы столкнулись с тем, что бегунок обновления ЗУП замер на 10%, не спешите прерывать процесс. Сначала выполните обновление статистики и очистку процедурного кэша SQL. В большинстве случаев это «подтолкнет» процесс, и он завершится успешно. Если же база данных продолжает стоять на месте, используйте замер производительности и анализ технологического журнала, чтобы выявить конкретные таблицы, требующие ручного вмешательства или предварительной очистки данных.