Quando o banco SQL Server corrompe, a reação instintiva da equipe de TI frequentemente causa mais dano do que a corrupção em si. Além disso, esses erros acontecem nos primeiros minutos — exatamente quando a pressão é maior e o tempo parece escasso. Neste artigo, você conhece os 5 erros mais destrutivos e o que fazer no lugar.
Por que a reação errada é mais perigosa que a corrupção
O SQL Server organiza os dados em páginas de 8 KB dentro do arquivo MDF. Quando ocorre corrupção, apenas uma parte dessas páginas é afetada — o restante permanece intacto. Portanto, a janela de recuperação depende diretamente de preservar o estado atual dos arquivos.
Cada ação errada depois da corrupção pode sobrescrever páginas íntegras, apagar referências que o especialista usaria para reconstruir o banco ou consolidar erros que seriam reversíveis. Por isso, entender o que não fazer é tão importante quanto entender o que fazer.
Erro 1: executar DBCC CHECKDB com REPAIR_ALLOW_DATA_LOSS
Este é o erro mais comum e o mais destruidor. O comando DBCC CHECKDB WITH REPAIR_ALLOW_DATA_LOSS parece a solução natural — afinal, é uma ferramenta nativa do SQL Server para corrigir inconsistências. Contudo, o nome já avisa o que acontece: ele permite perda de dados.
Na prática, esse comando apaga as páginas que não consegue corrigir. Ou seja, ele restaura a estrutura lógica do banco sacrificando o conteúdo danificado. Dessa forma, ele resolve a corrupção da perspectiva do SQL Server — mas destrói dados que um especialista conseguiria recuperar por forense.
O que fazer no lugar: execute DBCC CHECKDB sem a opção de reparo para diagnóstico. Anote os erros retornados e acione um especialista antes de qualquer reparo.
Erro 2: restaurar um backup sem salvar o estado atual
Quando existe um backup recente, a reação imediata é restaurá-lo. Contudo, restaurar o backup sobrescreve o arquivo MDF corrompido — destruindo o estado atual do banco que o especialista usaria para recuperar transações mais recentes.
Por isso, antes de qualquer restauração, faça uma cópia do arquivo MDF e LDF corrompido para um local seguro. Dessa forma, você preserva a possibilidade de recuperação forense das transações que ocorreram após o último backup.
Além disso, verifique se o backup é realmente íntegro antes de restaurar. Um backup corrompido restaurado sobre o banco original resulta em duas fontes de dados corrompidas, sem possibilidade de recuperação de nenhuma das duas.
O que fazer no lugar: copie MDF e LDF para destino seguro, verifique a integridade do backup e só então decida entre restaurar ou acionar recuperação forense.
Erro 3: tentar iniciar o SQL Server repetidamente após a falha
Quando o SQL Server não sobe, a equipe tenta reiniciá-lo repetidamente. Cada tentativa força o serviço a tentar rolar back as transações pendentes — e em bancos corrompidos, esse processo pode piorar a inconsistência das páginas afetadas.
Além disso, algumas tentativas de início criam arquivos de log temporários que ocupam espaço nos mesmos volumes dos dados — aumentando o risco de sobrescrita acidental de áreas ainda recuperáveis.
O que fazer no lugar: tente iniciar o SQL Server apenas uma vez para diagnóstico. Se não subir, pare as tentativas e acione o especialista com os logs de erro gerados nessa primeira tentativa.
Erro 4: copiar o MDF corrompido com o serviço do SQL Server ativo
Muitas equipes tentam fazer backup do arquivo MDF com o SQL Server ainda rodando, usando o Windows Explorer ou xcopy. Contudo, o SQL Server mantém locks sobre os arquivos de dados — e uma cópia feita com locks ativos pode gerar um arquivo inconsistente, com páginas em estado de transição capturadas no meio de uma operação.
Por isso, qualquer cópia dos arquivos de banco precisa ser feita com o serviço do SQL Server completamente parado. Dessa forma, o arquivo copiado reflete o estado real e consistente dos dados no momento da cópia.
O que fazer no lugar: pare o serviço do SQL Server, copie MDF e LDF para local seguro e só então inicie a análise ou acione o especialista.
Erro 5: instalar software de recuperação no mesmo servidor
Softwares genéricos de recuperação de dados instalados no mesmo servidor onde o banco corrompido reside gravam dados de instalação e funcionamento no volume — exatamente sobre as páginas MDF que você quer recuperar. Além disso, muitos desses softwares não entendem a estrutura interna de páginas do SQL Server e não conseguem recuperar objetos de banco como tabelas, índices e stored procedures.
Por isso, recuperação de banco de dados corrompido não é o mesmo que recuperação de arquivo. Ela exige conhecimento das estruturas internas do motor — o que ferramentas genéricas não têm.
O que fazer no lugar: não instale nada no servidor afetado. Acione um especialista com expertise em recuperação forense de SQL Server.
O protocolo correto quando o SQL Server corrompe
Agora que você conhece o que não fazer, o caminho correto é direto:
- Pare o SQL Server — uma única vez, de forma limpa
- Copie MDF e LDF para um disco separado com o serviço parado
- Anote os erros dos logs do SQL Server e do Event Viewer
- Não faça mais nada até falar com um especialista
- Acione a Crowdertech — diagnóstico gratuito em até 2 horas
A recuperação forense de SQL Server lê as páginas de 8 KB do arquivo MDF diretamente, reconstrói tabelas, índices, stored procedures e objetos de esquema a partir das páginas íntegras. Assim, mesmo bancos com corrupção severa frequentemente voltam com mais de 90% do conteúdo.
Perguntas frequentes sobre SQL Server corrompido
Dá para recuperar banco SQL Server sem backup? Sim. Enquanto o arquivo MDF existir no disco, os dados existem. A Crowdertech extrai o conteúdo por leitura forense direta das páginas, sem depender de backup.
DBCC CHECKDB sem opção de reparo é seguro? Sim. O DBCC CHECKDB sem a cláusula de reparo é apenas diagnóstico — ele lê e reporta, não modifica. Use-o para entender a extensão da corrupção antes de acionar o especialista.
SQL Server com erro 823 ou 824 tem recuperação? Na grande maioria dos casos, sim. O erro 823 indica falha física de leitura e o 824 indica inconsistência lógica — ambos são cenários tratáveis pela forense de páginas MDF.
Banco SQL Server que não sobe após corrupção ainda tem dados recuperáveis? Sim. Os dados vivem no arquivo MDF, não na instância do SQL Server. O banco não precisar subir para a recuperação acontecer — a Crowdertech acessa os dados diretamente no arquivo.
Quanto tempo leva a recuperação de SQL Server corrompido? Bancos com corrupção parcial voltam em horas. Casos com corrupção extensiva ou arquivos muito grandes levam de 24 a 72 horas. O diagnóstico define o prazo real antes da aprovação.
Conclusão
SQL Server corrompido não é perda total — mas os 5 erros descritos aqui transformam uma situação recuperável em perda definitiva. Em resumo, pare o serviço, copie os arquivos, documente os erros e acione especialistas antes de qualquer intervenção. Banco SQL Server corrompeu? A Crowdertech recupera MDF página a página. Veja também recuperação de banco de dados SQL Server.
Fontes: Microsoft Docs — SQL Server · NIST SP 800-86.