Как найти пользователя 1С или фоновое задание по Session ID (SPID) из SQL Server?

При администрировании высоконагруженных систем на платформе 1С:Предприятие часто возникает ситуация, когда в базе данных появляются блокировки. Используя мониторинг активности в SQL Server Management Studio (Activity Monitor) или профилировщик, мы можем увидеть, что некий процесс блокирует работу остальных. В этот момент нам известен только Session ID (он же SPID) и, возможно, системный логин, под которым выполняется процесс (чаще всего это служебная учетная запись, например, USR1CV8). Однако SQL-сервер ничего не знает об именах пользователей 1С.

Рассмотрим подробно, как сопоставить технический идентификатор сессии SQL с конкретным пользователем или заданием в системе 1С. Этот навык — ключевой при замере производительности и поиске узких мест. Разберем причины несовпадения номеров и выясним, как действовать в различных ситуациях.

Понимаем архитектуру: почему номера разные?

Прежде чем приступать к поиску, давайте разберемся, почему возникают вопросы с номерами. В теме обсуждения автор столкнулся с тем, что в консоли 1С номер сеанса — пятизначный (например, 58814), а в SQL Session ID — двузначный (например, 96). Прямой связи между этими числами нет.

Это происходит из-за трехзвенной архитектуры платформы:

1. Клиентское приложение подключается к кластеру серверов 1С. Ему присваивается Номер сеанса (внутри 1С).
2. Рабочий процесс сервера (rphost) держит пул физических соединений с СУБД (SQL Server).
3. SQL Server видит только подключения от процесса rphost. Каждому физическому подключению он присваивает свой SPID (Session ID).

Один и тот же процесс rphost может использовать одно соединение с СУБД для обслуживания запросов от разных пользователей 1С по очереди. Однако в момент выполнения запроса или транзакции конкретный сеанс 1С "захватывает" конкретное соединение СУБД.

Основной метод: Поиск через Консоль администрирования серверов 1С

Самый надежный и штатный способ найти виновника блокировки — воспользоваться консолью администрирования кластера 1С. Давайте пройдем этот путь по шагам.

Предположим, в мониторе SQL мы увидели, что блокировка исходит от Session ID = 96.

1. Откроем Консоль администрирования серверов 1С.
2. Развернем ветку нужного кластера, затем ветку Информационные базы.
3. Найдем нашу базу и перейдем в раздел Сеансы.
4. В открывшемся списке по умолчанию отображается множество колонок. Для более удобной работы с активными пользователями существуют инструменты вроде консоли активности пользователей, но мы рассмотрим штатный метод. Нас интересует колонка Соединение СУБД (в английской версии — DBMS Connection).

Важный нюанс: Часто эта колонка скрыта или находится далеко в правой части таблицы, и ее не видно без прокрутки. Проверим настройки видимости колонок или прокрутим список вправо.

В этой колонке отображаются числа, соответствующие SPID в SQL Server. Теперь нам нужно:

1. Найти строку, где в колонке Соединение СУБД стоит число 96.
2. В этой же строке посмотреть значение в колонке Пользователь. Это и есть имя пользователя 1С, который в данный момент использует это соединение.
3. Если нам нужно проанализировать историю действий этого пользователя, посмотрим на колонку Номер сеанса (например, 58814). Именно этот номер мы будем использовать для фильтрации в Журнале регистрации.

Что делать, если пользователь не указан (USR1CV8)?

Часто бывает ситуация, описанная в теме: логин в SQL определен как USR1CV8 (пользователь, от имени которого запущена служба сервера 1С), а в консоли 1С в найденной строке поле пользователя может быть пустым или содержать служебное имя.

Это указывает на то, что активность проявляет не интерактивный пользователь, а серверный процесс. Рассмотрим, что это может быть:

• Фоновое задание. Это наиболее частая причина. В списке сеансов обратим внимание на колонку Приложение. Если там написано BackgroundJob (Фоновое задание), значит, блокировку накладывает какой-то автоматический процесс.
• Регламентное задание. Фоновые задания часто порождаются регламентными (расписанием).

Чтобы выяснить, какое именно задание работает, выполним следующие действия:

1. Запомним Номер сеанса из строки, которую мы нашли по Соединению СУБД.
2. Перейдем в раздел Фоновые задания той же информационной базы в консоли. Для удобства можно использовать расширенную консоль регламентных и фоновых заданий.
3. Найдем задание, соответствующее этому номеру сеанса (или сопоставим по времени начала, если прямой связи нет).
4. В свойствах задания мы увидим его наименование (какой метод конфигурации выполняется).

Альтернативный метод: Анализ через SQL (для опытных администраторов)

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

Используем запрос к sys.dm_exec_sessions и sys.dm_exec_sql_text. Хотя SQL Server не знает имен пользователей 1С, платформа 1С иногда добавляет комментарии к транзакционным запросам или устанавливает Application Name специфическим образом.

Посмотрим пример запроса для анализа текущих сессий:

SELECT
    sess.session_id,
    sess.program_name,
    sess.login_name,
    req.command,
    text.text AS sql_text
FROM sys.dm_exec_sessions AS sess
LEFT JOIN sys.dm_exec_requests AS req ON req.session_id = sess.session_id
OUTER APPLY sys.dm_exec_sql_text(req.sql_handle) AS text
WHERE sess.session_id = 96 -- Наш искомый SPID

Проанализируем результат:

• В поле program_name мы увидим что-то вроде "1CV8 Server...". Это подтвердит, что соединение от сервера приложений.
• В поле sql_text мы увидим текст выполняемого запроса. В случае управляемых блокировок 1С или временных таблиц там могут быть подсказки. Например, имена таблиц вида _Document345. По метаданным конфигурации можно понять, какой это документ, особенно если сделать работу с функцией ПолучитьСтруктуруХраненияБазыДанных() удобнее и быстрее.

Программное получение соответствия (Автоматизация)

Если мы хотим автоматизировать процесс мониторинга и сразу получать имя пользователя по SPID без ручного поиска в консоли, можно воспользоваться средствами администрирования через COM-соединение или Java/Ras интерфейс.

Рассмотрим логику скрипта на встроенном языке 1С, который подключается к агенту сервера и ищет нужную сессию. Для этого используется объект IClusterInfo и коллекции сеансов.

В современных версиях платформы через COM-объект V83.COMConnector (или соответствующей версии) можно получить список соединений. В свойствах каждого соединения есть атрибут, отвечающий за Соединение СУБД. В разных версиях API он может называться DBMSConnection.

Алгоритм действий для скрипта:

1. Подключиться к агенту сервера 1С.
2. Получить список кластеров и рабочих процессов.
3. Получить список сеансов информационной базы.
4. Перебрать коллекцию сеансов и сравнить свойство DBMSConnection (или аналог) с искомым номером (например, 96).
5. Если совпадение найдено — вывести имя пользователя, номер сеанса и имя приложения.

Резюме решения

Подведем итог. Ошибка транзакционной блокировки требует быстрого выявления виновника. Несоответствие номеров в SQL и 1С — это нормальное явление архитектуры.

Для решения задачи:

1. Берем Session ID из монитора SQL.
2. Идем в Консоль кластера 1С -> Сеансы.
3. Ищем колонку Соединение СУБД.
4. Находим число из шага 1.
5. Смотрим колонку Пользователь и Приложение.
6. Если это фоновое задание — уточняем его имя в списке фоновых заданий.
7. Далее, чтобы понять причины долгой транзакции, проводим анализ журнала регистрации по номеру сеанса или коду 1С.