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
FULLparaBULK_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_LOGGEDparaFULLmodelo 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 = 1A 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
fonte
Respostas:
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 é oPageLSN.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
PageLSNePrevPageLSNrelacionar: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:
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 nossoPrevPageLSNé 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.
fonte