SQL Profiler для 1С: настройка трассировки и поиск медленных запросов

Когда 1С «тормозит», а технологический журнал показывает только общую картину, основным инструментом диагностики становится SQL Server Profiler. Он фиксирует все запросы, которые сервер 1С отправляет в СУБД, с длительностью, текстом SQL, именем пользователя и приложения. По этим данным можно найти конкретный запрос, который блокирует таблицы или выполняется минутами.

Настройка Profiler для 1С имеет особенности: сервер 1С:Предприятия генерирует огромный поток событий, и без правильных фильтров трассировка за минуты вырастает до гигабайтов, а сервер баз данных получает лишнюю нагрузку. Поэтому ключевая задача — заранее ограничить сбор только нужными событиями и только по нужной базе.

Материал рассчитан на клиент-серверный вариант 1С с Microsoft SQL Server. Для файловых баз Profiler неприменим — там нет отдельной СУБД. Если у вас PostgreSQL, используйте расширение pg_stat_statements и логирование медленных запросов вместо Profiler.

Что понадобится перед началом работы

SQL Server Profiler входит в состав SQL Server Management Studio (SSMS) и запускается из меню «Сервис» → «SQL Server Profiler» либо отдельным ярлыком. Для подключения к трассировке нужны права: учётная запись должна иметь разрешение ALTER TRACE на сервере СУБД. Обычно это членство в роли sysadmin.

Подготовьте три вещи: имя базы данных 1С (его видно в консоли кластера серверов 1С в свойствах информационной базы), учётную запись с правами на трассировку и свободное место на диске, куда будет писаться файл трассы. На активно работающей базе трассировка за час может занять несколько гигабайт, поэтому файл лучше размещать не на системном диске.

Уточните также, как воспроизводится проблема: кто из пользователей жалуется, в каком документе или отчёте, в какое время. Это позволит добавить в фильтр имя пользователя или приложение и сократить объём собираемых данных на порядок.

Запуск Profiler и выбор шаблона трассировки

После запуска Profiler нажмите «Файл» → «Создать трассировку» и подключитесь к экземпляру SQL Server, где размещена база 1С. Откроется окно свойств трассировки. В поле «Использовать шаблон» выберите Standard (по умолчанию) — это рабочая отправная точка, которую дальше сократим.

Шаблон Tuning ориентирован на оптимизатор и включает события, которые для поиска медленных запросов 1С избыточны. Шаблон TSQL_Duration ближе к задаче, но в нём нет части полезных столбцов. На практике удобнее взять Standard и вручную убрать лишнее на вкладке «Выбор событий».

Сразу настройте вывод: установите флажок «Сохранить в файл» и укажите путь с достаточным местом. Галочку «Сохранить в таблицу» на рабочем сервере лучше не ставить — запись каждого события в таблицу той же СУБД создаёт дополнительную нагрузку. Максимальный размер файла задайте осознанно, например 1000–5000 МБ, с включённой ротацией файлов.

Какие события выбрать для диагностики 1С

Главная ошибка новичков — оставлять все события шаблона. Для типовых задач 1С достаточно небольшого набора. Основные события: RPC:Completed (завершённые вызовы хранимых процедур — через них идёт большая часть обращений сервера 1С), SQL:BatchCompleted (завершённые пакеты запросов), при необходимости SP:StmtCompleted для детализации внутри процедур.

Для поиска взаимоблокировок добавьте Lock:Deadlock и Lock:Deadlock Chain. Для анализа долгих ожиданий и таймаутов полезны Attention (отменённые запросы) и Errors and Warnings → Exception. События Audit Login/Logout и ExistingConnection в большинстве случаев можно снять — они только раздувают файл.

Из столбцов обязательно оставьте: TextData, Duration, CPU, Reads, Writes, SPID, DatabaseName, LoginName, HostName, ApplicationName, StartTime, EndTime. Именно связка Duration + Reads позволяет отличить запрос, который долго выполняется из-за объёма данных, от запроса, который просто ждёт снятия блокировки.

Настройка фильтров под базу 1С

Фильтры — самая важная часть настройки. Нажмите «Фильтры столбцов» в окне выбора событий и задайте ограничение по базе. Надёжнее фильтровать по DatabaseID, а не по имени: узнать идентификатор можно запросом SELECT DB_ID('ИмяБазы'). В фильтре укажите DatabaseID → Equals → полученное число.

Если проблема у конкретного пользователя, добавьте фильтр по LoginName (учётная запись, под которой сервер 1С ходит в СУБД, часто одна на всех — тогда фильтр бесполезен) или по HostName рабочей станции. Учтите: при работе через сервер 1С в СУБД видно подключение сервера приложений, а не конкретного пользователя 1С. Привязку к пользователю 1С даёт только сопоставление по времени с технологическим журналом.

Для поиска медленных запросов полезен фильтр Duration → Greater than or equal → значение в миллисекундах, например 3000 или 5000. Так в трассировку попадут только запросы длиннее порога, и объём данных резко сократится. Не ставьте порог слишком высоким сразу: запросы по 1–2 секунды, выполняемые тысячами, тоже способны «съесть» производительность.

1. 1
   Откройте Profiler, создайте трассировку, шаблон Standard
2. 2
   Уберите лишние события, оставьте RPC:Completed, SQL:BatchCompleted, при необходимости Deadlock и Attention
3. 3
   Настройте сохранение в файл на диске с запасом места
4. 4
   Добавьте фильтр DatabaseID = ID базы 1С и при необходимости Duration >= порога
5. 5
   Запустите трассировку и воспроизведите проблемную операцию в 1С
6. 6
   Остановите сбор, отсортируйте по Duration и разберите топ запросов

Сбор данных и анализ результатов

Запустите трассировку кнопкой «Выполнить» и попросите пользователя повторить операцию, которая тормозит. Как только операция завершилась — останавливайте сбор. Длительные «профилактические» трассировки на весь день на рабочем сервере не запускайте: это и нагрузка, и риск переполнения диска.

Откройте сохранённый файл и отсортируйте события по убыванию Duration. Возьмите верхние запросы и скопируйте их TextData в SSMS. Для каждого включите отображение фактического плана выполнения и посмотрите, где основная стоимость: сканирование кластерного индекса, key lookup, отсутствующий индекс (SSMS подсвечивает подсказки по missing indexes).

Тексты запросов 1С выглядят непривычно: таблицы вида _Document245, _AccumRgOpt и параметры @P1, @P2. Сопоставить физические имена с объектами конфигурации помогает функция ПолучитьСтруктуруХраненияБазыДанных() в 1С или внешние обработки структуры хранения. Без этого сопоставления трудно понять, какой регистр или документ тормозит.

Параллельно с трассировкой включите технологический журнал 1С с событием DBMSSQL. Сопоставив время и текст запроса в обоих источниках, вы получите контекст 1С: пользователя, операцию и модуль конфигурации, из которого запрос вызван. По одному Profiler этого не видно.

Типичные ошибки и ограничения

Первая ошибка — трассировка без фильтра по базе на сервере, где крутится десяток баз 1С. В результате в файле смешаны запросы всех баз, анализировать это почти невозможно, а нагрузка максимальна. Вторая ошибка — сбор событий StmtCompleted для всего подряд: на активной базе это десятки тысяч событий в минуту.

Третья ошибка — делать выводы по одиночному запуску. Медленный запрос может быть следствием блокировки, нехватки памяти или параллельного регламентного задания. Повторите замер 2–3 раза и сравните Duration с Reads: стабильно высокие чтения говорят о проблеме запроса, скачущий Duration при низких чтениях — о конкуренции за ресурсы.

Ограничение самого инструмента: Profiler считается устаревшим, Microsoft рекомендует Extended Events, а для постоянного мониторинга — Query Store. Profiler хорош как быстрый инструмент разовой диагностики, но не как средство круглосуточного наблюдения. Также помните: трассировка показывает только сторону СУБД, проблемы толстого клиента, сети или сервера 1С в ней не видны.

Альтернативы Profiler для регулярной диагностики

Extended Events — штатная замена Profiler с меньшим влиянием на сервер. Сессия с событием sql_statement_completed и фильтром по database_id и duration решает ту же задачу, но мягче нагружает СУБД. Настройка сложнее, зато сессию можно оставить работающей дольше.

Query Store, включённый на уровне базы, автоматически накапливает статистику по запросам: длительность, потребление ресурсов, планы выполнения. Для поиска регрессий производительности после обновления конфигурации это удобнее разовых трассировок — история уже собрана, ничего запускать не нужно.

Со стороны 1С основной источник — технологический журнал с событиями DBMSSQL, SDBL и TLOCK, а также встроенный замер производительности в конфигураторе. Оптимальная схема: техжурнал даёт контекст 1С, Profiler или Extended Events — картину на стороне СУБД.

Сравнение инструментов

SQL Profiler

Быстрый старт и наглядный интерфейс; подходит для разовой диагностики. Ограничение: заметная нагрузка, инструмент устаревает

Extended Events

Минимальное влияние на сервер, гибкие фильтры; подходит для длительного сбора. Ограничение: сложнее настройка

Query Store

Автоматическая история запросов и планов; удобен для анализа регрессий. Ограничение: нет привязки к пользователю и сессии в моменте

Технологический журнал 1С

Показывает контекст 1С: пользователя, операцию, запрос SDBL. Ограничение: не показывает план и стоимость запроса в СУБД

FAQ

Как узнать, какой пользователь 1С запустил тяжёлый запрос, если в Profiler виден только сервер 1С?

Напрямую — никак: все соединения идут от учётной записи сервера 1С. Включите технологический журнал с событием DBMSSQL и сопоставьте запросы по времени и тексту — там указаны имя пользователя 1С и контекст операции.

Сколько времени можно держать трассировку включённой?

Ориентир — время воспроизведения проблемы плюс небольшой запас, обычно от нескольких минут до получаса. Чем активнее база, тем короче должен быть сбор. Для наблюдения часами используйте Extended Events с жёсткими фильтрами по duration.

Почему в трассировке запросы с непонятными именами таблиц вроде _Document123?

1С хранит данные в таблицах с техническими именами, которые не совпадают с именами объектов конфигурации. Сопоставление даёт функция ПолучитьСтруктуруХраненияБазыДанных() или обработки структуры хранения — по ним видно, какому документу или регистру принадлежит таблица.

Чем заменить Profiler, если база 1С на PostgreSQL?

Используйте расширение pg_stat_statements для статистики по запросам и параметр log_min_duration_statement в postgresql.conf для записи медленных запросов в журнал. Для разбора планов — EXPLAIN ANALYZE по конкретному запросу.

Замедляет ли Profiler работу пользователей 1С?

Да, особенно при широком наборе событий и выводе на экран. Минимизируйте влияние: фильтр по базе и длительности, сохранение только в файл, короткое время сбора. При правильной настройке влияние обычно некритично, но на перегруженном сервере ощутимо.

Какой порог Duration ставить в фильтре для первого сбора?

Практичный старт — 3000–5000 мс: так отсекается фон коротких запросов. Если файл всё равно большой, поднимите порог; если событий почти нет, а жалобы есть — снизьте до 1000 мс и ищите массовые запросы средней длительности.