Início / dba / Perguntas / 41709
Accepted
Brad
Asked: 2013-05-08 10:53:35 +0800 CST

Sleeping SPID bloqueando outras transações

  • 772

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

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

Quando visualizo o relatório Top Transactions by Blocked Transactions Count, a instrução SQL de bloqueio é '--'.

Já realizei um rastreamento no SQL e quando o bloqueio acontece rastreando o SPID de bloqueio de root mas não me levou a lugar nenhum. A última instrução trace é a mesma que a sqltextanterior SET TRANSACTION ISOLATION LEVEL READ COMMITTED.

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 acontecer nas últimas 24 horas e ninguém está alegando 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 correspondeu), mas ainda estamos confusos sobre o que exatamente estava acontecendo.

Ao examinar todas as informações de rastreamento, a instrução EXEC para esse procedimento armazenado foi listada às vezes, mas NUNCA imediatamente antes do BLOCK acontecer no SPID de bloqueio. Parecia que ao iniciar o bloqueio, o rastreamento não registrava a execução dele (ou qualquer uma das instruções dentro dele). No entanto, há outras vezes 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 consegui encontrar várias instruções EXEC em rastreamentos e executá-las no SSMS. Em nenhum momento, quando eu os executei, tivemos algum bloqueio ou eles travaram. Eles foram executados conforme o esperado (o bloco catch foi acionado e reverteu a transação após o erro). Depois de resolver a correção do procedimento armazenado, não vimos o problema novamente.

sql-server-2008 transaction

3 respostas

  1. Best Answer

    A partir 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.

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

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

    • 12

  2. Use 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
    • 10

  3. 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 proc. Pode ser que o aplicativo esteja mantendo uma transação aberta em vez de confirmá-la. Tente olhar para DBCC OPENTRAN também.

    • 4

relate perguntas