26 de agosto de 2026 · 6 min de leitura
Numa cadeia de blocking, várias sessões podem aparecer "bloqueadas" ao mesmo tempo — mas normalmente só uma é a causa raiz, e as outras estão esperando na fila atrás dela (às vezes bloqueadas pela sessão que está bloqueada por outra). Resolver a raiz libera a cadeia inteira de uma vez; matar uma sessão do meio da fila não resolve nada.
SELECT r.session_id AS bloqueada, r.blocking_session_id AS bloqueadora, r.wait_time, r.wait_type, s.login_name, s.host_name, s.program_name FROM sys.dm_exec_requests r JOIN sys.dm_exec_sessions s ON s.session_id = r.session_id WHERE r.blocking_session_id <> 0 ORDER BY r.wait_time DESC;
A sessão raiz é a que aparece como blocking_session_id em uma ou mais linhas, mas ela própria não aparece com blocking_session_id preenchido em nenhuma linha — ou seja, ela não está esperando ninguém, só sendo esperada.
SELECT s.session_id, s.login_name, s.program_name, t.text AS ultima_query, tat.transaction_begin_time, DATEDIFF(SECOND, tat.transaction_begin_time, GETDATE()) AS segundos_aberta FROM sys.dm_tran_active_transactions tat JOIN sys.dm_tran_session_transactions tst ON tst.transaction_id = tat.transaction_id JOIN sys.dm_exec_sessions s ON s.session_id = tst.session_id OUTER APPLY sys.dm_exec_sql_text((SELECT TOP 1 sql_handle FROM sys.dm_exec_requests WHERE session_id = s.session_id)) t WHERE s.session_id = @session_id_raiz;
segundos_aberta é o dado que mais importa aqui — uma transação aberta há 3 segundos é normal; uma aberta há 40 minutos é quase sempre o problema, mesmo que a query atual dela pareça inofensiva (pode estar esperando input do usuário no meio de uma transação, por exemplo).
Artigos relacionados
7 dias grátis para monitorar isso automaticamente no seu próprio ambiente.
Começar gratuitamente