Fala Pessoal,

Aproveitando o ótimo post do Silas Mendes (Backup FULL reinicia sequência do LOG. Mito?), resolvi tirar uma dúvida antiga que tinha sobre backups Full e do Log, mas ainda não tinha parado para realizar os testes.

A minha dúvida é a seguinte: O que acontece se eu executar Backups do Log junto com um Backup Full?  Como fica minha sequência de restores a partir desse backup Full? Como que eu sei qual é o primeiro Backup do Log que eu preciso restaurar após o meu Backup Full?

Suponha que seu ambiente tenha um backup Full diário pela manha e backups do Log a cada 10 minutos durante o dia.

Pela manhã é executado um backup Full conforme o script abaixo:

BACKUP DATABASE FabricioLima TO DISK = ‘C:\FabricioLimaFULL1.bak’
WITH INIT, stats = 10,name = ‘Backup Full 1’

Após executar esse backup, simulando um restore, cliquei com o botão direito em cima da database FabricioLima -> Task -> Restore -> Database, e tenho a seguinte informação:

Em seguida, criei uma tabela e deixei rodando um loop com um insert e um backup do Log simulando exatamente o que acontece durante o dia, manipulação de dados e backups do Log a cada 10 minutos.

CREATE TABLE registroBackup    (id INT IDENTITY,    registro VARCHAR(50))

DECLARE @Nome varchar(30) = ‘BAK do Log: ‘, @i INT = 1

WHILE 1=1
BEGIN
— Insere registro
INSERT INTO registroBackup
VALUES (‘Antes do ‘+CAST(@i AS VARCHAR(2))+’º backup de LOG’)

SET @Nome = @Nome + CAST(@i AS VARCHAR(2))

— Realiza o Backup do Log
BACKUP LOG FabricioLima TO DISK = ‘C:\FabricioLimaLOG.bak’  WITH NOINIT  , Name = @nome

waitfor delay ’00:00:02′
SELECT @i += 1, @nome = ‘BAK do Log: ‘

END

Agora imagina que seu backup FULL tenha falhado pela manhã e você precise rodá-lo novamente, entretanto, você esqueceu de desabilitar o backup do log  e os 2 rodaram simultaneamente. E agora? Preciso desabilitar o job do LOG e iniciar o FULL novamente para manter a sequência correta de restore desse backup FULL?

Não!!! Vamos simular essa situação.

Com o loop em execução, rodei simultaneamente outro backup FULL:

BACKUP DATABASE FabricioLima TO DISK = ‘C:\FabricioLimaFULL2.bak’
WITH INIT, stats = 10,name = ‘Backup Full: 2’

Quando o Backup FULL acabou, parei o loop que faz backup do LOG alguns segundos depois. Agora vamos ver como ficou situação dos backups. Simulando um restore do mesmo modo como como foi feito anteriormente, temos a seguinte informação:

Legal, o SQL Server já incluíu o meu backup FULL 2 no meio dos meus backups de LOG, então é só marcar o Backup FULL e todos os seus backups do Log posteriores e executar o restore. Eu realizei esse restore para uma database chamada FabricioLima2, posteriormente iremos conferir os dados das databases.

Existe alguma forma de verificar essa informação via T-SQL?

Sim. Executando a query abaixo:

select position, name, backup_start_date,
backup_finish_date,first_lsn,last_lsn
from msdb.dbo.backupset
where backup_start_date >= ‘20110430 17:42’    — Inicio dos testes
order by backup_start_date

Temos o seguinte resultado:

Pode-se verificar que o Backup Full 2  começou as 17:43:33 (Azul) e o backup do Log 8 (Preto) terminou e começou as 17:43:34.  Ou seja, o backup Full 2 contém os backups do Log 5, 6 e 7, mas não contém o de número 8.

Entretanto, olhando datas não é um método confiável de se verificar essa informação. Para ter certeza do que realmente entrou e não entrou no backup Full, deve-se olhar as colunas First_LSN e Last_LSN.

Cada registro do log de transações do SQL Server é identificado de forma exclusiva por um LSN (número da sequência de log). Os LSNs são ordenados de tal modo que se LSN2 for maior do que LSN1, a alteração descrita pelo registro de log mencionado por LSN2 ocorreu depois da alteração descrita pelo registro de log LSN.

A coluna First_LSN contém o número de sequência de log do primeiro ou mais antigo registro de log no conjunto de backup.
Já a coluna Last_LSN contém o número de sequência do primeiro registro de log feito após o conjunto de backup.

Como o inicio e o fim de todos os LSN são iguals, olharemos apenas os números intermediários para facilitar a explicação.

É possivel ver que o Backup Full guardou até o LSN 14086 (verde). Já o Backup do Log 8 contém os LSN de 14085 (Vermelho) até 14093. Perceberam que o backup FULL guardou 1 LSN do backup do Log 8? Todavia, ele não guardou todos os LSN’s desse backup 8 e é por isso que ele é o próximo backup que deve ser restaurado.

Descoberto quais arquivos precisam ser restaurados, vamos criar uma nova database chamada FabricioLima3 e restaurar os arquivos via T-SQL:

RESTORE DATABASE [FabricioLima3] FROM  DISK = N’C:\FabricioLimaFULL2.bak’
WITH
MOVE N’FabricioLima’ TO N’C:\FabricioLima3.mdf’,
MOVE N’FabricioLima_log’ TO N’C:\FabricioLima3_Log.ldf’,  NORECOVERY,  NOUNLOAD,  STATS = 10

RESTORE LOG [FabricioLima3] FROM  DISK = N’C:\FabricioLimaLog.bak’ WITH  FILE = 8,  NORECOVERY,  NOUNLOAD

RESTORE LOG [FabricioLima3] FROM  DISK = N’C:\FabricioLimaLog.bak’ WITH  FILE = 9,  NORECOVERY,  NOUNLOAD

RESTORE LOG [FabricioLima3] FROM  DISK = N’C:\FabricioLimaLog.bak’ WITH  FILE = 10,  RECOVERY, NOUNLOAD

Se você tentar restaurar o FILE = 7 após o Backup Full 2, você receberá o erro abaixo:

Msg 4326, Level 16, State 1, Line 2
The log in this backup set terminates at LSN 5334000001408500001, which is too early to apply to the database. A more recent log backup that includes LSN 5334000001408600001 can be restored.
Msg 3013, Level 16, State 1, Line 2
RESTORE LOG is terminating abnormally.

Na figura abaixo temos uma comparação da tabela populada pelo loop da database original para as outras 2 criadas via restore.

Espero que essa informação tenha sido útil.

Gostou desse Post?

Cadastre seu e-mail para receber novos Posts e curta minha Página no Facebook para receber Dicas de Leituras e Eventos sobre SQL Server.

Abraços,

Fabrício Lima

MCITP – Database Administrator

Consultor e Instrutor SQL Server

Trabalha com SQL Server desde 2006