O banco de produção parou de responder, o SSMS mostra um estado que ninguém quer ver e a aplicação começou a falhar em plena operação. Nesse momento, cada comando executado sem critério pode transformar uma perda parcial em perda definitiva. Este guia foi escrito para DBAs e equipes de TI que precisam recuperar banco de dados SQL Server e querem entender as causas, interpretar os sintomas e escolher o caminho certo antes de agir.
O que significa um banco de dados SQL Server corrompido
Um banco de dados SQL Server corrompido é aquele cujas estruturas internas — páginas de dados, índices, metadados do catálogo ou o log de transações — deixaram de ser íntegras o suficiente para que o Mecanismo de Banco de Dados consiga lê-las e interpretá-las com segurança. A corrupção raramente se anuncia: muitas vezes o banco continua aceitando conexões por dias ou semanas, até que uma consulta específica tenta varrer uma página danificada e o erro explode no meio da operação. Em outros casos, o banco nem chega a abrir, ficando preso em estados intermediários de inicialização.
O ponto central para quem precisa recuperar banco de dados SQL Server é entender que corrupção não é sinônimo de perda definitiva. As páginas danificadas podem representar uma fração mínima do arquivo .mdf, e o restante dos dados costuma estar fisicamente presente no disco. A decisão entre restaurar, reparar ou acionar recuperação especializada depende de identificar exatamente o que quebrou e o que ainda pode ser lido sem intervenção destrutiva.
Corrupção física x corrupção lógica
A corrupção física tem origem no subsistema de armazenamento: setores defeituosos no disco, queda de energia durante gravação, controladora RAID com cache sujo, falha de firmware em SSD ou desgaste de mídia. Nesse cenário, o SQL Server recebe do sistema operacional um erro de I/O (como o 823 ou o 824) ao tentar ler ou gravar uma página, e registra a ocorrência no Errorlog. O arquivo .mdf continua lá, mas trechos dele se tornaram ilegíveis no nível do hardware.
Já a corrupção lógica ocorre quando o hardware está íntegro, mas a estrutura interna do banco foi violada: checksum de página inválido, ponteiros de alocação quebrados, metadados inconsistentes após um encerramento abrupto ou bug de aplicação que gravou dados em formato inválido. A distinção importa porque a corrupção física exige, antes de qualquer comando T-SQL, estabilizar o armazenamento — caso contrário, qualquer tentativa de reparo sobre um disco falhando pode multiplicar as páginas perdidas.
Sintomas no SSMS, no log de erros e no SQL Server Errorlog
No SQL Server Management Studio, o sintoma mais evidente é o banco aparecer com estado SUSPECT ou RECOVERY_PENDING em vez de ONLINE. Consultas passam a retornar mensagens como “database is marked suspect”, “could not continue scan with NOLOCK due to data movement” ou erros de checksum em páginas específicas. Aplicações que dependem do banco começam a falhar de forma intermitente, às vezes apenas em tabelas grandes ou em horários de pico de leitura.
O SQL Server Errorlog é a fonte primária de diagnóstico: é nele que aparecem os erros 823 (falha de leitura/gravação no dispositivo), 824 (falha de checksum em página), 825 (falha de leitura com retry) e 9001/9002 (problemas no log de transações). Cada entrada registra o número da página, o arquivo físico e o banco afetado — informação essencial para saber se a corrupção está concentrada em uma região do arquivo ou espalhada por toda a base.
Diagnóstico: como confirmar a corrupção antes de agir
Antes de qualquer comando de reparo ou restauração, é obrigatório confirmar a extensão da corrupção. Agir às cegas — rodar um REPAIR ou sobrescrever o banco com backup — pode transformar uma perda parcial e recuperável em perda definitiva. O diagnóstico em duas camadas (estado do banco + integridade das páginas) é o que separa uma recuperação controlada de um incidente agravado por pressa.
Uma prática que reduz drasticamente o risco é trabalhar sobre uma cópia do arquivo .mdf e .ldf, nunca sobre o original. Com a cópia isolada, o DBA pode executar comandos destrutivos de teste, validar hipóteses e medir o que se perde em cada cenário, sem comprometer a única evidência física do banco.
DBCC CHECKDB e leitura do resultado
O DBCC CHECKDB é o comando padrão para verificar a integridade lógica e física de um banco. Ele percorre páginas de dados, índices, metadados do catálogo e estruturas de alocação, reportando mensagens de erro com severidade e número de página. O resultado é uma lista de mensagens que precisa ser lida de baixo para cima: as últimas linhas trazem o resumo do número de erros de alocação, de consistência e o tempo total de execução.
Dois detalhes mudam a interpretação do resultado. Primeiro, o CHECKDB com a opção PHYSICAL_ONLY verifica a integridade física das páginas sem validar a consistência lógica entre tabelas — útil para triagem rápida, mas insuficiente para descartar corrupção. Segundo, um banco com checksum de página habilitado (opção PAGE_VERIFY CHECKSUM) detecta corrupção muito mais cedo do que um banco configurado com NONE ou TORN_PAGE_DETECTION, porque cada página carrega um valor de verificação calculado na gravação.
Estados do banco: SUSPECT, RECOVERY_PENDING, IN RECOVERY e OFFLINE
Cada estado reflete uma etapa diferente da falha:
- SUSPECT: o processo de recuperação tentou abrir o banco e encontrou erro grave; o SQL Server impede o acesso até intervenção manual.
- RECOVERY_PENDING: o banco não concluiu a recuperação, mas o erro não foi classificado como terminal; ainda há janela para diagnóstico sem reparo destrutivo.
- IN RECOVERY: o banco está em processo de roll forward ou roll back do log; é um estado transitório que pode durar minutos ou horas.
- OFFLINE: o banco foi colocado fora de linha manualmente ou por falha; não aceita conexões, mas os arquivos permanecem intactos no disco.
O estado SUSPECT é o mais perigoso para intervenções caseiras, porque qualquer comando que tente forçar a abertura pode descartar o log de transações e impedir uma recuperação posterior mais completa. O estado IN RECOVERY, por outro lado, muitas vezes se resolve sozinho — o erro está em interromper o processo por impaciência.
As três fases da recuperação e por que o banco fica ‘In Recovery’
Todo banco SQL Server passa por três fases ao ser iniciado: análise, redo e undo. Na análise, o Mecanismo lê o log de transações e identifica quais transações foram confirmadas (commit) e quais estavam em andamento quando o serviço parou. No redo, ele reaplica as transações confirmadas que ainda não haviam sido gravadas nas páginas de dados — o chamado roll forward. No undo, ele desfaz as transações não confirmadas, devolvendo o banco a um estado consistente.
O banco fica em IN RECOVERY durante todo esse processo. Se o log de transações é grande, se o serviço foi interrompido de forma abrupta ou se o subsistema de I/O está lento, a fase de redo pode levar horas. O erro comum é interpretar a demora como travamento e reiniciar o serviço repetidamente, prolongando a indisponibilidade e, em cenários de corrupção no log, podendo agravar o quadro.
Quando a corrupção atinge exatamente o log de transações, o banco pode não conseguir concluir a fase de análise, entrando em SUSPECT ou RECOVERY_PENDING. Nesse ponto, o caminho de recuperação muda: sem log íntegro, as opções de roll forward se esgotam, e a discussão passa a ser sobre o que ainda pode ser extraído diretamente das páginas de dados.
Recuperação a partir de backup: o caminho mais seguro
Quando existe uma cadeia de backups íntegra e testada, a restauração é sempre o caminho de menor risco para recuperar banco de dados SQL Server. Ela não altera o arquivo original, não descarta dados por decisão automática e devolve o banco a um estado conhecido e validado. A segurança, porém, depende de três condições: o backup mais recente cobre a janela de perda aceitável, a cadeia de logs está completa e o backup foi testado em restauração real — não apenas gerado.
Backups que nunca foram restaurados são uma aposta, não uma garantia. Arquivos .bak corrompidos, fitas ilegíveis ou backups truncados por erro de script são descobertos exatamente no pior momento: durante o incidente. Por isso, a validação periódica de restauração é uma prática que separa ambientes preparados de ambientes que apenas acreditam estar preparados.
Restaurar com REPLACE e recuperar o log de transações
O comando RESTORE DATABASE … WITH REPLACE é necessário quando o SQL Server identifica que o banco a ser restaurado já existe e tem um histórico diferente do contido no backup. Sem o REPLACE, a restauração falha com um erro de proteção — o Mecanismo se recusa a sobrescrever um banco que não reconhece como o mesmo. O REPLACE contorna essa checagem e força a substituição dos arquivos.
A sequência correta envolve restaurar o backup completo com NORECOVERY, depois cada backup de log na ordem cronológica, também com NORECOVERY, e finalizar com RECOVERY. Pular um arquivo de log da cadeia interrompe a sequência e impede a aplicação dos logs seguintes. Se o último log disponível estiver corrompido, a restauração pode ser encerrada no log anterior, assumindo a perda das transações posteriores a ele.
Restauração em outro servidor para validar antes de sobrescrever
Antes de sobrescrever o banco de produção, a restauração deve ser validada em um servidor separado. O procedimento usa o mesmo backup, restaura em uma instância de teste e permite conferir se o banco abre, se as tabelas críticas têm a quantidade de registros esperada e se o ponto de recuperação corresponde ao que se acreditava ter salvo. Só depois dessa validação o backup é aplicado em produção.
Essa etapa evita o cenário em que o DBA descobre, após já ter sobrescrito o banco original, que o backup estava incompleto ou que a janela de perda era maior do que o aceitável pelo negócio. Em ambientes com RAID com disco caindo, a validação em servidor separado também protege contra a possibilidade de o próprio storage falhar durante a restauração de produção.
Quando não há backup: opções de recuperação de emergência
Sem backup válido, a recuperação passa a depender da integridade residual do arquivo .mdf e da capacidade de extrair dele o máximo de dados possível. É o cenário de maior risco técnico, porque cada comando executado sobre o banco corrompido pode alterar permanentemente o que ainda existe. A regra de ouro é duplicar os arquivos antes de qualquer tentativa e trabalhar apenas sobre a cópia.
Nesse contexto, a ordem de prioridade é: primeiro tentar colocar o banco online sem reparo destrutivo; segundo, extrair tabelas e páginas específicas que ainda estão íntegras; terceiro, considerar o reparo com perda de dados como último recurso, medindo exatamente o que será descartado.
Reparo com DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS e seus riscos
O DBCC CHECKDB … REPAIR_ALLOW_DATA_LOSS é o comando mais mal compreendido do SQL Server. O nome é literal: ele repara a estrutura do banco permitindo perda de dados. Quando encontra uma página corrompida, o reparo pode realocar linhas para novas páginas, descartar páginas inteiras ou desalocar estruturas que não consegue interpretar. O banco volta a abrir, mas tabelas podem perder registros sem que o DBA saiba quais.
O risco real não é o comando em si, mas executá-lo sem medir a perda. Antes do reparo, o DBCC CHECKDB com as opções de estimativa (ESTIMATEONLY) permite projetar o impacto. Mesmo assim, a estimativa não substitui a extração prévia das tabelas íntegras: se o reparo desalocar uma página que continha dados de uma tabela fiscal, a perda pode ter consequência regulatória ou jurídica. Para bancos de missão crítica, o reparo destrutivo sem extração prévia é uma decisão que raramente se justifica.
Recuperação de tabelas e páginas específicas
Em muitos casos de corrupção, apenas uma fração das páginas está danificada. O banco pode estar offline, mas a maior parte das tabelas continua legível no arquivo .mdf. A recuperação focada consiste em identificar, página a página, quais objetos foram afetados e extrair os demais sem passar pelo processo completo de abertura do banco.
Essa abordagem é especialmente útil quando a corrupção está concentrada em um índice não crítico ou em uma tabela de log da aplicação, enquanto as tabelas de negócio permanecem íntegras. A extração página a página exige leitura direta da estrutura do .mdf, interpretação do GAM/SGAM/IAM e remontagem das linhas — trabalho que ultrapassa o escopo do SSMS e entra no território da recuperação especializada em laboratório.
Erros comuns e o que eles realmente indicam
As mensagens de erro do SQL Server são frequentemente lidas pelo texto literal, quando na verdade apontam para causas diferentes. Dois erros em particular geram confusão recorrente entre DBAs: a falha na espera do identificador de recuperação e os problemas de inicialização dos bancos de sistema. Interpretá-los corretamente evita intervenções erradas sobre arquivos que não precisam ser tocados.
Falha na espera do identificador de recuperação do Mecanismo de Banco de Dados
O erro “Falha ao aguardar o identificador de recuperação do Mecanismo de Banco de Dados” geralmente aparece quando o serviço do SQL Server não consegue iniciar dentro do tempo esperado, deixando o agente ou a aplicação sem conexão. A causa raramente está no identificador em si: quase sempre é um banco grande preso em IN RECOVERY, um log de transações desproporcional ou um subsistema de I/O degradado que atrasa a fase de redo.
O erro também surge em clusters de failover, quando o tempo de inicialização do serviço excede o timeout configurado para o recurso. A resposta correta não é reiniciar o serviço repetidamente, e sim investigar qual banco está segurando a recuperação e por quê. Em cenários com RAID que parou de funcionar, o atraso na recuperação pode ser o primeiro sinal de falha de disco, antes mesmo de qualquer erro de I/O explícito.
Recuperação do banco MSDB e do banco master
O banco master armazena os metadados de toda a instância: logins, bancos registrados, configurações de servidor. Se ele corrompe, o SQL Server frequentemente nem inicia, porque não consegue localizar os demais bancos. A recuperação do master exige reconstruí-lo a partir do template e reanexar os bancos de usuário — operação delicada que depende de backups consistentes do próprio master.
O banco MSDB guarda histórico de backups, jobs do SQL Agent, pacotes SSIS e alertas. Sua corrupção não impede a instância de iniciar, mas elimina o histórico de restauração e pode paralisar rotinas automatizadas. A recuperação do MSDB segue o mesmo fluxo de um banco de usuário, com a diferença de que ele é pequeno e normalmente tem backup diário — o que torna sua perda mais uma questão de restauração rápida do que de recuperação complexa.
Como evitar a próxima corrupção
A corrupção de banco de dados raramente é um evento isolado. Na maioria dos casos, ela é o sintoma final de uma cadeia de decisões: storage sem redundância, backup sem teste, CHECKDB sem agendamento ou monitoramento de I/O inexistente. Prevenir a próxima ocorrência exige atacar a cadeia inteira, não apenas o incidente pontual.
Política de backup, CHECKDB agendado e monitoramento de I/O
Uma política de backup eficaz define, no mínimo, três elementos: frequência do backup completo, frequência do backup de log e retenção. O ponto frequentemente negligenciado é o teste de restauração: um backup que nunca foi restaurado com sucesso não é um backup, é um arquivo com potencial. A restauração periódica em ambiente de teste valida a integridade do .bak e treina a equipe para o dia em que ela for necessária de verdade.
O DBCC CHECKDB deve rodar de forma agendada, idealmente em horário de baixa utilização, com o resultado registrado e revisado. Um CHECKDB que roda e ninguém lê é tão útil quanto um que nunca rodou. O monitoramento de I/O, por sua vez, captura a degradação do storage antes que ela vire corrupção: latência crescente, fila de disco, erros de retry e SMART com setores realocados são indicadores que aparecem dias ou semanas antes do erro 823.
Para ambientes que dependem de storage compartilhado ou RAID em processo de degradação, o monitoramento de I/O precisa incluir a saúde física dos discos, não apenas o desempenho lógico da instância. Um disco com setores pendentes em um RAID 5 pode passar despercebido pelo SQL Server até o momento em que a controladora não consegue mais reconstruir a leitura.
O que define o custo de uma recuperação de banco de dados
O custo de uma recuperação de banco de dados SQL Server não é definido pelo tamanho do arquivo, mas pela complexidade do caso. Os fatores que mais pesam são:
- Extensão da corrupção: páginas isoladas são mais simples do que corrupção generalizada no log ou nos metadados.
- Existência de backup válido: com backup testado, o custo se limita a restauração e validação; sem backup, entra o trabalho de extração página a página.
- Estado do armazenamento físico: se o disco ou RAID está falhando, a recuperação exige estabilizar a mídia antes de tocar no banco.
- Urgência do negócio: parada operacional imediata demanda priorização de laboratório e trabalho fora do horário comercial.
- Necessidade de extração seletiva: recuperar tabelas específicas sem abrir o banco inteiro é mais trabalhoso do que restaurar tudo.
Cada um desses fatores altera o tempo de diagnóstico, as ferramentas necessárias e o risco envolvido. Por isso, qualquer orçamento sério depende de uma análise prévia dos arquivos — valores fechados sem diagnóstico costumam esconder surpresas no meio do processo.
Quando chamar um especialista em recuperação de SQL Server
Há um limite claro para a atuação interna do DBA. Enquanto existe backup válido e o problema se resolve com restauração, a recuperação é uma tarefa de rotina. O cenário muda quando o banco está corrompido, o backup falhou ou não existe, e cada comando executado pode destruir dados que ainda poderiam ser recuperados. Nesse ponto, a decisão técnica correta é interromper as tentativas e preservar os arquivos no estado atual.
Sinais de que a recuperação especializada é o caminho adequado: erro 823/824 recorrente mesmo após troca de disco; banco preso em SUSPECT sem backup; corrupção no log de transações que impede a abertura; necessidade de extrair tabelas específicas de um .mdf que não abre; ou suspeita de falha física no storage. Em todos esses casos, o valor da intervenção especializada está em maximizar o que ainda pode ser salvo, não em prometer resultado garantido.
A mesma lógica se aplica a ambientes com NAS em falha ou storages RAID comprometidos: quando o banco de dados depende de uma infraestrutura que também está falhando, a recuperação precisa tratar a camada física e a camada lógica em conjunto. Tentar resolver apenas o SQL Server sobre um storage morrendo é enxugar gelo — a corrupção volta, porque a causa raiz nunca foi removida.
