Entender como o SQL Server armazena dados internamente no arquivo MDF é o que separa uma recuperação forense bem-sucedida de um banco perdido. Além disso, esse conhecimento explica por que o DBCC CHECKDB com REPAIR_ALLOW_DATA_LOSS destrói dados que a forense ainda conseguiria recuperar — e por que a Crowdertech consegue extrair tabelas e stored procedures de bancos que o SQL Server declara como irrecuperáveis.

A unidade fundamental: a página de 8KB

O SQL Server organiza todos os dados em páginas de 8KB dentro do arquivo MDF. Além disso, cada página tem uma estrutura fixa e bem documentada, o que torna a leitura forense possível mesmo quando o motor do banco não consegue iniciar.

Cada página de 8KB é composta por três partes:

Cabeçalho da página (96 bytes): contém o número da página, o ID do objeto ao qual pertence, o tipo da página, o nível no índice e o checksum. Por isso, a leitura do cabeçalho permite identificar a qual tabela ou índice cada página pertence — sem depender do motor do SQL Server.

Área de dados (aprox. 8.060 bytes): contém as linhas de dados ou as entradas de índice. Além disso, cada linha começa com um offset que indica onde a linha termina e a próxima começa.

Slot array (variável): localizado no final da página, é uma tabela de offsets que aponta para cada linha dentro da área de dados. Portanto, o slot array é o que permite navegar pelas linhas sem ler a página inteira.

Tipos de página — o que cada uma guarda

O SQL Server tem vários tipos de página, cada um com função específica:

Tipo 1 — Data pages: guardam as linhas de dados das tabelas. É onde os registros que você inseriu com INSERT vivem. Por isso, são as páginas mais valiosas na recuperação forense.

Tipo 2 — Index pages: guardam entradas de índice B-tree. Além disso, em tabelas com índice clustered, as próprias linhas de dados vivem nas index pages.

Tipo 3 — Text/Image pages: guardam dados LOB (Large Object) — VARCHAR(MAX), NVARCHAR(MAX), VARBINARY(MAX). Portanto, arquivos e textos longos armazenados no banco ficam aqui.

Tipo 4 — PFS pages: Page Free Space — mapa de quais páginas têm espaço disponível. Por isso, são referência para entender a organização do arquivo.

Tipo 8 — GAM pages: Global Allocation Map — mapa de quais extents (grupos de 8 páginas) estão alocados. Além disso, são o ponto de entrada para mapear toda a estrutura do banco.

Tipo 10 — IAM pages: Index Allocation Map — mapa de quais extents pertencem a cada objeto (tabela ou índice). Portanto, as IAM pages são o GPS da forense — elas mostram exatamente onde cada tabela está armazenada fisicamente.

Como a corrupção se manifesta nas páginas

Quando o SQL Server detecta uma página corrompida, apresenta erros como:

  • Msg 824: indica que o checksum da página não confere — a página foi modificada de forma inesperada
  • Msg 823: indica falha física de leitura — o disco não conseguiu entregar a página
  • Msg 8928: indica que a página está marcada como alocada mas não é acessível

Contudo, esses erros não significam que os dados sumiram. Significam que aquela página específica tem problema. Por isso, as demais páginas do mesmo arquivo frequentemente estão íntegras e acessíveis por forense.

Por que o DBCC CHECKDB destrói o que a forense recuperaria

O DBCC CHECKDB WITH REPAIR_ALLOW_DATA_LOSS resolve a corrupção da perspectiva do SQL Server de uma forma específica: ele descarta as páginas corrompidas. Além disso, quando a página corrompida contém linhas de dados, essas linhas são perdidas permanentemente.

Contudo, a recuperação forense faz o caminho inverso: lê as páginas corrompidas com ferramentas de baixo nível, extrai as linhas ainda legíveis dentro da página — mesmo que o checksum falhe — e complementa com os dados das páginas íntegras ao redor.

Por isso, rodar DBCC CHECKDB com reparo antes da forense é o erro mais caro que um DBA pode cometer. Além disso, o backup da opção de reparo deveria ser literal — o DBCC apaga, não repara.

A leitura forense página a página — como a Crowdertech faz

A Crowdertech não depende do motor do SQL Server para acessar os dados. Portanto, bancos que não sobem, que reportam corrupção severa ou que foram criptografados por ransomware são tratados da mesma forma.

1. Leitura do cabeçalho do MDF: identificamos a versão do banco, o número de páginas e o estado do checkpoint. Dessa forma, sabemos o estado geral antes de qualquer extração.

2. Mapeamento via páginas GAM e IAM: localizamos cada objeto (tabela, índice, stored procedure) mapeando as IAM pages. Portanto, sabemos exatamente em quais páginas cada tabela está armazenada.

3. Extração de data pages: lemos cada data page individualmente, verificamos o checksum quando possível e extraímos as linhas de dados usando o slot array.

4. Reconstrução do esquema: as informações de esquema do banco (nomes de colunas, tipos de dados, constraints) vivem nas tabelas do sistema (sys.columns, sys.objects, sys.types) — também acessíveis por forense das páginas do catálogo.

5. Reconstituição dos objetos: reconstituímos tabelas, views, stored procedures e funções a partir das páginas íntegras — mesmo sem o arquivo de log (LDF) e mesmo sem o motor do banco subir.

Keywords técnicas para SEO

SQL Server internals · MDF file structure · SQL Server page header · data pages SQL · index pages SQL Server · IAM pages · GAM pages · PFS pages · extents SQL Server · DBCC PAGE · DBCC CHECKDB alternativa · recuperação forense SQL Server · MDF corrompido sem backup · SQL Server sem LDF · page checksum SQL Server · Msg 824 SQL Server · Msg 823 SQL Server

Perguntas frequentes sobre estrutura interna do SQL Server

Por que é possível recuperar SQL Server sem o arquivo LDF? O arquivo LDF contém o log de transações para recovery — não os dados em si. Os dados vivem no MDF, nas data pages. Portanto, com o MDF íntegro, a recuperação forense acessa os dados diretamente sem depender do LDF.

DBCC PAGE é seguro para diagnóstico de corrupção? Sim — é somente leitura. Além disso, o DBCC PAGE permite inspecionar o conteúdo de qualquer página do banco sem modificar nada. Portanto, é uma ferramenta segura para diagnóstico antes de acionar especialistas.

SQL Server com corrupção em página do catálogo (sys.objects) tem recuperação? É mais complexo, mas frequentemente sim. A Crowdertech lê as tabelas do sistema por forense direta e reconstrói o mapeamento de objetos mesmo com corrupção no catálogo.

Banco SQL Server de 500GB corrompido leva quanto tempo para recuperar? Depende do grau de corrupção. A Crowdertech entrega o diagnóstico em horas. A recuperação completa leva de 24 a 72 horas para a maioria dos casos.

Conclusão

Entender a estrutura interna de páginas do SQL Server explica por que a recuperação forense funciona onde o DBCC CHECKDB falha — e por que o banco não precisa subir para os dados serem acessíveis. Além disso, esse conhecimento é o que diferencia a Crowdertech de laboratórios que trabalham apenas na camada de sistema operacional. SQL Server MDF corrompido? A Crowdertech recupera banco a banco, página a página. Veja também recuperação de banco de dados e recuperação de ransomware.

Fontes: Microsoft SQL Server Documentation · NIST SP 800-86.