Performance

Blocking e sessões bloqueadoras: como identificar quem está travando quem

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.

Achando a cabeça da cadeia

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.

O que a sessão raiz está fazendo

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).

Decidir entre esperar e matar

  • Transação curta que está prestes a terminar → geralmente vale esperar alguns segundos.
  • Transação claramente esquecida (sessão idle, mesma query há muito tempo, sem atividade) → candidata a KILL, avaliando o que será desfeito no rollback.
  • Padrão recorrente no mesmo horário/job → a correção real é revisar o código que abre a transação, não ficar matando sessão toda vez.
Guia completo: Bloqueios (blocking) — causas e como resolver →

Artigos relacionados

Quer acompanhar bloqueios continuamente?

30 dias grátis para monitorar isso automaticamente no seu próprio ambiente.

Começar gratuitamente
codeDB

Monitoramento inteligente de SQL Server com agente local seguro e diagnósticos em tempo real.

Produto

RecursosPreçosComparativoscodeDB Lens (grátis)

© 2026 codeDB. Todos os direitos reservados.

Powered by codeDB

codeDB Informática Ltda — CNPJ 18.953.756/0001-10 — Florianópolis/SC