Write Ahead {B}Log

Existe uma frase que todo DBA aprende a reconhecer cedo demais na carreira:

“A aplicação está lenta… deve ser o banco.”

Ela quase nunca vem acompanhada de contexto. Não diz quando começou, não diz o que mudou, não diz se é intermitente ou constante. Só chega como uma bola quente no colo de quem já está cuidando de várias instâncias espalhadas por regiões, engines e times diferentes.

Em ambientes modernos, o problema raramente é só o banco. Mas também quase nunca é só a aplicação. Devemos analisar o conjunto, mas é exatamente aí que a maior parte das investigações falha.

Durante muito tempo, troubleshooting de banco foi um exercício solitário. A gente conectava na instância, rodava query de sessão ativa, olhava locks, esperava o gráfico bater com o horário da reclamação e tentava reconstruir o que aconteceu. Quando dava certo, era quase um milagre. Quando não dava, virava jogo de empurra entre os times. O que muda quando começamos a olhar performance em escala não é a ferramenta. É o jeito de pensar o problema.

O primeiro erro: olhar o banco isolado do resto

Quando alguém diz “o banco está lento”, a pergunta que um DBA experiente faz não é qual query está lenta, mas onde isso aparece primeiro.

Em ambientes com dezenas ou centenas de bancos, o ponto de partida não pode ser conectar instância por instância. Isso não é escalável. O ponto de partida precisa ser visão de frota. Não para encontrar culpados, mas para responder algo simples:
isso é um problema pontual ou um padrão de comportamento?

Quando você enxerga sua frota inteira, com suas múltiplas regiões, contas, engines, começa a perceber coisas que uma instância isolada nunca mostraria. Um pico que parece enorme em um banco pode ser irrelevante quando comparado ao comportamento normal de outros. Ou o contrário: algo que parecia dentro do aceitável se revela completamente fora da curva quando você vê o todo.

Essa visão muda o jogo porque ela responde à primeira pergunta real de um incidente:
onde vale a pena gastar energia agora?

Carga alta não é vilã

Uma das confusões mais comuns em troubleshooting é tratar carga alta como problema. Mas carga alta, sozinha, não significa nada. O que importa é como essa carga se comporta. Se ela cresce de forma previsível, se acompanha o tráfego, se responde bem a picos. O problema começa quando a carga deixa de ser explicável.

É aí que métricas como sessões ativas, espera por CPU, espera por I/O ou por locks começam a contar uma história. Não isoladas, mas correlacionadas no tempo.

Uma query que sempre rodou bem pode, de um dia para o outro, passar a dominar o consumo de recursos. Não porque ficou “mais pesada”, mas porque algo mudou ao redor dela: um plano de execução diferente, uma partição específica, um volume inesperado de chamadas.

E esse tipo de problema não aparece olhando apenas a query. Ele aparece quando você cruza quem executa, de onde executa, com que frequência e em qual contexto.

Quando o culpado tem nome, host e aplicação

Todo DBA já viveu esse momento: finalmente encontrar a query problemática e perceber que ela não é exatamente um erro técnico, mas um erro humano.

Uma query simples, rodando em loop. Um relatório esquecido em produção. Um script de manutenção rodando sem limite. Um job que deveria ser eventual, mas virou constante. O ponto aqui não é o erro em si, mas a diferença entre descobrir isso em minutos ou em horas.

Quando você consegue responder rapidamente quem, de onde e por qual aplicação uma carga está sendo gerada, o troubleshooting deixa de ser defensivo e passa a ser colaborativo.

“Esse consumo começou aqui, nesse horário, vindo desses hosts, usando essa aplicação.”

A conversa muda completamente.

Locks não são bugs, mas são sintomas

Locks assustam porque são visíveis. Mas, na prática, eles raramente são a causa raiz. São consequência de algo que demorou mais do que deveria ou que foi projetado sem pensar em concorrência real.

A diferença entre um lock saudável e um lock problemático está no tempo e na cadeia. Um lock curto, esperado, faz parte do funcionamento normal. Uma árvore de bloqueios crescendo, com sessões esperando umas pelas outras, conta uma história diferente.

E essa história não se resolve com kill session no impulso. Ela se resolve entendendo qual transação começou tudo, por que ela demorou, e o que mais ficou preso atrás dela.

Ter essa visão sem precisar se conectar manualmente, reconstruindo o cenário depois que o problema já passou, muda completamente a eficiência do DBA. Porque lock problemático raramente acontece quando você está olhando.

Quando o plano muda, tudo muda

Poucas coisas são tão traiçoeiras quanto um plano de execução que muda silenciosamente. A query é a mesma. O código é o mesmo. O banco é o mesmo. Mas, de repente, algo que levava milissegundos passa a consumir segundos.

Quem já passou por isso sabe: não é falta de índice. É contexto, estatística, partição ou cardinalidade mal estimada. Comparar planos ao longo do tempo revela algo poderoso: o momento exato em que o comportamento mudou.

E isso transforma a investigação. Você para de perguntar “por que está lento agora?” e passa a perguntar “o que mudou aqui?”. Essa mudança de pergunta costuma levar à resposta muito mais rápido.

Nem toda lentidão nasce no banco

Em arquiteturas modernas, o banco de dados é só uma etapa de uma transação muito maior. API Gateway, Lambda, containers, filas, serviços intermediários. Um erro ou retry antes do banco pode multiplicar carga. Uma exceção depois do banco pode fazer parecer que a query falhou, quando na verdade ela foi rápida e correta.

Quando você consegue enxergar uma transação do começo ao fim, da requisição do usuário até a resposta final, o banco deixa de ser bode expiatório e passa a ser parte da explicação.

Ver a duração real da query dentro de um trace completo, comparar isso com o tempo total da requisição e identificar onde o erro foi lançado muda o nível da conversa com o time de aplicação. Não é mais opinião. É evidência.

Troubleshooting não é apagar incêndio é reduzir o próximo

No fim das contas, troubleshooting em escala não é somente sobre resolver um problema específico, mas encurtar o próximo incidente. É criar visibilidade antes da reclamação, perceber padrões e conseguir dizer “isso não é normal” antes que vire indisponibilidade.

E talvez o ponto mais importante: é tirar o DBA da posição de bombeiro solitário e colocá-lo como parte ativa da engenharia do sistema. Quando banco, aplicação e observabilidade conversam, o troubleshooting deixa de ser reativo. E quando isso acontece, todo mundo ganha, inclusive quem nunca vai saber que um incidente foi evitado.

Porque o melhor problema de performance…
é aquele que ninguém precisou abrir chamado para avisar.