Como detectar e eliminar locks e deadlocks no banco de dados

Em ambientes de banco de dados concorrentes, travamentos são inevitáveis. Eles fazem parte da mecânica normal de controle de consistência. O problema surge quando o que deveria ser um bloqueio transitório se transforma em um impasse permanente — o famoso deadlock — ou em um acúmulo de sessões presas, aguardando liberação de recursos.

Quando não tratados com atenção, locks e deadlocks podem degradar seriamente a performance, gerar timeouts e até interromper aplicações críticas. Neste artigo, analisamos como identificar esses eventos com precisão e, mais importante, como preveni-los.

Locks: o que são e por que acontecem

Todo banco de dados relacional precisa garantir integridade transacional. Para isso, ele usa locks — mecanismos que impedem que dois processos modifiquem simultaneamente o mesmo dado.

Os principais tipos de lock incluem:

• Locks de linha: comuns em operações UPDATE e DELETE.
• Locks de página ou bloco: afetam um conjunto de registros.
• Locks de tabela: menos comuns, mas podem ser causados por DDL ou por varreduras completas mal otimizadas.
• Locks de metadados: ocorrem durante alterações de estrutura, estatísticas ou recompilações.

Locks são normais. O que não é normal é mantê-los por muito tempo, ou deixar que bloqueios escalem ao ponto de gerar cadeias de espera.

Deadlocks: quando o bloqueio se transforma em impasse

Um deadlock ocorre quando duas ou mais sessões entram em um ciclo de dependência, onde cada uma espera por um recurso que a outra detém. Nenhuma pode prosseguir — o sistema detecta o impasse e, normalmente, mata uma das sessões envolvidas para liberar os recursos.

Exemplo clássico:

• Sessão A bloqueia a linha X.
• Sessão B bloqueia a linha Y.
• Sessão A tenta acessar a linha Y.
• Sessão B tenta acessar a linha X.
• Nenhuma pode prosseguir.

Esses eventos são mais comuns do que se imagina e, se ocorrem com frequência, indicam falhas no desenho transacional da aplicação ou ausência de controle de concorrência.

Como detectar locks e deadlocks

A detecção precisa exige visibilidade em dois níveis: sessões ativas e estrutura de espera por recursos.

1. Consultas para detecção em tempo real

Oracle

sqlCopyEditSELECT blocking_session, sid, wait_class, event, seconds_in_wait
FROM v$session
WHERE blocking_session IS NOT NULL;

SQL Server

sqlCopyEditSELECT 
  blocking_session_id AS blocker,
  session_id AS waiter,
  wait_type, wait_time
FROM sys.dm_exec_requests
WHERE blocking_session_id <> 0;

PostgreSQL

sqlCopyEditSELECT 
  pid, 
  pg_blocking_pids(pid) AS blocked_by
FROM pg_stat_activity
WHERE wait_event_type = 'Lock';

Essas consultas ajudam a identificar quem está travando quem, por quanto tempo, e qual tipo de espera está ocorrendo.

2. Deadlocks detectados por logs

SGBDs modernos registram deadlocks automaticamente em seus logs internos. O problema é que, se você só os vê depois que aconteceram, é sinal de que o monitoramento está incompleto.

Ferramentas de observabilidade específicas podem:

• Correlacionar picos de latência com eventos de lock
• Alertar sobre sessões em espera por mais de X segundos
• Exibir graficamente a cadeia de bloqueios (blocking tree)
• Capturar eventos de deadlock com contexto (query, usuários, recursos envolvidos)

A visibilidade contínua é o diferencial entre um diagnóstico reativo e uma correção estratégica.

Como eliminar e evitar locks e deadlocks

Eliminar travamentos exige uma combinação de otimização de queries, revisão de transações e, em alguns casos, ajuste fino da configuração do banco.

1. Otimize o tempo de retenção dos locks e deadlocks

Transações longas são inimigas da concorrência. Sempre que possível:

• Faça commits frequentes, especialmente em operações batch
• Evite deixar transações abertas em sessões ociosas
• Quebre operações grandes em blocos menores

2. Mantenha a ordem consistente de acesso a recursos

Muitos deadlocks são evitáveis apenas garantindo que todas as transações acessem os dados na mesma ordem. Exemplo: sempre atualize Tabela A antes de Tabela B.

3. Use índices apropriados

Leituras ou atualizações sem índice forçam o banco a bloquear mais registros (ou páginas) do que o necessário. Um bom índice permite acesso preciso e menos lock.

4. Evite escalonamento automático de locks

Em alguns SGBDs, uma grande quantidade de locks em linha pode escalar para um lock de tabela. Configurar corretamente os limiares (ou evitar varreduras desnecessárias) reduz esse risco.

5. Implemente controle de concorrência na aplicação

Revisar o uso de ORM, pools de conexão e práticas de retry ajuda a evitar cenários onde múltiplas sessões disputam os mesmos recursos em ciclos viciosos.

Quando o monitoramento faz a diferença

Monitorar locks em tempo real é o primeiro passo. Mas o diferencial está em:

• Detectar tendências (ex.: sessões que frequentemente causam bloqueios)
• Correlacionar picos de latência com tempo de espera por locks
• Visualizar top N sessões bloqueadoras
• Alertar por thresholds configuráveis de espera ou de cadeias de bloqueio

A observabilidade não resolve o problema sozinha — mas fornece os dados necessários para resolvê-lo com precisão.

Conclusão

Locks são parte inevitável da arquitetura de bancos de dados. O problema não é sua existência, mas sua duração e impacto. Deadlocks, por sua vez, indicam que o controle de concorrência saiu do controle.

Eliminar essas situações exige disciplina transacional, queries otimizadas e monitoramento ativo. Esperar que o banco “se resolva sozinho” é uma aposta arriscada — e, em ambientes críticos, insustentável.

Quer saber o que está travando seu banco agora? Olhe para as sessões em espera. Quer evitar que isso volte a acontecer? Monitore o padrão de bloqueios com profundidade e contexto. É aí que o desempenho real começa.

Agende uma demonstração aqui

Saiba mais sobre o Flightdeck!

Visite nosso canal no youtube e aprenda sobre a plataforma e veja tutoriais

Aprenda sobre monitoramento de banco de dados com ferramentas avançadas aqui.