Как посмотреть блокировки 1С на SQL Server

Когда пользователи 1С массово жалуются, что документы «не проводятся», а программа «зависла», в большинстве случаев причина — блокировки на уровне СУБД. Один сеанс удерживает ресурс в базе, остальные ждут его освобождения, и очередь ожидания растёт. Задача администратора — быстро увидеть, кто кого заблокировал, и принять решение: дождаться завершения операции или завершить проблемный сеанс.

Блокировки в связке «1С + Microsoft SQL Server» можно смотреть на двух уровнях: средствами самого SQL Server (запросы к системным представлениям, Activity Monitor) и средствами платформы 1С (консоль кластера, технологический журнал). Первый способ показывает картину на уровне строк, страниц и таблиц базы данных, второй — привязывает блокировку к конкретному пользователю 1С, сеансу и даже исполняемому коду конфигурации.

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

Что такое блокировка и почему она возникает

Блокировка — это механизм СУБД, который не даёт двум транзакциям одновременно изменить одни и те же данные. Когда пользователь проводит документ, SQL Server ставит блокировки на затрагиваемые записи; другой пользователь, пытающийся обратиться к тем же записям, встаёт в очередь ожидания. Это нормальное поведение, пока время ожидания измеряется секундами.

Проблемой блокировка становится, когда транзакция длится долго: массовое перепроведение, тяжёлый отчёт, регламентное задание в рабочее время, обмен данными. В 1С ситуацию усугубляют управляемые блокировки на уровне платформы и обращения к итоговым таблицам регистров — один «тяжёлый» сеанс способен остановить работу десятков пользователей.

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

Просмотр блокировок запросами к системным представлениям

Самый информативный способ — выполнить запрос к динамическим административным представлениям SQL Server в среде SQL Server Management Studio (SSMS). Для этого нужны права VIEW SERVER STATE на сервере; обычно они есть у администратора базы данных.

Базовый запрос показывает цепочку «кто кого блокирует» с текстом запроса и программой-источником:

SELECT 
    blocking.session_id AS blocking_session,
    blocked.session_id AS blocked_session,
    blocked_login.login_name AS blocked_user,
    blocking_login.login_name AS blocking_user,
    blocked_sql.text AS blocked_query,
    blocking_sql.text AS blocking_query,
    blocked.wait_time / 1000.0 AS wait_seconds,
    blocked.wait_type
FROM sys.dm_os_waiting_tasks AS blocked
JOIN sys.dm_exec_sessions AS blocking 
    ON blocking.session_id = blocked.blocking_session_id
LEFT JOIN sys.dm_exec_sessions AS blocked_login 
    ON blocked_login.session_id = blocked.session_id
LEFT JOIN sys.dm_exec_sessions AS blocking_login 
    ON blocking_login.session_id = blocked.blocking_session_id
OUTER APPLY sys.dm_exec_sql_text(blocked.sql_handle) AS blocked_sql
OUTER APPLY sys.dm_exec_sql_text(blocking.sql_handle) AS blocking_sql
WHERE blocked.blocking_session_id IS NOT NULL;

Дополнительно полезно посмотреть сами удерживаемые блокировки через sys.dm_tran_locks: там видны тип ресурса (строка KEY, страница PAGE, таблица OBJECT), режим блокировки (X — монопольная, S — разделяемая, U — обновления) и статус (GRANT — удерживается, WAIT — ожидает). Для быстрой диагностики достаточно первого запроса, но sys.dm_tran_locks помогает понять, какой именно объект конфигурации стал «горячей точкой».

Если запрос вернул пустой результат, а пользователи жалуются, — снимок сделан «между» блокировками. Кратковременные ожидания живут доли секунды, поэтому запрос стоит выполнять несколько раз подряд или настроить периодический сбор через Extended Events или технологический журнал 1С.

Просмотр блокировок через Activity Monitor в SSMS

Для тех, кто предпочитает графический интерфейс, в SSMS есть встроенный инструмент Activity Monitor. Он открывается правой кнопкой по имени сервера в обозревателе объектов → «Монитор активности» (Activity Monitor).

В разделе «Процессы» (Processes) виден список всех подключений, и в столбцах «Блокируется» / «Блокирует» (Blocked By / Blocking) отображаются номера сессий, участвующих в конфликте. Кликнув по процессу правой кнопкой, можно посмотреть текст его последнего запроса (Details) или принудительно завершить процесс (Kill Process).

1. 1
   Откройте SSMS и подключитесь к серверу с базой 1С
2. 2
   Кликните правой кнопкой по имени сервера и выберите «Монитор активности»
3. 3
   Раскройте секцию «Процессы» и найдите строки с непустым значением «Блокируется»
4. 4
   Посмотрите текст запроса блокирующего процесса через контекстное меню
5. 5
   Сопоставьте номер сессии с пользователем 1С в консоли кластера
6. 6
   При необходимости завершите процесс через Kill Process — только убедившись, что это безопасно

Activity Monitor удобен для быстрой разовой диагностики, но у него есть ограничение: он показывает текущий момент и не хранит историю. Для анализа повторяющихся проблем «по утрам» или «в конце месяца» нужны инструменты с накоплением данных.

Как связать процесс SQL с пользователем 1С

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

Откройте консоль кластера, перейдите в нужный кластер → «Сеансы». В списке сеансов есть колонка с номером соединения с СУБД — именно она соответствует session_id (SPID) в SQL Server. Найдите сеанс с номером блокирующего процесса — и вы увидите пользователя 1С, приложение (тонкий клиент, фоновое задание, COM-соединение), время начала сеанса и последний вызов.

Обратная ситуация: если в консоли кластера видно, что сеанс «висит» в состоянии обращения к СУБД длительное время, его номер соединения можно проверить в SQL Server — есть ли он в цепочке блокировок и кем заблокирован.

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

Технологический журнал (ТЖ) — механизм платформы, который фиксирует события работы сервера 1С, включая таймауты блокировок (событие TLOCK, TTIMEOUT, TDEADLOCK) и длительные запросы (DBMSSQL с длительностью). Он включается настройкой файла logcfg.xml в каталоге conf сервера 1С.

Минимальная конфигурация для сбора событий блокировок выглядит так:

<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="C:\1clogs" history="24">
    <event><eq property="name" value="TLOCK"/></event>
    <event><eq property="name" value="TTIMEOUT"/></event>
    <event><eq property="name" value="TDEADLOCK"/></event>
    <property name="all"/>
  </log>
</config>

Преимущество ТЖ перед разовыми запросами к SQL Server — история. Журнал пишется постоянно, и по нему можно восстановить, что происходило в момент жалобы пользователя: какие сеансы конфликтовали, какой контекст кода выполнялся, сколько длилось ожидание. Это основной инструмент для разбора повторяющихся инцидентов.

Недостатки: ТЖ нужно включать заранее (задним числом события не появятся), файлы быстро растут на нагруженных базах, а разбор логов вручную трудоёмок — обычно используют скрипты или специализированные инструменты анализа.

Что делать с найденной блокировкой

После того как виновник найден, есть три пути действий. Первый — дождаться завершения: подходит, если блокирующий сеанс выполняет осмысленную операцию (проведение большого документа, закрытие месяца) и время ожидания приемлемо. Второй — связаться с пользователем и попросить завершить работу корректно: закрыть отчёт, отменить операцию. Третий — принудительное завершение сеанса через консоль кластера или KILL в SQL Server, когда операция зависла или заблокировала критичные процессы.

Разовые блокировки — норма; систематические — повод для оптимизации. Если одна и та же пара «запрос — таблица» регулярно появляется в цепочках, стоит разбираться с причиной: нехватка индексов, избыточные итоги регистров, обмены в рабочее время, код конфигурации, читающий лишние данные в транзакции.

Типичные ошибки при работе с блокировками

Отдельно стоит предостеречь от «лечения» блокировок хинтами вроде NOLOCK в текстах запросов конфигурации: чтение незафиксированных данных убирает ожидания, но приводит к неконсистентным отчётам и ошибкам в учёте. Это приемлемо лишь в редких аналитических сценариях и должно быть осознанным решением.

Часто задаваемые вопросы