Quando um banco SQL Server deixa de responder após uma falha no servidor, a primeira pergunta que surge é se é possível recuperar um banco SQL Server que não abre mais. A resposta é sim — na maioria dos casos — mas o caminho até lá exige diagnóstico técnico preciso e ações imediatas corretas. Diferentemente de um arquivo corrompido que você tenta recuperar com software caseiro, um banco de dados é uma estrutura complexa com logs de transação, índices e metadados interdependentes; qualquer tentativa inadequada de acesso ou reparo pode danificar permanentemente registros críticos da sua empresa.
O que determina a recuperabilidade não é apenas a falha em si, mas como você responde nos primeiros minutos após detectá-la. Reinicializações forçadas, tentativas de rebuild de índices, ou uso de ferramentas genéricas de recuperação aumentam drasticamente o risco de perda irreversível de dados. Com mais de 20 anos de experiência e mais de 170 mil casos analisados, sabemos que a diferença entre recuperar seus dados integralmente e perdê-los para sempre frequentemente vem da decisão que você toma hoje.
Sim, é possível recuperar um banco SQL Server que não abre após falha no servidor — entenda por quê
A resposta curta é: sim, na maioria dos casos é possível recuperar um banco SQL Server que não abre após uma falha no servidor — mas o resultado depende diretamente do tipo de falha, do estado dos arquivos MDF (dados) e LDF (log de transações) e das ações tomadas imediatamente após o incidente. Tentar soluções caseiras sem diagnóstico adequado é o principal fator que transforma um banco recuperável em perda definitiva.
O SQL Server foi projetado com mecanismos internos de recuperação automática — o processo de crash recovery é executado toda vez que o serviço reinicia após um encerramento anormal. Ele percorre o log de transações, aplica as transações confirmadas que ainda não foram gravadas nos arquivos de dados e reverte as transações incompletas. Quando esse processo falha ou trava, o banco fica inacessível, mas isso não significa que os dados foram destruídos. Significa que o mecanismo automático não conseguiu concluir o trabalho — e é exatamente aí que entra a recuperação técnica especializada.
Este guia cobre as principais causas, os métodos de diagnóstico e as abordagens de recuperação disponíveis, do mais simples (restaurar backup) ao mais complexo (extração direta de MDF corrompido). Se o seu ambiente envolve um servidor em RAID ou NAS corporativo, vale também entender o que acontece com os dados quando o servidor não inicializa após falha no RAID, pois os problemas frequentemente se sobrepõem.
Principais causas de um banco SQL Server que não abre após falha
Antes de executar qualquer procedimento de recuperação, é essencial identificar a causa raiz. Cada cenário exige uma abordagem diferente — e aplicar o método errado pode agravar a corrupção.
Corrupção nos arquivos MDF e LDF
A corrupção física ou lógica dos arquivos de banco de dados é a causa mais comum de inacessibilidade. O arquivo MDF contém as páginas de dados e índices; o LDF registra todas as transações. Quando setores do disco subjacente apresentam erros de leitura — seja por falha mecânica em HD, desgaste de células em SSD ou corrupção no array RAID —, o SQL Server não consegue ler as páginas necessárias para montar o banco e o coloca em estado SUSPECT ou RECOVERY PENDING. Corrupção lógica, por sua vez, ocorre quando a estrutura interna das páginas está inconsistente, mesmo que o arquivo seja lido fisicamente sem erros.
Banco preso no estado ‘In Recovery’
Após qualquer reinicialização não planejada, o SQL Server executa automaticamente o processo de recovery antes de disponibilizar o banco. Se o volume de transações não confirmadas no LDF for muito grande, esse processo pode levar horas. O banco aparece como In Recovery no SSMS e qualquer tentativa de conexão é recusada. O problema ocorre quando o processo trava indefinidamente — geralmente por corrupção parcial no LDF ou por inconsistências internas que o mecanismo não consegue resolver sozinho.
Arquivo de log do banco de dados cheio ou inacessível
O arquivo LDF cresce continuamente quando o banco opera em modo de recuperação FULL ou BULK-LOGGED sem backups regulares do log de transações. Quando o disco atinge 100% de capacidade ou o LDF ultrapassa o limite configurado, o SQL Server suspende todas as operações de escrita. Após uma falha nesse estado, o banco pode não inicializar porque o processo de recovery precisa escrever no log para registrar as operações de rollback — e não há espaço disponível.
Desligamento inesperado do servidor durante transações ativas
Quedas de energia, travamentos de hardware, falhas em controladora RAID ou queima de controladora interrompem transações no meio da execução. O SQL Server não teve tempo de gravar o checkpoint final nem de fechar os arquivos de forma limpa. Na próxima inicialização, o mecanismo de recovery precisa reconstruir o estado consistente a partir do LDF — e se o LDF também foi corrompido no desligamento abrupto, o processo falha.
Erro MSSQLSERVER_4064: banco de dados padrão do usuário inacessível
O erro 4064 ocorre quando o banco de dados configurado como padrão para um login específico está offline, corrompido ou foi removido. O usuário simplesmente não consegue conectar ao SQL Server, pois a instância tenta abrir automaticamente o banco padrão durante a autenticação e falha. Embora pareça um problema de acesso, a causa subjacente costuma ser a inacessibilidade real do banco de dados associado.
Como diagnosticar o problema antes de tentar a recuperação
Qualquer intervenção técnica deve ser precedida por diagnóstico. Agir sem entender o estado atual do banco aumenta o risco de perda definitiva dos dados.
Verificando o estado do banco no SQL Server Management Studio (SSMS)
No SSMS, expanda o nó Databases no Object Explorer. O banco problemático exibirá seu estado entre parênteses ao lado do nome: Suspect, Recovery Pending, In Recovery, Offline ou Emergency. Cada estado indica uma fase diferente do problema. Alternativamente, execute a query abaixo para obter o estado de todos os bancos da instância:
SELECT name, state_desc FROM sys.databases;
O campo state_desc retorna o estado legível. Documente esse estado antes de qualquer ação — ele é a primeira informação que um especialista vai solicitar.
Consultando o SQL Server Error Log para identificar a causa raiz
O Error Log do SQL Server registra os eventos com timestamps precisos, incluindo o momento exato da falha, os erros de I/O e as mensagens do processo de recovery. Acesse via SSMS em Management > SQL Server Logs ou execute EXEC xp_readerrorlog;. Procure por mensagens com severity 24 (erro de hardware), severity 25 (erro fatal) e qualquer referência a I/O error, torn page ou checksum mismatch. Essas mensagens indicam corrupção física e sinalizam que a recuperação vai exigir abordagem especializada.
Usando DBCC CHECKDB para avaliar a integridade do banco
O comando DBCC CHECKDB ('nome_do_banco') WITH NO_INFOMSGS, ALL_ERRORMSGS; realiza uma varredura completa de consistência nas páginas do banco. Execute-o somente em leitura, nunca com opções de reparo neste momento — o objetivo aqui é mapear a extensão dos danos, não corrigi-los ainda. O resultado lista as páginas corrompidas, os objetos afetados e a severidade dos erros. Se o banco estiver em estado SUSPECT, será necessário colocá-lo em EMERGENCY MODE antes de executar o CHECKDB.
Passo a passo: como recuperar um banco SQL Server que não abre
Os métodos abaixo estão ordenados do menos invasivo para o mais agressivo. Sempre faça uma cópia dos arquivos MDF e LDF antes de qualquer intervenção.
Método 1 — Restaurar a partir do backup mais recente
Se existe um backup válido, este é o caminho mais seguro e previsível. Execute RESTORE DATABASE nome_do_banco FROM DISK = 'caminho_do_backup' WITH REPLACE, RECOVERY;. Se a estratégia de backup incluir logs de transações, aplique-os em sequência após o backup full para minimizar a perda de dados. Valide o backup antes de iniciar: um backup corrompido ou incompleto não restaura corretamente. Após a restauração, execute DBCC CHECKDB para confirmar a integridade.
Método 2 — Colocar o banco em modo de emergência e extrair os dados
Quando não há backup, o Emergency Mode permite acesso de leitura a um banco SUSPECT:
- Altere o estado:
ALTER DATABASE nome_do_banco SET EMERGENCY; - Coloque em single-user:
ALTER DATABASE nome_do_banco SET SINGLE_USER; - Execute
DBCC CHECKDBpara mapear os danos. - Use scripts de exportação (SELECT INTO, BCP, SSIS) para extrair os dados acessíveis para um banco novo e limpo.
O Emergency Mode não repara o banco — ele apenas remove a proteção que impede o acesso, permitindo que você leia o que ainda é legível.
Método 3 — Desanexar e reanexar os arquivos MDF/LDF no SSMS
Em alguns casos, o banco ficou inacessível por problema de registro interno, não por corrupção real dos arquivos. Desanexe o banco com sp_detach_db, copie os arquivos MDF e LDF para um local seguro e reanexe com sp_attach_db ou via SSMS em Attach Database. Se o LDF estiver ausente ou corrompido, o SQL Server tentará criar um novo log durante o attach — mas isso só funciona se o MDF estiver em estado consistente (shutdown limpo). Caso contrário, o attach falha e é necessário avançar para os métodos seguintes.
Método 4 — Recriar o arquivo de log (LDF) quando ele está corrompido ou ausente
Se o LDF foi perdido ou está corrompido além de recuperação, é possível recriar o log em determinadas condições. No SQL Server 2008 R2 e versões posteriores, o processo envolve colocar o banco em EMERGENCY MODE, executar DBCC CHECKDB com REPAIR_ALLOW_DATA_LOSS e deixar o mecanismo recriar o LDF internamente. Atenção: a opção REPAIR_ALLOW_DATA_LOSS implica exatamente o que o nome diz — transações não confirmadas serão descartadas. Use apenas quando as alternativas foram esgotadas e o objetivo é recuperar o máximo possível dos dados.
Método 5 — Usar DBCC CHECKDB com opções de reparo (último recurso)
As opções de reparo do DBCC CHECKDB existem em três níveis: REPAIR_FAST (apenas metadados, sem perda), REPAIR_REBUILD (reconstrói índices, sem perda de dados) e REPAIR_ALLOW_DATA_LOSS (reparo agressivo, pode descartar páginas corrompidas). Este último deve ser tratado como último recurso absoluto — ele pode tornar o banco funcionalmente acessível ao custo de eliminar dados que ainda poderiam ser recuperados por métodos especializados. Antes de executar, faça cópia dos arquivos e considere envolver um especialista em recuperação de dados.
O que fazer quando o banco fica preso no estado ‘In Recovery’
Quanto tempo o processo de recovery pode levar e quando se preocupar
O tempo de recovery é proporcional ao volume de transações ativas no momento da falha. Em bancos de grande movimentação, o processo pode levar de minutos a várias horas — isso é normal. A regra geral: se o banco está em In Recovery há mais tempo do que o dobro do tempo habitual de inicialização do serviço e não há progresso perceptível nos logs, há motivo para investigar. Reiniciar o SQL Server no meio do recovery não resolve — reinicia o processo do zero e pode piorar a situação.
Como monitorar o progresso do recovery via DMVs
Execute a query abaixo para acompanhar o progresso em tempo real:
SELECT percent_complete, estimated_completion_time, command, status FROM sys.dm_exec_requests WHERE command = ‘DB STARTUP’;
O campo percent_complete mostra o avanço e estimated_completion_time estima o tempo restante em milissegundos. Se o percentual não avança por longos períodos, o recovery está travado — não apenas lento.
Forçar a recuperação com ALTER DATABASE e EMERGENCY MODE
Quando o recovery trava definitivamente, a sequência de intervenção é:
ALTER DATABASE nome_do_banco SET EMERGENCY;ALTER DATABASE nome_do_banco SET SINGLE_USER WITH ROLLBACK IMMEDIATE;DBCC CHECKDB ('nome_do_banco', REPAIR_ALLOW_DATA_LOSS);ALTER DATABASE nome_do_banco SET MULTI_USER;ALTER DATABASE nome_do_banco SET ONLINE;
Reitere: essa sequência pode resultar em perda de dados das transações não confirmadas. Documente tudo e mantenha cópia dos arquivos originais intacta.
Recuperação quando não existe backup disponível
Tentando recuperar dados diretamente do arquivo MDF corrompido
O arquivo MDF tem estrutura interna bem documentada — páginas de 8 KB organizadas em extensões, com cabeçalhos, ponteiros e checksums. Quando o banco não abre por corrupção parcial, é possível ler diretamente as páginas íntegras do MDF e extrair os dados delas, mesmo sem o LDF e sem conseguir montar o banco pelo SQL Server. Esse processo exige ferramentas especializadas e conhecimento profundo da estrutura interna do formato — não é algo que scripts T-SQL padrão conseguem fazer. É o cenário em que a recuperação profissional faz diferença real entre recuperar 90% dos dados ou não recuperar nada.
Situações semelhantes ocorrem em ambientes onde o banco reside em um NAS corporativo ou storage em RAID. Nesses casos, a falha pode ser simultânea no hardware e no banco de dados — e a recuperação exige primeiro reconstruir o array lógico antes de trabalhar o MDF. Entender a diferença entre recuperar dados de um NAS doméstico e de um storage corporativo é relevante para dimensionar o escopo do trabalho.
Ferramentas de terceiros para recuperação de MDF sem backup
Existem ferramentas comerciais — como Stellar Repair for MS SQL, ApexSQL Recover e SysTools SQL Recovery — que tentam reconstruir o banco a partir do MDF corrompido. Elas funcionam para corrupções lógicas leves e para situações em que as páginas de dados estão fisicamente intactas. Não as utilize se o disco ou array subjacente apresenta erros de leitura — cada tentativa de leitura com falha em um HD mecânico danificado deteriora ainda mais a superfície magnética. Nesses casos, a recuperação precisa começar pelo hardware, em laboratório especializado com equipamentos como PC-3000, antes de qualquer abordagem no nível do banco de dados.
Erros comuns durante a recuperação e como resolvê-los
Erro ‘Cannot open database requested by the login’ (4064)
Esse erro bloqueia o login antes mesmo de chegar ao banco problemático. A solução imediata é redirecionar o banco padrão do usuário para master ou outro banco acessível via ALTER LOGIN nome_login WITH DEFAULT_DATABASE = master;. Se o login não consegue nem conectar para executar esse comando, use a conexão de administrador dedicada (DAC) via ADMIN:nome_servidor no SSMS. Após reconectar, investigue e corrija o banco de dados padrão original.
Falha no rollback de snapshot após DBCC CHECKDB e desligamento inesperado
O DBCC CHECKDB cria internamente um snapshot do banco para leitura consistente. Se o servidor cair durante a execução, esse snapshot pode não ser removido automaticamente e bloquear futuras operações. Verifique snapshots órfãos com SELECT name, source_database_id FROM sys.databases WHERE source_database_id IS NOT NULL; e remova-os com DROP DATABASE nome_do_snapshot;. Após a limpeza, reinicie o SQL Server e tente novamente.
Log do tempdb cheio impedindo a inicialização do SQL Server
O tempdb é recriado a cada inicialização do serviço — mas se o disco onde ele reside está cheio, o SQL Server não consegue inicializar. Nesse caso, o serviço nem chega a tentar abrir os bancos de usuário. Libere espaço no disco do tempdb (normalmente o mesmo volume do sistema), ajuste o tamanho inicial configurado nas propriedades do tempdb para um valor compatível com o espaço disponível e reinicie o serviço. Após a inicialização, redistribua o tempdb para um volume com capacidade adequada.
Boas práticas para evitar que o banco SQL Server não abra após falhas futuras
Estratégia de backup: full, diferencial e log de transações
A estratégia mínima aceitável para um banco em produção combina três camadas:
- Backup full — diário, preferencialmente fora do horário de pico, com retenção de pelo menos 7 dias.
- Backup diferencial — a cada 4 a 6 horas, capturando apenas as páginas alteradas desde o último full.
- Backup do log de transações — a cada 15 a 60 minutos, dependendo da criticidade do banco, para permitir recuperação point-in-time.
Armazene os backups em local fisicamente separado do servidor de produção — de preferência em storage dedicado ou nuvem. Um backup no mesmo disco do banco não protege contra falha de hardware. Teste a restauração regularmente: um backup que nunca foi testado não é um backup confiável. Ambientes que hospedam bancos SQL Server em storages corporativos ou NAS em RAID devem considerar também a proteção no nível do array — uma falha de disco pode afetar simultaneamente o banco e o backup se ambos residem no mesmo volume. Veja mais sobre os custos envolvidos em recuperação de dados de servidor RAID empresarial para entender o impacto financeiro de não ter backup.
Configurar alertas de monitoramento para o SQL Server Agent
O SQL Server Agent permite configurar alertas baseados em eventos do Windows Event Log e mensagens de erro do SQL Server. Configure alertas para:
- Severity 19 a 25 (erros fatais e de hardware).
- Mensagens específicas: erro 823 (I/O error), 824 (torn page), 825 (read retry) e 832 (checksum mismatch).
- Espaço em disco abaixo de 20% nos volumes que hospedam MDF, LDF e backups.
- Jobs de backup com falha.
Esses alertas, enviados por e-mail ou integrados a sistemas de monitoramento como Zabbix ou PRTG, permitem agir antes que um aviso se torne uma falha catastrófica. O erro 825, por exemplo, indica que o SQL Server precisou de múltiplas tentativas para ler uma página — sinal precoce de degradação física do disco que, se ignorado, resulta exatamente no cenário descrito ao longo deste artigo.
Quando todos os métodos internos foram tentados sem sucesso — ou quando o problema está no hardware subjacente ao banco —, a recuperação profissional especializada é o caminho que preserva as maiores chances de êxito. Ambientes corporativos que enfrentam parada operacional por inacessibilidade de banco de dados frequentemente têm o problema agravado por tentativas de reparo feitas sem o diagnóstico correto. Quanto mais cedo o caso chega a um laboratório especializado, maiores as chances de recuperação integral dos dados.
