Recuperação de Dados em SQL Server
Resposta direta
Microsoft SQL Server falha por arquivos MDF/LDF/NDF corrompidos, databases em estado SUSPECT ou EMERGENCY, page errors crescentes (824, 823, 829), transaction log truncado e atualizações mal-sucedidas. A HD Doctor recupera 91% dos casos SQL Server via reparo técnico de páginas, extração de tabelas via parser MDF e reconstrução do log. Em 24+ anos atendemos 380+ casos SQL Server. Diagnóstico gratuito em 24h.
Crítico: NÃO rode DBCC CHECKDB com REPAIR_ALLOW_DATA_LOSS sem backup, NÃO faça DETACH/ATTACH em database SUSPECT, NÃO trunque o log com banco em alerta. SQL Server tem comandos destrutivos disfarçados de reparo.
Como o SQL Server organiza os dados
SQL Server usa MDF (Master Data File, arquivo principal), NDF (secundários, opcionais para particionamento) e LDF (Log Data File, transaction log). Páginas de 8 KB com header GAM/SGAM/PFS/IAM. Transaction log usa modelo Full, Bulk-logged ou Simple. Falhas comuns: page tear (página parcialmente escrita), bad block em data file, log corrupto após shutdown abrupto e instâncias em SUSPECT após I/O error.
Sintomas comuns em SQL Server
- Database em estado SUSPECT, EMERGENCY ou RECOVERY_PENDING
- Erro 824/823/829 (consistency errors em páginas)
- DBCC CHECKDB reporta múltiplos erros
- Erro 5172 (header file is incorrect) ao attach
- MDF não abre com "Cannot open database"
- Transaction log cresceu até encher disco e travou
- BACKUP database falha com "page not found"
- Aplicação reporta deadlocks crescentes e queries lentas
Causas mais frequentes em SQL Server
| Causa | % | Recuperável? |
|---|---|---|
| Page corruption (824, 823 errors) | 30% | ✅ Sim, reparo de páginas |
| Database em SUSPECT após I/O error | 22% | ✅ Sim, EMERGENCY mode + repair |
| Transaction log corrompido | 18% | ✅ Sim, reconstrução do log |
| Storage failure (RAID/SAN sob MDF) | 12% | ✅ Sim, recuperação de storage primeiro |
| Header file incorrect (5172) | 10% | ✅ Sim, reparo do header MDF |
| Update SQL Server mal-sucedido | 5% | ✅ Sim, dados em arquivos separados |
| Outros (deleção acidental, drop) | 3% | ✅ Sim, file carving |
Fonte: estatísticas internas da HD Doctor sobre 380 casos de SQL Server entre 2022 e 2025.
O que NÃO fazer em SQL Server com problema
- 1.NÃO rode DBCC CHECKDB com REPAIR_ALLOW_DATA_LOSS sem backup. Esse modo apaga páginas corrompidas mesmo que ainda tenham dados extraíveis.
- 2.Não faça DETACH em database SUSPECT. Database SUSPECT pode não conseguir reattach, causando perda completa.
- 3.Não trunque o transaction log com banco em alerta. Trunca antes do checkpoint pode tornar a recuperação impossível.
- 4.Não rode RESTORE com TRUNCATE_ONLY. Comando deprecated que destrói o log.
- 5.Não substitua MDF por backup antigo sem extrair dados novos. Restore overwrite perde transações pós-último backup.
- 6.Não rode shrink em database corrompido. Shrink reorganiza páginas e pode amplificar corrupção.
Como a HD Doctor recupera SQL Server
Trabalhamos sobre cópias do MDF/LDF/NDF, jamais no original. Reparamos páginas via parser técnico ou extraímos tabelas individualmente.
- 1
Recebimento dos arquivos MDF/LDF/NDF
Você envia os arquivos do banco ou os discos do servidor. Para criptografia TDE, instruções específicas.
- 2
Diagnóstico em 24h
Análise das páginas, headers, identificação de versão SQL Server e tipo de corrupção.
- 3
Laudo gratuito com escopo
Análise técnica antes da aprovação, listando tabelas viáveis e estimando perda.
- 4
Reparo de página técnico
Para corrupção de páginas, usamos parser proprietário que reconstrói GAM/SGAM/IAM/PFS.
- 5
Extração via parser MDF
Quando o database não pode ser attached, extraímos tabelas individualmente analisando o formato MDF nativo.
- 6
Reconstrução do transaction log
Para LDF corrompido, criamos novo log e marcamos último checkpoint estável.
- 7
EMERGENCY mode + DBCC
Quando viável, colocamos em EMERGENCY, fazemos backup e rodamos DBCC CHECKDB com escopo controlado.
- 8
Validação dos dados extraídos
Comparamos contagens de linhas, integridade referencial e checksums com instância de teste.
- 9
Entrega + laudo final
Database restaurado ou tabelas em formato BAK/SQL/CSV, laudo técnico assinado.
Tempo e SLA
| Cenário | Prazo |
|---|---|
| Database SUSPECT (1 MDF) | 5–10 dias úteis |
| Page corruption sem dano físico | 7–12 dias úteis |
| Storage failure + recuperação MDF | 12–22 dias úteis |
| Database criptografado (TDE) | +5–10 dias úteis para análise |
- SLA emergencial 24h disponível para SQL Server em produção.
- Política No Data, No Charge: se não recuperarmos as tabelas críticas que você indicou, você não paga pelo serviço. Diagnóstico gratuito em 92% dos casos.
Versões e ambientes atendidos
Atendemos SQL Server 2005, 2008, 2008 R2, 2012, 2014, 2016, 2017, 2019, 2022, 2025. Edições: Express, Web, Standard, Enterprise, Developer. Azure SQL Database (snapshots), Azure SQL Managed Instance. Tipos: row-store, columnstore, in-memory OLTP. Suportamos TDE (Transparent Data Encryption), Always Encrypted, AlwaysOn Availability Groups, Failover Cluster.
Por que escolher a HD Doctor para SQL Server
- 🏛️24+ anos dedicados exclusivamente a recuperação de dados
- 🔬Sala limpa Classe 100 + infraestrutura SQL Server própria
- 🧠Parser MDF nativo + reparo de páginas + reconstrução de log
- ⚡SLA emergencial 24h para SQL Server em produção
- 🤝Único Platinum oficial Western Digital com laboratório regional
- ⚖️Laudo técnico assinado, válido para perícia e seguro
Perguntas frequentes sobre SQL Server
Database em SUSPECT, ainda dá pra recuperar?
Sim, em 90% dos casos. SUSPECT é estado de proteção quando SQL Server detecta corrupção. Colocamos em EMERGENCY, extraímos as tabelas via parser e reconstruímos.
Erro 823/824 em produção. O que fazer?
Page corruption errors. Pare a aplicação, faça backup do MDF/LDF e mande para análise. NÃO rode DBCC CHECKDB com REPAIR_ALLOW_DATA_LOSS antes do diagnóstico.
Perdi o LDF. Recupera só com MDF?
Sim, em 85% dos casos. Sem LDF, o database fica sem transaction log mas conseguimos extrair os dados. Pode haver perda de transações não commitadas.
Database criptografado com TDE. Conseguem?
Sim, com a master key e o certificate de TDE. Sem essas chaves, o MDF é matematicamente irrecuperável.
Storage do servidor pegou fogo. Tem chance?
Sim. Recuperamos primeiro os discos físicos do storage (RAID/SAN), depois extraímos os arquivos MDF/LDF e processamos.
Como funciona o orçamento?
O diagnóstico é gratuito. Após análise técnica em até 24h, enviamos por e-mail ou WhatsApp o orçamento detalhado.
SQL Server em SUSPECT? Fale agora
SLA emergencial corporativo disponível 24h.