RESTORE detected an error on page (0:0) in database "database_name" as read from the backup set.

Olá!

Compartilharei uma experiência muito interessante que tive recentemente e que vem ao encontro do meu pensamento que DBAs tem de conhecer não somente o SGBD, como também o ambiente aonde eles se encontram.

Primeiramente, meu cenário, três servidores como descrito abaixo:

• [servidor_antigo] - Windows Sever 2003 R2 SP2 + SQL Server 2005 SP4
• [servidor_relatorios] - Windows Server 2012 R2 + SQL Server 2008R2 SP2 CU10
• [servidor_novo] - Windows Server 2012 R2 + SQL Server 2008R2 SP2 CU10

Importante informar que tanto o [servidor_antigo] quanto o [servidor_novo] eram VMs dentro de uma estutura de Blade Server + VMware. Objetivando a substituição do [servidor_antigo] pelo [servidor_novo], após as devidas configurações, iniciei testes para garantir uma migração o mais trasnparente possível.

Por uma necessidade de negócio, diariamente o [servidor_antigo] realizava um backup full em um disco local que posteriormente era restaurado no [servidor_relatorios] para, como o próprio nome sugere, serem processados relatórios com querys de longa duração. Este restore era feito lendo o arquivo de backup no [servidor_antigo] através de um compartilhamento de rede.

Realizei um backup full do meu banco de teste no [servidor_novo] em um disco local e após o termino disparei o restore deste backup no [servidor_relatorios] também através de um compartilhamento de rede, exatamente como a rotina diária já existente fazia e, para minha surpresa:

RESTORE detected an error on page (0:0) in database "[nome do meu database]" as read from the backup set.

Error: 3183, Severity: 16, State: 1.

A primeira coisa que fiz foi validar o backup no [servidor_novo] usando o comando :

RESTORE VERIFYONLY

FROM [caminho do meu arquivo de backup]

WITH CHECKSUM

O que me retornou que o backup estava ok. Sendo assim, por desencargo, também executei:

DBCC CHECKDB([nome do meu database]) WITH NO_INFOMSGS

Database e backup validados. Como o [servidor_novo] era SQL Server 2008 R2, eu estava fazendo o backup já com compactação do SQL Server e dividindo o arquivo em quatro partes, sendo assim, resolvi fazer um backup no modelo do [servidor_antigo], um arquivo apenas e sem compactação. No momento do  restore, logo no início do processo:

RESTORE detected an error on page ([X]:[Y]) in database "[nome do meu database]" as read from the backup set.

Error: 3183, Severity: 16, State: 1.

Iniciei um novo restore para mais um teste, e este demorou um pouco mais e me retornou valores de [X] e [Y] totalmente diferentes, executei um VERIFYONLY neste novo arquivo e novamente um ok.

Neste ponto, abandonei a idéia de ser um problema nos arquivos de backup e comecei a desconfiar de algo de errado na rede que ligava as duas máquinas. Efetuei alguns testes de ping básicos, inclusive durante os processos de restore, porém sem nenhuma anormalidade.

Fiz algumas pesquisas nesse aspecto e achei algumas pessoas relatando problemas de performance quando as opções de TCP Offload Engine (TOE) das placas de rede estavam ativadas. O TOE é uma tecnologia de hardware existente em placas de rede de alta performance que visa retirar da CPU do host o custo de alguns processos e realizá-los diretamente na própria placa de rede.

No passado eu já havia lido artigos que estas opções podiam causar lentidão em VMs sobre Microsoft Hyper-V Server, mas nunca havia lido nada sobre este comportamento em VMware. Achei também relatos de lentidão em máquinas que possuiam placas Broadcom (placa de rede real do meu Blade Server) ou Intel (placa de rede que o VMWare emula na VM).

Com base nisso, desabilitei todas as opções de Offload de minha placa de rede no [servidor_novo] e iniciei um restore do mesmo arquivo unico de backup sem compactação que mencionei anteriormente, concluído com sucesso.Efetuei um novo backup, agora compactado e dividido em quatro partes, iniciei o restore e, para minha satisfação, concluído com sucesso.

As opções de TOE, no meu caso, eram realmente o problema, provavelmente durante a transferência de um arquivo grande (meu backup tinha por volta de 260 GB) os pacotes se corrompiam no transporte, tanto que, utilizando backup compactado, o SQL Server não conseguia descompactar o pacote para descobrir as páginas que ele continha (por isso sempre página 0:0), já no descompactado, ele conseguia (valores de [X], [Y] aleatórios) .

Por agora é isto senhores, até mais e obrigado pelos peixes.