Ситуация, когда проведение партионного учета в 1С:УПП внезапно замедляется в 2–3 раза без видимых изменений в оборудовании или настройках, является классической проблемой для крупных баз данных. Часто стандартные операции обслуживания (индексы, статистика) не дают результата. В этой статье мы подробно разберем, как локализовать «узкое место» и какие неочевидные настройки могут влиять на скорость работы.
Первым делом проанализируем базовые параметры сервера, которые могли измениться незаметно для администратора. Проверим схему электропитания. Часто после обновлений Windows или сброса настроек BIOS сервер переходит в режим "Сбалансированный" (Balanced). Для SQL Server это критично: процессор не успевает мгновенно поднять частоту при выполнении коротких, но интенсивных запросов партионного учета.
Убедимся, что установлена схема "Максимальная производительность" (High Performance). Если сервер виртуальный, проанализируем параметр CPU Ready на стороне гипервизора. Если другие виртуальные машины начали потреблять больше ресурсов, ваша СУБД может простаивать в ожидании физических ядер, что внутри гостевой ОС будет выглядеть как низкая нагрузка при медленной работе.
Разберем ситуацию с загрузкой ядер. В 1С:УПП партионный учет по одной организации практически невозможно распараллелить — это последовательный процесс. Однако важно, как SQL Server обрабатывает отдельные запросы внутри этой процедуры. Рассмотрим параметр max degree of parallelism (MAXDOP). Для систем 1С рекомендуется устанавливать значение 1, чтобы каждый отдельный запрос выполнялся на одном ядре. Это предотвращает накладные расходы на координацию потоков и исключает ожидания типа CXPACKET.
Посмотрим на флаги трассировки, которые помогают оптимизатору запросов:
Партионный учет в УПП активно использует временные таблицы. Если TempDB настроен неверно, возникает конкуренция за страницы распределения. Выясним, соответствует ли количество файлов данных TempDB количеству логических ядер процессора (но обычно не более 8). Все файлы должны иметь одинаковый размер и шаг расширения.
Для версий SQL Server ниже 2016 крайне рекомендуется включить флаги трассировки 1117 (равномерное расширение файлов в группе) и 1118 (выделение полных экстентов). Это значительно ускоряет создание и удаление временных объектов.
Если визуальный мониторинг ресурсов не показывает аномалий, перейдем к глубокой диагностике. Настроим сбор Технологического Журнала (ТЖ), чтобы поймать самые длительные запросы и блокировки. Создадим файл logcfg.xml со следующим содержанием:
<config xmlns="http://v8.1c.ru/v8/tech-log">
<dump create="false"/>
<log location="C:\LOGS\DBMSSQL" history="24">
<event alias="DBMSSQL">
<eq property="Name" value="DBMSSQL"/>
<gt property="Duration" value="1000000"/>
</event>
<event alias="Locks">
<eq property="Name" value="TLOCK"/>
</event>
<event alias="Wait">
<eq property="Name" value="TWAIT"/>
</event>
<property name="all"/>
</log>
</config>
Проанализируем события DBMSSQL с большой длительностью (Duration). Если мы видим один и тот же запрос, который выполняется долго, необходимо исследовать его план в SQL Profiler. Также обратим внимание на TWAIT — это укажет на ожидания блокировок, если пользователи мешают проведению партионки.
Посмотрим на проблему глазами SQL Server. Выясним, чего именно «ждет» сервер при выполнении запросов. Выполним следующий запрос к динамическим представлениям:
SELECT TOP 10
wait_type,
max_wait_time_ms,
wait_time_ms / 1000 AS wait_time_s
FROM sys.dm_os_wait_stats
WHERE wait_type NOT IN ('CLR_SEMAPHORE','LAZYWRITER_SLEEP','RESOURCE_QUEUE','SLEEP_TASK')
ORDER BY wait_time_ms DESC;
Разберем результаты:
.ldf, и убедитесь, что он не перегружен.Проанализируем состояние таблиц итогов. В УПП часто возникают проблемы с записями, у которых по всем ресурсам (количество, сумма) стоят нули, но измерения заполнены. 1С продолжает перебирать эти записи при расчете партий. Выполним тестирование и исправление (ТиИ) с пересчетом итогов. Также проверим, нет ли в базе «хвостов» от незавершенных транзакций или старых версий объектов, которые раздувают таблицы _AccumRegTotals.
Иногда замедление вызвано тем, что SQL Server кэшировал плохой план запроса (Parameter Sniffing). Попробуем выполнить очистку процедурного кэша для конкретной базы:
-- Осторожно: это сбросит планы запросов для всей СУБД
DBCC FREEPROCCACHE;
Если после этой команды скорость проведения временно восстановилась — значит, проблема в планах. В этом случае поможет обновление статистики с полным сканированием (FULLSCAN) для ключевых таблиц регистров накопления: ПартииТоваровНаСкладах, СписанныеТовары и других.
Подводя итог, отметим: если ресурсы сервера свободны, а работа идет медленно — ищите проблему в очередях ожиданий SQL Server и неоптимальных планах запросов, вызванных устаревшей статистикой или неверными настройками TempDB.