Quando um banco SQL Server corrompido dispara o erro 824 ou falha numa consulta com “page header invalid”, o primeiro passo natural é rodar DBCC CHECKDB. O problema começa na sugestão que o próprio SQL Server imprime no final do relatório: repair_allow_data_loss — a opção mais agressiva do CHECKDB, e a única que o comando lista como último recurso mesmo quando existem alternativas mais seguras. O nome já avisa: esse modo não repara a página corrompida — ele a descarta permanentemente.

O que o CHECKDB realmente diz sobre o banco SQL Server corrompido

Antes de rodar qualquer reparo, o relatório completo do CHECKDB precisa de leitura linha por linha — não só a última linha com a sugestão. O relatório separa os erros em dois grupos distintos.

Erros de alocação (nível de página, extent, IAM): geralmente mais graves, mas às vezes recuperáveis sem perda com reconstrução de índice. Veja como a Crowdertech trata esses casos em recuperação de banco de dados.

Erros de consistência (nível de linha, dentro de uma página específica): é aqui que o repair_allow_data_loss de fato descarta dados. Se a página pertence a uma tabela sem índice clusterizado, a linha inteira some. Se pertence a um índice, o SQL Server reconstrói o índice do zero — o que pode levar horas em tabelas grandes e travar a produção durante a operação.

Rodar o reparo sem separar os dois tipos é o erro mais comum. Bancos que tinham só corrupção de índice — 100% recuperável sem perda — perdem linhas de dados porque o DBA rodou o comando sugerido sem investigar o relatório completo.

Antes de rodar repair_allow_data_loss no banco SQL Server corrompido

1. Nunca rode diretamente em produção. Restaure o banco — ou os arquivos MDF/LDF — em ambiente isolado primeiro. Além disso, o banco em produção pode estar ativo com transações em andamento, o que piora qualquer corrupção existente.

2. Rode CHECKDB sem reparo primeiro. Salve o relatório completo e identifique quais objetos estão envolvidos — tabela, índice, página específica. Por isso, esse passo define toda a estratégia de recuperação.

3. Verifique se existe backup limpo anterior à corrupção. Muitas vezes é possível extrair as linhas afetadas do backup e reinserir, sem tocar no restante do banco. Além disso, se o banco usa replicação ou Always On, o secundário pode ter as páginas íntegras.

4. Se o backup não existe ou também está corrompido, a extração direta das páginas de dados — carving no nível de página, fora do mecanismo do SQL Server — preserva registros que o repair_allow_data_loss descartaria. Para entender como funciona esse processo, veja recuperação de banco de dados SQL Server sem backup.

O que acontece quando repair_allow_data_loss é a única opção

Mesmo quando o repair_allow_data_loss é realmente necessário, a sequência correta minimiza a perda. Primeiro, a Crowdertech faz uma imagem forense completa do banco antes de qualquer reparo. Depois, extrai por forense todas as linhas ainda legíveis das páginas marcadas para descarte. Por isso, o que seria uma perda total de determinadas tabelas se torna uma perda parcial — com registro exato de quais linhas foram afetadas.

O laudo técnico entregue ao final documenta hash SHA-256 de cada arquivo e lista os registros afetados, o que é essencial para notificações à ANPD em casos que envolvem dados pessoais sob a LGPD. Para emergências com prazo regulatório, o atendimento 24h na Vila Olímpia prioriza casos com deadline de autoridades.

Perguntas frequentes

O erro 824 no SQL Server significa perda de dados? Não necessariamente. O erro 824 indica que o SQL Server leu uma página com checksum inválido — pode ser falha de disco, controladora, memória RAM ou cabo. A causa determina se outros dados estão em risco.

Posso usar o CHECKDB com REPAIR_REBUILD em vez de REPAIR_ALLOW_DATA_LOSS? Sim, quando os erros são apenas de índice. O REPAIR_REBUILD reconstrói índices sem descartar dados de tabelas. Por isso, é sempre a primeira opção a avaliar antes do modo destrutivo.

Banco SQL Server corrompido ainda em produção — preciso desligar? Sim. Cada transação nova sobre um banco corrompido pode agravar a situação. Além disso, o SQL Server pode tentar recovery automático que sobrescreve metadados recuperáveis.

Conclusão

Banco SQL Server corrompido com sugestão de repair_allow_data_loss não é sentença de perda de dados. Além disso, o relatório do CHECKDB tem muito mais informação do que a última linha de sugestão. Em resumo, leia o relatório completo, isole o banco e acione especialistas antes de rodar qualquer reparo. A Crowdertech recupera SQL Server sem perda de dados — (11) 99630-0675.

Fontes: Microsoft Learn — DBCC CHECKDB · CERT.br.