Переход с конфигурации Управление торговлей 11.3 на версию 11.4 (а также аналогичные обновления в ERP 2.4 и КА 2.4) часто сопровождается длительным выполнением дополнительных процедур обработки данных. Одной из самых «тяжелых» операций является дозаполнение регистра сведений СуммыДокументовВВалютеРегл. Этот регистр необходим для корректной работы новых отчетов по выручке и себестоимости, так как в версии 11.4 архитектура хранения управленческих сумм изменилась: теперь данные подготавливаются заранее, а не рассчитываются в момент формирования отчета.
Разберем подробно, почему этот процесс может занимать десятки часов и как мы можем значительно ускорить его выполнение, используя программные и системные настройки.
Процедура РегистрыСведений.СуммыДокументовВВалютеРегл.ОбработатьДанныеДляПереходаНаНовуюВерсию работает по достаточно сложному алгоритму. Проанализируем ситуацию: система перебирает десятки видов документов (около 36 типов), делает выборку данных, выполняет проверки и записывает новые ресурсы — СуммаБезНДСУпр, СуммаНДСУпр и БазаНДСУпр. Проблема усугубляется тем, что в типовых решениях этот процесс часто выполняется в один поток, последовательно обрабатывая миллионы записей.
Кроме того, если база данных работает в виртуализированной среде (например, Hyper-V), неправильная настройка взаимодействия между сервером 1С и SQL Server может привести к критическому падению производительности записи. В мониторе активности SQL это часто проявляется как высокие ожидания типа Latch (кратковременные блокировки в памяти).
Первым делом нам необходимо убедиться, что механизм отложенного обновления работает максимально эффективно. Рассмотрим настройки регламентного задания ОтложенноеОбновлениеИБ. По умолчанию оно может запускаться с большими интервалами или иметь низкий приоритет.
Выполним следующие действия:
В современных релизах (УТ 11.4.3+), где используется новая библиотека стандартных подсистем, мы можем попробовать распараллелить обновление. Проверим наличие константы КоличествоПотоковОбновленияИнформационнойБазы. Если программно установить значение больше 1, система попытается запустить несколько фоновых заданий параллельно:
// Пример программной установки количества потоков
Константы.КоличествоПотоковОбновленияИнформационнойБазы.Установить(4);
Выясним причину высоких ожиданий Latch. Часто это связано с тем, что оптимизатор SQL Server пытается распараллелить простой запрос на запись или выборку, что при архитектуре 1С приводит к конфликтам внутри страниц памяти. Для баз данных 1С настоятельно рекомендуется устанавливать параметр Max Degree of Parallelism (MAXDOP) в значение 1.
Разберем, как это сделать через SQL Server Management Studio:
Как показывает практика, после изменения этого параметра ожидания Latch падают практически до нуля, а скорость записи в регистр СуммыДокументовВВалютеРегл может увеличиться в 5 и более раз.
Также проанализируем состояние статистики. Перед запуском тяжелых обновлений обязательно выполним полное обновление статистики для всей базы данных. Это поможет SQL Server строить оптимальные планы запросов при чтении документов для обработки. Используем скрипт:
-- Обновление статистики для всей базы
EXEC sp_updatestats;
Проанализируем ситуацию, когда сервер приложений 1С и сервер SQL находятся на одном физическом хосте под управлением гипервизора. Если они разнесены по разным виртуальным машинам, обмен данными идет через протокол TCP/IP, что создает дополнительные накладные расходы.
Рассмотрим рекомендации по настройке:
Shared Memory, минуя сетевой стек.MAXDOP, значит, мы уперлись в скорость дисков. Рекомендуется вынести TempDB на максимально быстрые накопители (NVMe SSD).Поскольку регистр СуммыДокументовВВалютеРегл имеет кластерный индекс, состоящий из 7 полей, любая массовая вставка данных приводит к его сильной фрагментации. Рассмотрим план действий в ночное время:
Это позволит избежать лишних операций чтения-записи при вставке новых данных в «раздутые» страницы индекса.
Проанализировав опыт администраторов, можно сделать вывод: если процесс заполнения регистра идет со скоростью 10 записей в секунду — это явный признак технических проблем. После корректной настройки MAXDOP, обновления статистики и выделения ресурсов под фоновые задания, скорость должна вырасти до сотен и тысяч записей в секунду.
Помните, что заполнение регистра СуммыДокументовВВалютеРегл — операция одноразовая. Если база данных очень большая (сотни гигабайт), планируйте переход на выходные дни, предварительно протестировав скорость выполнения на копии базы с аналогичными серверными настройками. Использование MAXDOP = 1 является ключевым фактором успеха в борьбе с внутренними блокировками SQL Server при работе с платформой 1С.