Спящий SPID блокирует другие транзакции

У меня действительно есть проблемы с отслеживанием некоторых блокировок, которые мы испытываем.

Статус SPID корневого блокирующего - «спящий», cmd - «AWAITING COMMAND» и « sqltextis» SET TRANSACTION ISOLATION LEVEL READ COMMITTED.

Когда я просматриваю отчет «Количество транзакций по количеству заблокированных транзакций», оператор блокирующего SQL имеет вид «-».

Я выполнил трассировку SQL и, когда происходит блокировка, отслеживает корневой блокирующий SPID, но это ни к чему меня не привело. Последний оператор трассировки такой же, как указано sqltextвыше SET TRANSACTION ISOLATION LEVEL READ COMMITTED.

Я проверил все связанные хранимые процедуры, которые я могу найти, чтобы убедиться, что они имеют операторы TRY / CATCH BEGIN TRAN / COMMIT TRAN / ROLLBACK TRAN (мы используем хранимые процедуры для всего, поэтому не выполняются отдельные операторы). Эта проблема только начала возникать в течение последних 24 часов, и никто не утверждает, что внес какие-либо изменения в систему.

Решение: одна из наших редко используемых хранимых процедур имела ошибку со вставкой (количество столбцов не совпадало), но мы все еще не уверены в том, что именно происходит.

При просмотре всей информации о трассировке оператор EXEC для этой хранимой процедуры иногда показывался, но НИКОГДА непосредственно перед тем, как BLOCK происходил с блокирующим SPID. Казалось, что когда он начал блокировать, трассировка не записывала его выполнение (или какие-либо операторы внутри него). Однако бывают случаи, когда трассировка записывала свое выполнение, и блокировка не происходила.

Отчет об ошибке хранимой процедуры был получен от пользователя, и я смог найти несколько операторов EXEC в трассировках и запустить их в SSMS. Ни разу, когда я запускал их, у нас не было никаких блокировок или они зависали. Они работали как ожидалось (блок catch сработал и откатил транзакцию после ошибки). После исправления хранимой процедуры мы больше не видели проблему.

Из комментариев я предполагаю, что у вас был тайм-аут команды на стороне клиента, который прервал SQL-запрос. Это не отменяет транзакцию, потому что соединение остается открытым на SQL Server из-за пула соединений.

Итак, вам нужно использовать SET XACT_ABORT ON или добавить некоторый код отката клиента

См. Тайм-аут транзакции SQL Server для всех подробностей

Используйте most_recent_sql_handle в sys.dm_exec_connections, чтобы увидеть последний выполненный оператор.

SELECT  t.text,
        QUOTENAME(OBJECT_SCHEMA_NAME(t.objectid, t.dbid)) + '.'
        + QUOTENAME(OBJECT_NAME(t.objectid, t.dbid)) proc_name,
        c.connect_time,
        s.last_request_start_time,
        s.last_request_end_time,
        s.status
FROM    sys.dm_exec_connections c
JOIN    sys.dm_exec_sessions s
        ON c.session_id = s.session_id
CROSS APPLY sys.dm_exec_sql_text(c.most_recent_sql_handle) t
WHERE   c.session_id = 72;--your blocking spid

Также проверьте, есть ли открытые транзакции для этого спида

SELECT  st.transaction_id,
        at.name,
        at.transaction_begin_time,
        at.transaction_state,
        at.transaction_status
FROM    sys.dm_tran_session_transactions st
JOIN    sys.dm_tran_active_transactions at
        ON st.transaction_id = at.transaction_id
WHERE   st.session_id = 72;--your blocking spid

Вы пробовали использовать sp_whoisactive Адама Мачаника ? Есть возможность получить внешнюю команду, чтобы увидеть, действительно ли она находится внутри proc. Возможно, приложение удерживает транзакцию открытой, а не фиксирует ее. Попробуйте посмотреть на DBCC OPENTRAN .