SPID adormecido bloqueando outras transações

Estou realmente tendo problemas para rastrear alguns bloqueios que estamos enfrentando.

O status do SPID de bloqueio raiz é 'adormecido', o cmd é 'AWAITING COMMAND' e o sqltexté SET TRANSACTION ISOLATION LEVEL READ COMMITTED.

Quando visualizo o relatório Principais transações por contagem de transações bloqueadas, a instrução SQL de bloqueio é '-'.

Eu executei um rastreamento no SQL e, quando o bloqueio acontece, rastreia o SPID de bloqueio raiz, mas ele realmente não me levou a lugar algum. A última instrução de rastreamento é a mesma que a sqltextacima SET TRANSACTION ISOLATION LEVEL READ COMMITTED.

Eu verifiquei todos os procedimentos armazenados relacionados que posso encontrar para garantir que eles tenham instruções TRY / CATCH BEGIN TRAN / COMMIT TRAN / ROLLBACK TRAN (usamos procedimentos armazenados para tudo, para que não haja instruções independentes sendo executadas). Esse problema começou a ocorrer nas últimas 24 horas e ninguém está afirmando ter feito alterações no sistema.

Solução: um de nossos procedimentos armazenados raramente usados ​​teve um erro com uma inserção (o número de colunas não correspondia), mas ainda estamos confusos sobre o que exatamente estava acontecendo.

Ao examinar todas as informações de rastreamento, a instrução EXEC deste procedimento armazenado foi listada às vezes, mas NUNCA pouco antes do BLOCK ocorrer no SPID de bloqueio. Parecia que, quando começou a bloquear, o rastreio não registrou a execução (ou nenhuma das instruções nele). No entanto, há outros momentos em que o rastreamento registrou sua execução e nenhum bloqueio ocorreu.

O relatório de erro do procedimento armazenado veio de um usuário e eu consegui encontrar várias instruções EXEC em rastreios e executá-las no SSMS. Em nenhum momento em que os executei, ocorreu algum bloqueio ou eles travaram. Eles foram executados conforme o esperado (o bloco catch foi acionado e revertida a transação após o erro). Depois de resolver a correção do procedimento armazenado, não vimos o problema novamente.

Dos comentários, acho que você teve um tempo limite de comando do lado do cliente que abortou a consulta SQL. Isso não reverte a transação porque a conexão permanece aberta no SQL Server devido ao pool de conexões.

Portanto, você precisa usar SET XACT_ABORT ON ou adicionar algum código de reversão do cliente

Consulte Tempo limite de transação do SQL Server para obter todos os detalhes sangrentos

Use o most_recent_sql_handle em sys.dm_exec_connections para ver a última instrução que foi executada.

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

Verifique também se há transações abertas para esse 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

Você já tentou usar o sp_whoisactive de Adam Machanic ? Existe uma opção para obter o comando externo para ver se ele realmente está dentro de um processo. Pode ser que o aplicativo esteja mantendo uma transação aberta em vez de confirmá-la. Tente olhar para o DBCC OPENTRAN também.