Почему SQL Profiler не видит запросы из 1С и как это исправить?

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

В этой статье мы подробно разберем, почему возникает эта техническая проблема, проанализируем внутренние механизмы сетевого взаимодействия MS SQL Server и 1С, а также рассмотрим пошаговые инструкции по ее устранению.

В чем кроется причина проблемы? Разбираем сетевые протоколы

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

Существует три основных сетевых протокола для взаимодействия клиентских приложений (в данном случае сервера 1С) с MS SQL Server:

1. Shared Memory (LPC — Local Procedure Call). Это протокол общей памяти. Он используется автоматически, когда в качестве адреса сервера СУБД указан localhost, локальный IP-адрес 127.0.0.1 или просто точка .. Данный протокол является самым производительным (прирост скорости работы может достигать 10–15%), поскольку данные не упаковываются в сетевые пакеты, а передаются напрямую через оперативную память компьютера.
2. TCP/IP. Стандартный сетевой протокол. Он задействуется, когда подключение идет по сетевому имени компьютера (имени хоста, например, SRV-WORKSTATION) или внешнему IP-адресу машины в локальной сети.
3. Named Pipes (Именованные каналы). Альтернативный протокол взаимодействия через локальные или сетевые каналы Windows, который используется реже.

Проблема «невидимости» запросов в SQL Profiler чаще всего возникает из-за несовпадения протоколов или экземпляров СУБД. Если в настройках базы данных в консоли кластера 1С прописан адрес localhost, сервер 1С подключается к СУБД по сверхбыстрому протоколу Shared Memory. В то же время, если сам SQL Profiler или среда SQL Server Management Studio (SSMS) запущены с подключением по реальному имени хоста (компьютера), они работают через сетевой стек TCP/IP.

В некоторых конфигурациях операционной системы и служб SQL Server, сессия трассировки, запущенная под сетевым протоколом TCP/IP, физически не может перехватить низкоуровневые сообщения, проходящие через локальный протокол Shared Memory. Еще более критичная ситуация возникает, когда на компьютере установлено несколько экземпляров (инстансов) SQL Server. В этом случае обращение к localhost и к имени компьютера может вести на совершенно разные экземпляры СУБД (например, основной экземпляр Developer и скрытый экземпляр SQL Express, установленный сторонним софтом).

Шаг 1. Проверяем настройки подключения в кластере 1С

Для начала нам необходимо выяснить, как именно прописано подключение к СУБД на стороне сервера «1С:Предприятие». Выполним следующие действия:

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

Если там написано localhost, 127.0.0.1 или ., то сервер 1С общается со СУБД через общую память. Если указано имя компьютера (например, Server-PC), то взаимодействие идет по протоколу TCP/IP.

Шаг 2. Выравниваем адреса подключения

Чтобы SQL Profiler гарантированно перехватывал запросы, необходимо настроить единообразие подключений. Самый надежный способ — перевести оба приложения на работу по имени хоста. Это заставит весь трафик проходить через сетевой стек TCP/IP, который Profiler отслеживает без каких-либо затруднений.

Выполним перенастройку:

1. В свойствах информационной базы 1С в поле «Сервер баз данных» заменим localhost на реальное имя вашего компьютера (узнать его можно в свойствах системы Windows).
2. Перезапустим службу сервера «1С:Предприятие», чтобы изменения вступили в силу, а все старые кэшированные соединения закрылись.
3. Запустим SQL Server Management Studio (SSMS) и в окне авторизации укажем в качестве имени сервера то же самое имя компьютера, которое мы прописали в 1С.
4. Из меню SSMS («Сервис» -> «SQL Server Profiler») запустим утилиту трассировки, подключившись к СУБД под тем же именем хоста.

После выравнивания адресов запустим трассировку заново и проверим работу в 1С. Запросы должны начать мгновенно отображаться на экране.

Шаг 3. Глубокая диагностика активных соединений с помощью SQL

Если мы хотим точно удостовериться, по каким именно протоколам и к какому экземпляру СУБД сейчас подключены наши сессии 1С, выполним специальный диагностический запрос в SSMS. Этот запрос обращается к системным динамическим представлениям СУБД и возвращает детальную информацию обо всех текущих подключениях.

Откроем окно создания нового запроса в SSMS и выполним следующий код:

SELECT 
    s.session_id AS [ID Сессии],
    s.program_name AS [Имя программы],
    s.login_name AS [Логин],
    c.net_transport AS [Протокол подключения],
    c.client_net_address AS [IP-адрес клиента]
FROM sys.dm_exec_sessions AS s
INNER JOIN sys.dm_exec_connections AS c 
    ON s.session_id = c.session_id
WHERE s.program_name LIKE '%1C%' 
   OR s.program_name LIKE '%Profiler%';

Проанализируем результаты выполнения запроса:

• В колонке «Имя программы» мы увидим рабочие процессы 1С (обычно начинаются с 1C:Enterprise или содержат имена rphost).
• В колонке «Протокол подключения» (net_transport) мы увидим реальный тип соединения. Значение Shared memory подтвердит работу через локальную память, а значение TCP укажет на работу через сетевой драйвер.
• Если мы видим, что сессии 1С используют Shared memory, а сессия профайлера подключена по TCP, это является прямой подсказкой к необходимости выравнивания адресов, описанного в Шаге 2.

Шаг 4. Проверка фильтрации событий трассировки

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

1. Перейдем на вкладку «Выбор событий» (Events Selection).
2. Убедимся, что включены ключевые события для перехвата запросов 1С. Нам обязательно нужны события из группы Stored Procedures (а именно RPC:Completed — выполнение хранимых процедур, через которые 1С выполняет большинство параметризованных запросов) и из группы TSQL (событие SQL:BatchCompleted — выполнение пакетов инструкций SQL).
3. Нажмем на кнопку «Фильтры столбцов» (Column Filters).
4. Проверим фильтр по полю DatabaseName или DatabaseID. Часто разработчики ошибаются при вводе имени базы данных, из-за чего профайлер просто отсекает нужные события. Для теста рекомендуется полностью очистить все фильтры, оставив только стандартный дефолтный фильтр, исключающий отображение самого SQL Profiler (поле ApplicationName -> Not like -> SQL Profiler).

Современная альтернатива: переходим на Extended Events

Рассматривая работу с СУБД MS SQL Server 2016 и выше, важно упомянуть крайне важный факт: корпорация Microsoft официально объявила SQL Server Profiler устаревшим инструментом (deprecated). Использовать его на реальных высоконагруженных базах данных настоятельно не рекомендуется.

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

Современной, легкой и гораздо более надежной заменой являются Extended Events (Расширенные события). Этот инструмент встроен непосредственно в ядро СУБД, работает в сотни раз быстрее и лишен проблем с конфликтами локальных сетевых протоколов.

Для создания сессии расширенных событий выполним следующие действия:

1. В обозревателе объектов SSMS развернем узел «Управление» (Management), затем перейдем в «Расширенные события» (Extended Events) -> «Сеансы» (Sessions).
2. Нажмем правой кнопкой мыши и выберем «Мастер создания сеанса» (New Session Wizard).
3. Укажем имя сеанса (например, Trace_1C) и перейдем на шаг выбора шаблонов. Можно выбрать пустой шаблон и вручную добавить интересующие нас события: sql_batch_completed и rpc_completed.
4. Настроим фильтрацию: в качестве фильтра выберем поле sqlserver.database_name равным имени нашей базы данных 1С.
5. В качестве хранилища данных выберем вывод на экран в режиме реального времени (или запись в файл на диске сервера для последующего анализа).

Сессия Extended Events перехватит абсолютно все запросы от сервера приложений 1С, независимо от того, подключен ли он через localhost по общей памяти или по имени хоста через сеть TCP/IP. Это исключит любые проблемы с сетевой адресацией и убережет рабочий сервер от нежелательных перегрузок.