O CHECKDB não apontou problemas, mas os alertas diziam outra coisa. ERROS críticos no banco não escolhem horário, nosso suporte também não.
Em ambientes críticos, alguns problemas não aparecem exatamente onde começaram.
Às vezes, é preciso conectar diferentes evidências até chegar à verdadeira origem da falha.
Um caso recente envolvendo páginas corrompidas em um ambiente SQL Server mostrou exatamente isso:
mesmo com um DBCC CHECKDB em execução, a investigação precisou ir muito além do primeiro diagnóstico.
Aqui na Power Tuning, nossos clientes contam com suporte especializado 24 horas por dia, 7 dias por semana.
Recentemente, fui acionado durante a madrugada após um ambiente SQL Server começar a registrar alertas de páginas corrompidas.
O detalhe interessante é que uma rotina de DBCC CHECKDB já estava em execução antes do início do problema.
Durante essa execução, ocorreu uma falha na camada de infraestrutura/storage que acabou provocando a corrupção.
O CHECKDB, porém, terminou sem reportar erros.
Como isso é possível?
No momento em que a corrupção aconteceu, o CHECKDB já havia passado pelo objeto afetado.
Ou seja, aquela região da base já havia sido validada quando ocorreu o problema de I/O.
Mesmo assim, outras rotinas de monitoramento da Power Tuning começaram a gerar alertas relacionados às páginas corrompidas.
Foi aí que começou a investigação.
Começando a investigação
Com base nas coletas já existentes e em novas coletas configuradas durante a análise,
comecei a correlacionar os erros com as operações que estavam ocorrendo no momento da falha.
E chegamos a um ponto interessante:
A tabela corrompida não fazia parte diretamente da rotina principal. Ela era alimentada por uma
trigger.
Quando ocorria um UPDATE na tabela principal, a trigger era acionada e realizava operações em uma segunda tabela.
Com o apoio das coletas, consegui seguir esse caminho até chegar ao objeto realmente afetado.
| Etapa | O que aconteceu |
|---|---|
| 1. UPDATE | Uma operação ocorreu na tabela principal. |
| 2. Trigger | A trigger foi acionada automaticamente. |
| 3. Segunda tabela | A trigger realizou operações no objeto relacionado. |
| 4. Investigação | As coletas permitiram chegar até o objeto afetado. |
Confirmando a corrupção
Ao identificar a tabela, executei um DBCC CHECKTABLE direcionado e confirmei a corrupção.
Na sequência, identificamos que o problema estava em um índice nonclustered,
o que permitiu corrigir a estrutura sem necessidade de uma intervenção mais invasiva nos dados.
DBCC CHECKTABLE → objeto afetado → índice nonclustered → correção da estrutura
Após a correção
✅ CHECKTABLE concluído com sucesso
✅ CHECKDB completo sem erros
✅ Aplicação e rotinas normalizadas
Além disso, a análise encontrou evidências de falhas na camada de I/O/storage no mesmo período.
O cliente foi comunicado imediatamente e o time responsável pela Infra aplicou as tratativas necessárias,
evitando impactos maiores no ambiente.
O que tiramos disso tudo?
Esse caso reforça algo importante no trabalho de um DBA: a importância de uma análise cuidadosa,
conectando as evidências até chegar à real origem do problema.
Foi justamente essa investigação, apoiada também pelos alertas do PowerAlerts,
que permitiu sair de uma ocorrência de página corrompida e chegar até a estrutura responsável pela falha.
Em um ambiente crítico, identificar o problema é apenas o começo.
É preciso entender o que aconteceu, conectar as evidências e agir de forma rápida e segura
para normalizar o ambiente.
Esse é um pouco do trabalho que realizamos na Power Tuning:
monitorar, investigar e atuar quando o cliente mais precisa, inclusive fora do horário comercial.
Porque, em situações como essa, o diferencial não está apenas em detectar uma página corrompida.
Está em conseguir transformar os sinais espalhados pelo ambiente em uma investigação que leve à causa
e permita uma correção segura.
Power Tuning · Monitoramento, investigação e suporte especializado para ambientes críticos.
