Как найти источник тяжелого SQL-запроса в 1С и оптимизировать работу сервера

← На главную

В процессе эксплуатации крупных информационных баз, таких как 1С:Управление производственным предприятием (УПП) 1.3, специалисты часто сталкиваются с ситуацией, когда нагрузка на процессор сервера SQL достигает 100%. При анализе средствами SQL Server Management Studio (SSMS) удается выделить конкретный «тяжелый» запрос, однако его текст на языке SQL сильно отличается от того, что программист привык видеть в конфигураторе 1С. Разберем по шагам, как найти место в коде, инициирующее данный запрос, и как интерпретировать специфические конструкции SQL-транслятора платформы.

Анализ специфики SQL-запроса и трансляции функций 1С

Рассмотрим представленный фрагмент запроса, который вызывает максимальную нагрузку. В нем мы видим сложные конструкции с использованием DATEADD и DATEPART. Проанализируем этот участок:

DATEADD(DAY, CAST(DATEPART(DAY, T1._Q_003_F_005) AS NUMERIC(4)) - 1, DATEADD(MONTH, ...))

Такой громоздкий код является результатом работы платформы 1С по трансляции функции НАЧАЛОПЕРИОДА. Если в исходном запросе 1С вы используете, например, НАЧАЛОПЕРИОДА(Таблица.Дата, ДЕНЬ), то СУБД получает именно такую математическую конструкцию для вычисления даты. Особое внимание уделим фрагменту (CAST(DATEPART(YEAR, ...) AS NUMERIC(4)) - 2000) - 2000. Это явный признак того, что в базе данных используется смещение дат 2000. Платформа прибавляет или вычитает 2000 лет, чтобы корректно обрабатывать даты в SQL Server.

Выясним причину, почему глобальный поиск по строке ДОБАВИТЬКДАТЕ в конфигураторе часто не дает результатов. Дело в том, что SQL-запрос может формироваться динамически или быть частью системы компоновки данных (СКД). Поэтому искать нужно не точное совпадение текста, а логические конструкции:

Использование функции НАЧАЛОПЕРИОДА в запросах.
Соединения таблиц по полям периодов.
Обращение к виртуальным таблицам (ОстаткиИОбороты, СрезПоследних), где параметры дат вычисляются «на лету».

Использование Технологического журнала для точного поиска

Наиболее эффективным и надежным способом определения источника запроса является настройка Технологического журнала (ТЖ). ТЖ позволяет сопоставить SQL-запрос с конкретной строкой кода в модуле 1С. Для этого нам необходимо создать файл конфигурации logcfg.xml в каталоге bin/conf сервера приложений 1С.

Разберем пример настройки ТЖ для отлова конкретного запроса. Нам важно включить событие DBMSSQL и, самое главное, свойство Context, которое покажет стек вызова программного кода.


<config xmlns="http://v8.1c.ru/7.4/config/log">
  <log location="C:\LOGS\SQL_QUERIES" history="2">
    <event>
      <eq property="Name" value="DBMSSQL"/>
      <like property="Sql" value="%DATEADD(DAY,CAST(DATEPART(DAY,T1._Q_003_F_005)%"/>
    </event>
    <property name="All"/>
  </log>
</config>

После активации этой настройки система начнет записывать в логи все SQL-запросы, содержащие указанный фрагмент. В поле Context вы увидите подробную информацию, например:

Context=ОбщийМодуль.ПроцедурыРасчетаСебестоимости.Модуль : 1452 : Запрос.Выполнить()

Это позволит вам мгновенно перейти к проблемному участку кода в конфигураторе.

Специфика УПП 1.3: РАУЗ и временные таблицы

Проанализируем структуру самого запроса. Наличие вставок в таблицы вида #tt25 из #tt21 говорит о том, что выполняется длинная цепочка расчетов с использованием Менеджера временных таблиц. В конфигурации УПП 1.3 такая логика характерна для механизмов РАУЗ (Расширенная аналитика учета затрат).

Посмотрим, какие объекты могут быть задействованы:

Документ Расчет себестоимости.
Обработки проведения по партиям.
Отчеты на базе универсального отчета, использующие сложные вложенные схемы компоновки.

Если запрос содержит 3 ключевых ссылки (организация, склад, номенклатура), скорее всего, это этап распределения затрат или формирования движений по регистру УчетЗатратРегл или УчетЗатрат. В базах объемом более 500 Гб эти таблицы разрастаются, и стандартные алгоритмы могут требовать оптимизации или обновления статистики индексов.

Дополнительные инструменты анализа

Рассмотрим ситуацию, когда Технологический журнал по каким-то причинам включить невозможно (например, из-за риска падения производительности на слабом сервере). В этом случае воспользуемся следующими методами:

Инструментарий разработчика: Существуют специализированные обработки (например, "Статистика запросов MSSQL"), которые позволяют сопоставить текущие активные сессии SQL с метаданными 1С. Они переводят названия таблиц типа _AccumReg1234 в понятные имена РегистрНакопления.Продажи.
SQL Server Management Studio (SSMS): Используйте стандартный отчет "Top Queries by Total CPU Time". Выявив Plan Handle запроса, вы можете посмотреть его план выполнения. Если вы видите Index Scan (сканирование индекса) вместо Index Seek (поиск в индексе), значит, запрос не оптимален и требует добавления индексов или переписывания условий ГДЕ.
Анализ временных таблиц: Если вы видите обращение к #tt, попробуйте найти в коде места, где в запросе 1С используется конструкция ПОМЕСТИТЬ. Именно там закладывается фундамент для последующих тяжелых соединений.

Практические рекомендации по оптимизации

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

Во-первых, необходимо регулярно обновлять статистику. Для баз объемом 600 Гб стандартного задания SQL может быть недостаточно. Настройте ежедневное обновление статистики для наиболее нагруженных таблиц (регистров накопления и сведений).

Во-вторых, проанализируйте возможность выноса тяжелых отчетов на копию базы. Если пользователи формируют отчеты за большие периоды с группировками по дням, это неизбежно приведет к генерации запросов с DATEADD и DATEPART, которые нагружают CPU.

В-третьих, проверьте настройки регламентных заданий. Часто «тормоза» вызваны совпадением времени работы фоновых заданий (например, «Извлечение текста», «Обновление индекса ПП») и активной работы пользователей. Распределите их выполнение по времени.

Подводя итог, отметим, что поиск источника SQL-запроса — это комплексная задача, требующая понимания механизмов платформы 1С. Сочетание глубокого анализа Технологического журнала и понимания бизнес-логики типовых решений (таких как РАУЗ в УПП) позволяет быстро локализовать проблему и найти пути ее решения.