Qual Backup Full meu Differential e Log referenciam?

Bom dia pessoal,

Hoje vou falar de um problema muito interessante que observei no Forum MSDN,que pode confundir alguns pessoas.Situação do Problema:

Você é o DBA da sua empresa e estar com dois Backup Set para restaurar seu banco de dados,ou fazer uma migração,etc.Um Backup Set estar armazenado o Backup Full da sua Base e o outro um Backup Differential.Você não sabe a precedencia destes backups,apenas “cairam” em sua mao,como se fosse uma bomba,juntamente com aquela velha expressão: “Se vira !”.

Ok,com os Backup Set´s em maos,voce começa o restore.Vamos exemplificar a situação utilizando o banco de dados de exemplo Northwind.

–Restaurando o Backup Full
RESTORE DATABASE NORTHWIND FROM DISK = ‘C:BACKUPNORTHWIND_FULL.BAK’ WITH NORECOVERY,REPLACE,STATS = 10

Processed 3768 pages for database ‘NORTHWIND’, file ‘Northwind’ on file 1.
Processed 1 pages for database ‘NORTHWIND’, file ‘Northwind_log’ on file 1.
RESTORE DATABASE successfully processed 3769 pages in 10.481 seconds (2.945 MB/sec).

–Restaurando o Backup Differential
RESTORE DATABASE NORTHWIND FROM DISK = ‘C:BACKUPNORTHWIND_DIFF.BAK’ WITH STATS = 10

Msg 3136, Level 16, State 3, Line 1
This differential backup cannot be restored because the database has not been restored to the correct earlier state.
Msg 3013, Level 16, State 1, Line 1
RESTORE DATABASE is terminating abnormally.

Opa ! Ocorreu um erro no processo de restore do Backup Differential,O que aconteceu ? O SQL Server apontou o erro durante o restore do Backup Differential porque este Backup Differential estar com sua caidea de LSN quebrada,ou seja,o backup Full que ele referencia,de qual ele armazena todas as alterações não é o Backup Full previamente restaurado,com isso o SQL Server não pode restaurar o Backup Differential com a cadeia quebrada de qual iria gerar problemas de integridade na base.

Como poderíamos prever o problema este problema,antes de perder tempo restaurando nosso Backup Full ?

Para assegurar que os nossos Backup Set´s estejam com cadeia de LSN correta,podemos utilizar o comando RESTORE HEADERONLY de qual nos retorna diversas informações sobre nossa midia de backup,como Nome do Backup Set,Tamanho em Bytes,Descrição,Usuário que efetuou o Backup,hora de começo e fim do Backup,entre outras,mas em nosso caso as informações  imprecindíveis são as colunas FirstLSN e DatabaseBackupLSN.

A coluna FirstLSN armazena o Log Sequence Number(LSN) do primeiro ou mais antigo registro de log dentro do Backup Set e a coluna DatabaseBackupLSN armazena o Log Sequence Number(LSN) do mais recente backup Full,é o começo do Checkpoint no instante do começo da operação de backup,esta coluna pode igualar com o valor da coluna FirstLSN caso o banco de dados esteja ocioso no momento do backup.Com isso temos que comparar os valores da coluna FirstLSN da saída do comando RESTORE HEADERONLY contra o Backup Set do Backup Full com o valor da coluna DatabaseBackupLSN da saída do comando RESTORE HEADERONLY contra o Backup Set do backup Differential,essa coluna deve referenciar o mesmo valor da coluna FirstLSN do backup Full,pois o backup differential armazena todas as alterações após este LSN,caso seja diferente a cadeia de LSN estará quebrada,ou seja,este backup differential tem como “base” outro backup Full.

Agora com as informações corretas vamos aos testes.Vamos utilizar o comando RESTORE HEADERONLY contra os Backup Set´s utilizados anteriormente para visualizar a discrepancia entre os LSN.

–Visualizando os LSN.
RESTORE HEADERONLY FROM DISK = ‘C:BACKUPNORTHWIND_FULL.BAK’
RESTORE HEADERONLY FROM DISK = ‘C:BACKUPNORTHWIND_DIFF.BAK’

result

Podemos observar através da imagem,que a primeira linha corresponde a saída do comando RESTORE HEADERONLY do Backup Set Full e a segunda do Backup Set Differential,na coluna FirstLSN marcada como verde visualizamos o LSN do Backup Set Full e se compararmos a coluna DatabaseBackupLSN podemos ver a discrepancia entre os valores,como disse que esta coluna armazena o LSN do mais recente backup Full,se repararmos nesta mesma coluna mas para o Backup Set Full podemos ver que é o mesmo LSN da coluna DatabaseBackupLSN do Backup Set Differential,com isso concluimos que este backup differential referencia o backup Full efetuado anterior a este em nosso exemplo.

Agora vou mostrar a cadeia de LSN completa,efetuando um Backup Differential e um Backup Log para verificarmos os valores em sequencia,representando a cadeia de backup suportada pelo SQL Server.

Exemplo da cadeia de LSN integra,utilizando Backup Full,Differential e Log.

–Backup Full.
RESTORE HEADERONLY FROM DISK = ‘C:BACKUPNORTHWIND_FULL.BAK’
–Backup Differential.
RESTORE HEADERONLY FROM DISK = ‘C:BACKUPNORTHWIND_DIFF(1).BAK’
–Backup Log.
RESTORE HEADERONLY FROM DISK = ‘C:BACKUPNORTHWIND_LOG.TRN’

Result2

Podemos observamos que a coluna DatabaseBackupLSN dos backups set´s Differential e Log referencia a coluna FirstLSN do Backup Set Full,ou seja,a cadeia de LSN estar integra.

Apenas para finalizar ou mostrar a situação,onde poderíamos visualisar as informações de nosso backup Full de qual nosso primeiro Backup Differential mostrado na primeira imagem referenciava.Caso agente tivesse acesso a uma instancia do SQL Server onde foram efetuados os Backup´s poderíamos consultar a tabela de sistema chamada Backupset do banco de dados MSDB,para recuperar algumas informações úteis sobre o backup Full realizado,como “quem” realizou o backup, data e hora,etc. Segue a query de qual responderia as nossas perguntas.

USE MSDB
SELECT *
FROM BACKUPSET
WHERE first_lsn = 2109000000035200044

Result3 

Com isso,concluo meu artigo,sobre como descobri qual backup full os nossos backups differenciais e log referenciam,bem como uma solução para entender o erro 3136 de qual define a cadeia de log quebrada.Espero que gostem,até o próximo.

 

Advertisements

3 Responses to Qual Backup Full meu Differential e Log referenciam?

  1. Marcos Lucas says:

    Parabens muito bom artigo

  2. Gustavo says:

    Oi Felipe,Esse é um recurso bem interessante e pouco explorado. Costumo utilizá-lo em alguns artigos e treinamentos que envolvam o backup. É importante notar que o comportamento do LSN backup full é alterado quando se utiliza a cláusula COPY_ONLY. Com esse recurso dá pra tirar vários FULLs sem "atrapalhar" o diferencial.Abs,

  3. Felipe says:

    Oi GustavoRealmente é um recurso bem interessante,com ele podemos ver de forma clara a cadeia de LSN utilizada pelo SQL Server.Concordo com você que a clausula COPY_ONLY poderia resolver esse problema,como você demonstrou em seu artigo.Obrigado,até mais.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: