Bloqueios (blocking) no SQL Server: causas e como resolver

Bloqueio (blocking) não é um bug — é o mecanismo normal de controle de concorrência do SQL Server funcionando como projetado: uma transação segura um recurso e outra espera. O problema não é blocking existir, é uma sessão segurar o recurso por tempo demais e virar um gargalo pra todo mundo atrás dela.

Encontrando a cadeia de bloqueio

O primeiro passo é sempre achar a sessão "cabeça de fila" — a que está bloqueando as outras sem estar bloqueada por ninguém:

SELECT
  r.session_id AS sessao_bloqueada,
  r.blocking_session_id AS sessao_bloqueadora,
  r.wait_type, r.wait_time,
  t.text AS query_bloqueada
FROM sys.dm_exec_requests r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t
WHERE r.blocking_session_id <> 0
ORDER BY r.wait_time DESC;

Se a sessao_bloqueadora de uma linha aparece também como sessao_bloqueada em outra, você tem uma cadeia — várias sessões esperando em fila atrás de uma única sessão raiz. Resolver a raiz libera todo o resto de uma vez.

O que costuma causar blocking prolongado

• Transação aberta e esquecida — alguém rodou BEGIN TRAN no SSMS, foi almoçar, e a transação nunca fechou.
• Operação em lote grande (UPDATE/DELETE de milhões de linhas) numa única transação, segurando locks por minutos.
• Índice ausente fazendo table scan dentro de uma transação de escrita — a leitura varre (e bloqueia) muito mais linhas do que precisaria.
• Aplicação com nível de isolamento mais alto que o necessário, ou sem timeout de lock configurado.

Ações imediatas vs. correção definitiva

No incidente, a ação imediata costuma ser identificar a sessão raiz e decidir entre esperar ela terminar ou matá-la com KILL (avaliando o impacto de desfazer o que ela estava fazendo). Isso resolve o sintoma. A correção definitiva é tratar a causa: quebrar operações em lote grande em lotes menores (batching), adicionar o índice que faltava, ou revisar por que aquela transação ficou aberta tanto tempo.

Blocking pontual de alguns segundos é normal e esperado. O que vale monitorar é a duração e a recorrência — o codeDB registra automaticamente as cadeias de bloqueio e por quanto tempo cada uma durou, então dá pra distinguir "aconteceu uma vez" de "acontece toda sexta às 18h quando roda aquele job de fechamento".