SPID inattivo che blocca altre transazioni

Ho davvero problemi a rintracciare alcuni blocchi che stiamo vivendo.

Lo stato di SPID che blocca la radice è "sleep", il cmd è "AWAITING COMMAND" e lo sqltextè SET TRANSACTION ISOLATION LEVEL READ COMMITTED.

Quando visualizzo il rapporto Transazioni principali per conteggio transazioni bloccate, l'istruzione SQL di blocco è "-".

Ho eseguito una traccia sull'SQL e quando il blocco si verifica tracciando lo SPID di blocco radice, ma non mi ha portato da nessuna parte. L'ultima istruzione trace è uguale alla sqltextprecedente SET TRANSACTION ISOLATION LEVEL READ COMMITTED.

Ho verificato tutte le relative procedure memorizzate che riesco a trovare per assicurarmi che abbiano TRY / CATCH INIZIA TRAN / COMMIT TRAN / ROLLBACK TRAN (utilizziamo le procedure memorizzate per tutto, quindi non ci sono istruzioni standalone in esecuzione). Questo problema è appena iniziato nelle ultime 24 ore e nessuno afferma di aver apportato modifiche al sistema.

Soluzione: una delle nostre procedure memorizzate utilizzate di rado ha avuto un errore con un inserimento (il numero di colonne non corrisponde), ma siamo ancora confusi su ciò che stava accadendo esattamente.

Quando si guardavano tutte le informazioni di traccia, l'istruzione EXEC per questa procedura memorizzata veniva elencata a volte, ma MAI poco prima che il BLOCCO si verificasse sullo SPID di blocco. Sembrava che quando ha iniziato a bloccare, la traccia non ha registrato l'esecuzione di esso (o nessuna delle dichiarazioni al suo interno). Tuttavia, ci sono altre volte in cui la traccia ha registrato la sua esecuzione e non si è verificato alcun blocco.

Il rapporto sugli errori della procedura memorizzata proveniva da un utente e sono stato in grado di trovare più istruzioni EXEC nelle tracce ed eseguirle in SSMS. Nessun momento in cui li ho eseguiti abbiamo avuto qualche blocco o si sono bloccati. Hanno funzionato come previsto (il blocco catch è stato attivato e ripristinato la transazione dopo l'errore). Dopo aver risolto la correzione della procedura memorizzata, non abbiamo più riscontrato il problema.

Dai commenti, suppongo che tu abbia avuto un timeout del comando sul lato client che ha interrotto la query SQL. Ciò non ripristina la transazione perché la connessione rimane aperta su SQL Server a causa del pool di connessioni.

Pertanto, è necessario utilizzare SET XACT_ABORT ON o aggiungere un codice di rollback del client

Vedere Timeout transazione SQL Server per tutti i dettagli gory

Utilizzare most_recent_sql_handle in sys.dm_exec_connections per vedere l'ultima istruzione eseguita.

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

Controlla anche se ci sono transazioni aperte per quello 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

Hai provato a utilizzare sp_whoisactive di Adam Machanic ? C'è un'opzione per ottenere il comando esterno per vedere se è davvero all'interno di un proc. È possibile che l'applicazione stia tenendo aperta una transazione invece di eseguirla. Prova anche a guardare DBCC OPENTRAN .