Atenção quando fizer um restore vindo de um Database Snapshot!

Posted on junho 5, 2011

0


 

O Database Snapshot é um feature implementada no SQL Server 2005, ela faz com que seja possível tirar fotos das base de dados, menos bases de sistema. Essa foto é uma cópia do banco em read-only ou seja, acesso somente leitura. A partir dessa foto gerada, conseguimos realizar o restore de uma base de dados, ou seja voltar o banco de dados no momento em que a foto foi retirada.

Estudo de Caso

Imagine que temos uma rotina de backup assim para um banco de dados:

Backup FULL – Domingo 12:00 PM

Backup LOG – De 1hs em 1hs

 

Durante a semana, está sendo realizado inserções que tocam várias tabelas no banco, então criamos um database snapshot para garantir que antes que seja iniciado as inserções, tenhamos uma foto do banco de dados em um estado consistente.

  • Database Snapshot Gerados as: 15:10 Hs

 

CREATE DATABASE TesteSnapshotSnap ON

( NAME = TesteSnapshot,

  FILENAME = ‘c:\temp\TesteSnapshot.SS’

) AS SNAPSHOT OF TesteSnapshot

GO

 

Durante a importação, aproximadamente ás 15:30Hs há um erro nas inserções e elas param. O primeiro passo para ser realizado é, colocar a base de dados em um estado consistente novamente, para isso realizamos um restore da base de dados a partir do database snapshot gerado anteriormente.

 

  • Restore do Database Snapshot as 15:35 Hs

USE master

go

 

RESTORE DATABASE TesteSnapshot

FROM DATABASE_SNAPSHOT  = ‘TesteSnapshotSnap’

 

 

O Restore funciona normalmente, depois disso começamos a importação novamente e ela é concluída com sucesso, logo em seguida você recebe um alerta dizendo:

 

Msg 4214, Level 16, State 1, Line 1
BACKUP LOG cannot be performed because there is no current database backup.
Msg 3013, Level 16, State 1, Line 1
BACKUP LOG is terminating abnormally.

Olhando nos JOBS vemos que, esse erro é referente a rotina de backup do banco de dados no qual você acabou de restaurar que roda de 1Hs em 1Hs, mais porque?

Bem, quando realizamos o restore de uma base de dados vindo de um database snapshot, o processo faz com que a cadeia de bakup do log ou seja os sequencias  sejam quebrados. Para que uma nova sequência seja gerada e que seja possível realizar Backups de Log novamente, é necessário que seja realizado um Backup FULL do banco de dados, durante isso a base permanecerá em um modo chamado TRUNCATE LOG ON CHECKPOINT, isso acontece quando não há nenhum backup FULL gerado, todas as informações que estão sendo gravadas no log são apagadas depois de serem comitadas no disco, ou seja, sua base está tendo comportamento igual à uma base em modo de recuperação SIMPLE, preocupante isso não?

Na verdade sim, porque a partir desse momento sua base de dados não fará nenhum backup de log, sendo assim todas alterações, inserções e modificações não estão sendo gravadas no log,  Vamos analisar o seguinte cenário.

  • Visualizando o Log do Banco de Dados antes das inserções.

     DBCC LOGINFO()

 

image

 

INSERT INTO Clientes (Nome, CPF, DataNascimento, Sexo, EstadoCivil, Profissao, UF)

VALUES (‘Luan.Moreno’, ‘022.366.551-77’, ‘1988-07-20’, ‘Masculino’, ‘Solteiro’, ‘DBA’, ‘DF’)

GO 10000

 

  • Visualizando o Log do Banco de Dados depois das inserções.

     DBCC LOGINFO()

 

 

image

 

Essa foto mostra claramente que, os FSeqNo aumentaram mais não houve nenhum crescimento nos VLF’s sendo assim o arquivo de log não cresceu, mostrando que como eu disse anteriormente a base está com comportamento de  TRUNCATE LOG ON CHECKPOINT.

Sempre que for pensar em incluir na sua rotina de backup o database snapshot, pense nisso que acabei de lhe contar.

 

Gostou, então deixe seu comentário.

Abs.

Posted in: Curiosidades