Não foi possível restaurar (erro 3456)

Eu tenho uma situação que não é fácil de entender e pensei em perguntar neste fórum se outras pessoas podem ter sugestões.

Estou executando o SQL Server 2008 R2 Standard SP3 no Windows Server 2008R2 Enterprise.

Um banco de dados precisava de manutenção e, após o fato, eu precisava restaurar em outro servidor. Eu tenho um backup de banco de dados completo feito com COPY_ONLY mais um conjunto de 4 backups de tlog.

antes de iniciar, crie tlogbackup1
mudar de FULLpara BULK_LOGGEDmodelo de recuperação
adicionar novo grupo de arquivos
adicionar arquivo ao newfilegroup
defina newfilegroup como padrão
selecione na tabela (no novo grupo de arquivos)
soltar tabela original
excluir arquivo original
excluir grupo de arquivos original
alterar o nome da nova tabela para corresponder à tabela original
alterar o nome do arquivo do newfilegroup para corresponder ao grupo de arquivos original
alterar o nome do arquivo no catálogo para corresponder ao nome do arquivo original
alterar o nome do arquivo no nível do SO para corresponder ao nome do arquivo original
defina o grupo de arquivos padrão como o original
trazer db online
mudar de BULK_LOGGEDpara FULLmodelo de recuperação
Após a conclusão de todas as etapas, crie tlogbackup2

A restauração de todos os backups deve usar WITH MOVE, devido a alterações na letra da unidade no servidor de restauração.

Etapas de recuperação:

RESTORE database SomeDB FROM DISK = 'D:\REPRO\SomeDB.bak'   
WITH 
MOVE 'SystemData' TO 'D:\SQLDATA\SomeDB.mdf'
,MOVE 'SystemDataPDS' TO 'D:\SqlData\SomeDB.ndf'
,MOVE 'SystemData_log' TO 'D:\SQLLogs\SomeDB.LDF'
,NORECOVERY
,stats = 1

RESTORE LOG SomeDB FROM DISK = 'D:\REPRO\tlogbackup1.trn'   
WITH 
MOVE 'SystemData' TO 'D:\SQLDATA\SomeDB.mdf'
,MOVE 'SystemDataPDS' TO 'D:\SqlData\SomeDB.ndf'
,MOVE 'SystemData_log' TO 'D:\SQLLogs\SomeDB.LDF'
,NORECOVERY
,stats = 1

RESTORE LOG SomeDB FROM DISK = 'D:\REPRO\tlogbackup2.trn'   
WITH 
MOVE 'SystemData' TO 'D:\SQLDATA\SomeDB.mdf'
,MOVE 'SystemDataPDS' TO 'D:\SqlData\SomeDB.ndf'
,MOVE 'SystemData_log' TO 'D:\SQLLogs\SomeDB.LDF'
,NORECOVERY
,stats = 1

A restauração final do tlog chega a 100% e falha com o erro 3456:

Processado 368 páginas para o banco de dados 'SomeDB', arquivo 'SystemData' no arquivo 1.

Páginas processadas 7656520 para o banco de dados 'SomeDB', arquivo 'SystemDataPDS' no arquivo 1.

172430 páginas processadas para o banco de dados 'SomeDB', arquivo 'SystemData_log' no arquivo 1.

A mensagem 3456, nível 16, estado 1, linha 1
não pôde refazer o registro de log (210388: 123648: 232), para o ID da transação (0: 1016710921), na página (4: 8088), banco de dados 'SomeDB' (ID do banco de dados 6) . Página: LSN = (0: 0: 1), tipo = 11. Log: OpCode = 4, contexto 11, PrevPageLSN: (210388: 122007: 1). Restaure a partir de um backup do banco de dados ou repare o banco de dados. A mensagem 3013, nível 16, estado 1, linha 1 RESTORE LOG está sendo finalizada de maneira anormal.

Apenas para verificar se o backup completo do banco de dados estava ok, restaurei a CHECKDBexecução e não houve erros.

Todo o feedback recebido.

Desde já, obrigado,

Ned Otter

— NedOtter
fonte

Você poderia explicar por que acha que possui uma cadeia de logs ininterrupta? No momento em que você inverteu o banco de dados no modo BULK_LOGGED e começou a mexer no esquema, todas as apostas em manter a cadeia de logs ininterrupta estão desativadas.

— Thomas Kejser

Obrigado pela sua resposta, Thomas. Vejo agora que o título da minha postagem estava incorreto. Não preciso de uma recuperação pontual, mas de uma restauração completa no final do quarto backup do tlog. Portanto, a configuração de BULK_LOGGED não deve ter causado nenhum problema. Não vejo como o que fiz causaria falha no segundo backup do tlog - todos os comandos eram suportados pelo SQL Server e executei exatamente as mesmas etapas (embora não nos mesmos dados) em um banco de dados menor, e consegui restaurar o segundo backup do tlog sem problemas.

— NedOtter

O erro parece corrupção. É um erro interno. Você pode verificar a integridade de todos os arquivos de backup? Eles estão com somas de verificação?

— usr

Eu verifiquei se o backup completo do banco de dados tinha 0 erros executando o CHECKDB. Vou ter que verificar se CHECKSUM foi usado.

— NedOtter

Se os backups tiverem a soma de verificação ativada, você também deverá usar a soma de verificação para a restauração. O tipo de página 11 é uma página do PFS, o que significa que você não pode corrigi-lo, você só pode fazer uma restauração completa. Além disso, você não diz quando foi feito o backup apenas da cópia. Onde estava esse backup na linha do tempo?

— Robert L Davis

Para entender por que o erro 3456 seria lançado, precisamos dar um pequeno passo para trás e entender como o SQL Server lida com esse canto da recuperação.

Quando o SQL Server está refazendo uma operação e refazendo uma modificação de página, ele faz uma verificação rápida. No cabeçalho da página, finalmente haverá um PageLSN, que é uma indicação do último LSN que modificou essa página, gravado pela página. Pense assim, a página controla o último LSN que fez modificações nele. Este é o PageLSN.

Toda vez que há uma operação de modificação da página registrada, esse registro de log inclui alguns LSNs. Ou seja, o LSN do registro de log (pense ... LSN atual ) e, em seguida, tem o que é chamado LSN da Página Anterior ( PrevPageLSNdaqui para frente). Portanto, quando modificamos uma página, um dos dados inseridos no registro de log é o que a página indica como sendo o último LSN antes de você ter modificado a página .

Pense assim ... Seu carro precisa ter trabalho nele. O mecânico John trabalha no seu carro e, no compartimento do motor, tem uma pequena etiqueta e o mecânico John escreve "John trabalhou neste carro por último". Da próxima vez que você levar seu carro para outra loja, o mecânico Mark olha no compartimento do motor e vê que o mecânico John trabalhou nesse carro pela última vez. Em sua folha de dados, ele escreve essas informações. Mesma idéia com o SQL Server.

Isso pode ser um pouco confuso, então dê uma olhada nesta imagem abaixo sobre modificações de páginas seqüenciais, e como o PageLSNe PrevPageLSNrelacionar:

insira a descrição da imagem aqui

Vamos voltar, pois tudo isso entra em ação quando você precisa refazer uma operação em uma página (restaurações, recuperação, HA, etc.). Quando o SQL Server precisa refazer uma operação de página, ele faz uma verificação de integridade para verificar se PageLSNa página corresponde à PrevPageLSNque o registro de log inclui. Se isso não for igual, você verá o erro 3456 ser lançado.

Does PageLSN igual PrevPageLSN ? Não??? Erro de parada e aumento 3456 ...

Vamos analisar sua mensagem de erro, que inclui como:

Não foi possível refazer o registro de log (210388: 123648: 232), para o ID da transação (0: 1016710921), na página (4: 8088), banco de dados 'SomeDB' (ID do banco de dados 6). Página: LSN = (0: 0: 1) , tipo = 11. Log: OpCode = 4, contexto 11, PrevPageLSN: (210388: 122007: 1) . Restaure a partir de um backup do banco de dados ou repare o banco de dados. A mensagem 3013, nível 16, estado 1, linha 1 RESTORE LOG está sendo finalizada de maneira anormal.

Coloquei em negrito os dois dados que têm uma desigualdade causando o erro. Você pode ver que nosso PageLSNé 0: 0: 1 (foi encontrado no cabeçalho da página) e nosso PrevPageLSNé 210388: 122007: 1 (foi encontrado nos dados no registro de log que estava tentando ser refeito). Obviamente estes não são iguais, portanto, err3456.

Portanto, para descobrir o porquê desse evento, seria descobrir por que há uma disparidade aqui. Nós realmente precisamos rastrear o ciclo de vida da página 4: 8088 e ver onde está a desconexão. Infelizmente, sem mais informações ou solução prática de problemas, não há muito o que fazer além de fornecer os antecedentes dessa operação de recuperação e o que causa o erro.

— Thomas Stringer
fonte

Eu sei que já faz um tempo, mas ainda ... coisas boas, obrigado pela explicação completa!

— RThomas