No mês de Abril fiz o curso de SQL Server Internals com o Luciano Moreira, mais conhecido na comunidade como Luti; não vou me estender muito neste assunto, mas se você é um DBA SQL Server, recomendo fortemente que faça este curso. Excelente…

Mas vamos ao foco do nosso post. Durante o curso de internals alguns mitos foram por água abaixo; um deles foi  “Ao realizar um backup full, perdemos a sequência do log”.

Verdade? Sim ou Não?

Bom, confesso que eu sempre tive isso como verdade absoluta e tenho certeza que outros inúmeros DBAs SQL Server pensam o mesmo; mas a verdade é que não, realizar um backup full não quebra a sequência do seu log. Mas falando assim não tem graça né, vamos testar a brincadeira:

Primeiro criamos um banco para nosso teste (no fim do post está o script completo do nosso teste):

CREATE DATABASE testeBackup

Por padrão o SQL Server criar o banco com o recovery model FULL (exceto na edição Express). Isto é importante para o nosso teste já que iremos realizar backup do log. Para confirmar:

-- Recovery Model = FULL
SELECT recovery_model_desc
FROM sys.databases
WHERE NAME LIKE 'testeBackup'

Vamos criar uma tabela para nossos testes e realizar nosso primeiro backup FULL:

USE testeBackup

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

-- Realiza backup FULL
BACKUP DATABASE testeBackup
TO DISK = 'C:\testeBackupFULL.bak' WITH INIT

Agora utilizando uma estrutura de repetição inserimos 1 registro na tabela e realizamos um backup de log. Isso repetirá por 5 vezes:

DECLARE @i INT

SET @i = 1

WHILE @i <= 5
BEGIN
	-- Insere registro
	INSERT INTO registroBackup
	VALUES ('Antes do '+CAST(@i AS VARCHAR(2))+'º backup de LOG')
	-- Realiza backup de log
	BACKUP LOG testeBackup
	TO DISK = 'C:\testeBackupLOG.bak'
	WITH NOINIT
	-- Incrementa contador
	SET @i = @i + 1
END

Verificamos então os registros inseridos na tabela:

SELECT * FROM registroBackup

Resultado:

E verificamos os nossos backups de log:

RESTORE HEADERONLY FROM DISK = 'C:\testeBackupLOG.bak'

Resultado:

Como verificamos temos aí 5 registros e 5 backups de log.

Agora realizamos um novo backup FULL:

BACKUP DATABASE testeBackup
TO DISK = 'C:\testeBackupFULL_2.bak' WITH INIT

E repetimos a execução do laço:

DECLARE @i INT

SET @i = 6

WHILE @i <= 10
BEGIN
	-- Insere registro
	INSERT INTO registroBackup
	VALUES ('Antes do '+CAST(@i AS VARCHAR(2))+'º backup de LOG')

-- Realiza backup de log
	BACKUP LOG testeBackup
	TO DISK = 'C:\testeBackupLOG.bak'
	WITH NOINIT

-- Incrementa contador
	SET @i = @i + 1
END

Ao fim temos 10 registros em nossa tabela, 10 backups de LOG e 2 backups FULL.

Agora entra a figura do estagiário que exclui o segundo arquivo de backup FULL… (sacanagem, rss)

Segundo a lenda, isso inválida todos os backups de log posteriores e teríamos que realizar um backup FULL imediatamente, porque ao realizar o segundo backup FULL perderíamos a seqüência do log.  Certo? Bom… vamos testar:

Excluímos  a base de dados:

USE MASTER
GO
DROP DATABASE testeBackup

E restauramos os backups (FULL + LOGs) ignorando o segundo backup FULL:

RESTORE DATABASE testeBackup
FROM DISK = 'C:\testeBackupFULL.bak' -- primeiro backup FULL
WITH NORECOVERY

-- Restauramos os 10 arquivos de log

DECLARE @i INT
SET @i = 1

WHILE @i <= 10
BEGIN

	RESTORE LOG testeBackup
	FROM DISK = 'C:\testeBackupLOG.bak'
	WITH FILE = @i, NORECOVERY

	SET @i = @i + 1

END

	RESTORE DATABASE testeBackup
	WITH RECOVERY -- colocamos a base em operação

Verifique que restauramos os 10 registros de nossa tabela:

USE testeBackup
SELECT COUNT(*) FROM registroBackup

Resultado:

Enfim, note que a realização do 2º backup FULL não quebrou a seqüência dos nossos backups de log!

Agora a pergunta que não quer calar: qual a função do parâmetro de backup COPY_ONLY lançado a partir do SQL Server 2005?!

Um backup diferencial tem total dependência do último backup FULL; logo, se você perder o backup FULL anterior, não será possível restaurar o diferencial, mesmo com um FULL mais antigo. Então pense numa situação que você precise de um backup FULL adicional, mas não deseja que ele afete seus próximos backups diferenciais (que deverão continuar utilizando como referência o backup FULL anterior), então aqui utilizaríamos o COPY_ONLY.

Resumindo: Os backups diferenciais posteriores iram ignorar um backup FULL com COPY_ONLY.

CONCLUSÃO

Backup FULL não altera a sequência dos backups de LOG. Se você perdeu seu último backup FULL, mas tem um do mês passado e de lá pra cá todos os seus backups de LOG estão intactos, não se desespere! Você conseguirá restaurar seu backup.

PS: Obrigado Luti pela super dica :D

Disponibilizei o script completo deste teste aqui.

Até +

Uma estratégia de backup é algo muito particular de cada negócio; em alguns ambientes críticos é inadimissível a perda de um minuto de informação, já em outros lugares, na ocasião de uma falha, um backup do dia anterior é a solução ideal; logo, a forma como mesclar os diferentes tipos de backups é uma questão a ser analisada (e testada!) com muito critério.

No entanto de uma coisa temos certeza: toda estratégia de backup incluirá um backup completo (comumente chamado de backup FULL) e neste texto iremos focar na recuperação (via script) de um backup completo no SQL Server; para isso utilizaremos como base dois cenários:

• O primeiro cenário abordará o restore de um backup FULL sobre a base original (do backup), por exemplo, sua base de dados atual sofreu alterações inadequadas e agora precisa da restauração do último backup para reaver os dados anteriores.
• No segundo cenário iremos visualizar um DBA que recebe um backup completo de um cliente e precisa restaurá-lo em outro ambiente, por exemplo, para sua equipe de desenvolvimento.

CENÁRIO 1

Temos aqui um arquivo de backup chamado AdventuresWorks_FULL.bak. Antes de restaurá-lo precisamos verificar qual o conteúdo desse arquivo físico e se o backup existente irá atender a necessidade do restore; para isso utilizaremos o seguinte comando:

restore headeronly from disk ='C:\LabRestore\AdventuresWorks_FULL.bak'

Veja o resultado:

No resultado da execução do comando RESTORE HEADERONLY podemos identificar que o arquivo em questão contém três backups (sim! um arquivo físico pode conter inúmeros backups de uma mesma base). Observe a posição de cada backup dentro do arquivo (campo Position), o tamanho de cada um (BackupSize)  e suas respectivas datas (BackupStartDate).

No nosso exemplo vamos restaurar o backup do dia 03 de Fevereiro, logo, o backup a ser restaurado será o da posição 2 (dois). Vamos ao script:

USE MASTER

GO

RESTORE DATABASE AdventureWorks

FROM DISK = 'C:\LabRestore\AdventuresWorks_FULL.bak'

WITH FILE = 2, REPLACE, STATS = 10

A base de dados a ser restaurada é a AdventureWorks, o arquivo de backup está localizado no endereço: C:\LabRestore\AdventuresWorks_FULL.bak. O backup que será restaurado está na posição 2 deste arquivo (FILE = 2). Como a base já existe é necessário sobrescrevê-la, para isto utilizamos a opção REPLACE. O STATS mostrará o progresso da restauração em intervalos de 10 em 10%.

Importante: Numa operação de restore a base não deve estar em uso por nenhum usuário (inclusive você), por isso antes de iniciar o script direcionamos a sessão para o database Master. Se a base estiver em uso, a seguinte mensagem de erro será exibida:

Msg 3101, Level 16, State 1, Line 1

Exclusive access could not be obtained because the database is in use.

Se tudo estiver ok, ao final da execução do script você verá uma mensagem similar a esta:

RESTORE DATABASE successfully processed 22514 pages in 10.209 seconds (18.065 MB/sec).

CENÁRIO 2

Neste cenário o DBA deverá restaurar um backup completo recebido de um cliente externo. O arquivo de backup está identificado como SistemaX_FULL.bak e será restaurado no ambiente de desenvolvimento que é composto por um servidor com um único disco (C:\).

Vamos analisar o conteúdo do arquivo com o RESTORE HEADERONLY:

restore headeronly from disk = 'C:\LabRestore\SistemaX_FULL.bak'

Veja o resultado:

No resultado acima verificamos que existe um único backup neste arquivo. A base do cliente (campo DatabaseName) está identificada por SistemaX e podemos verificar também outros dados como o tamanho do backup e data.

Até aqui tudo bem, mas neste cenário precisamos analisar novos elementos, isso porque a base em questão ainda não existe e ao efetuar a restauração o SQL Server irá trazer além dos objetos deste banco (tabelas, procedures, triggers) suas configurações originais como: endereço dos arquivos físico de dados e log, modo de recovery, etc. Para verificar o estado de algumas destas propriedades podemos utilizar o comando RESTORE FILELISTONLY:

restore filelistonly from disk = 'C:\LabRestore\SistemaX_FULL.bak'

Veja o resultado:

Observe que a base do cliente e seus respectivos arquivos de dados e log estão localizados em discos diferentes. Neste caso, se o DBA realizar um restore comum (como o script utilizado no exemplo anterior) o SQL Server tentará alocar estes arquivos em seus caminhos de origem, logo precisamos alterar este comportamento, já que neste cenário o servidor onde será realizado o restore só possui um disco. Veja o comando:

USE MASTER

GO

RESTORE DATABASE SistemaX
FROM DISK = 'C:\LabRestore\SistemaX_FULL.bak'
WITH
MOVE 'SistemaX' TO 'C:\LabRestore\SistemaX.mdf',
MOVE 'SistemaX_log' TO 'C:\LabRestore\SistemaX_log.ldf',
STATS = 10

A base de dados a ser restaurada é a SistemaX e o arquivo de backup está em: C:\LabRestore\SistemaX_FULL.bak. Observe que adicionamos a opção MOVE; esta opção direciona os arquivos de dados e log para um novo caminho. O restante não muda; continuo utilizando o STATS e desta vez não precisamos do REPLACE já que a base não existia.

É importante destacar que os comandos RESTORE FILELISTONLY e RESTORE HEADERONLY não são obrigatórios num processo de restauração de banco; eles são comandos que recuperam informações sobre os arquivos de backup e estas informações podem auxiliar o DBA no processo de restauração.

Existem outros comandos similares, como o RESTORE VERIFYONLY que verifica se o arquivo de backup está legível.

CONCLUSÃO

Como podemos verificar, o restore de um backup full, via script não é difícil, basta conhecer os comandos certos para recuperar informações sobre o conteúdo do arquivo de backup; estas informações  irão auxiliar o usuário na construção do comando de restore.

Nos próximos posts iremos abordar o restore de backups diferenciais e log. Até +

Bom trabalho!

SQL Virtual Database: It’s As Easy As 1, 2, 3.

O anúncio chamou atenção e resolvi dar uma verificada.

Imagine o seguinte cenário: você tem um backup de uma base de dados SQL Server e precisa restaurá-lo pra trabalhar em cima dele. O backup tem aproximadamente 180 GB e você vai precisar de algumas horas pra restaurá-lo.

Imagine agora que você tenha uma forma de “restaurar” esse backup em 10 minutos e trabalhar em cima dele normalmente, como qualquer outra base de dados do SQL Server, executando consultas, procedures, realizando updates, etc. Essa é a idéia da ferramenta SQL Virtual Database desenvolvida pela Idera.

Algumas pessoas poderão dizer, “ah, mas o SQL Server já tem o Database Snapshot”. Sim, a idéia é parecida, mas o Database Snapshot só pode ser gerado na mesma instância da base de origem e só está disponível a partir do SQL Server 2005 em edições Enterprise. O SQL Virtual Database gera uma base de dados virtual em qualquer instância (inclusive SQL Server 2000) a partir de um arquivo de backup.

Achei a idéia inicial muito boa (o programa está na versão beta) e de certa forma fiquei impressionado com os 9 minutos que esperei para ter uma base virtual, baseada num backup de 180 GB, que estava em outra estação da rede. Particularmente achei uma saída muito interessante pra ambientes de desenvolvimento e homologação.

Vou testá-la repetidamente durante os próximos 14 dias (que é o período do Trial) e se tiver mais considerações posto aqui.

Abaixo algumas telas da ferramenta:

1. Tela de instalação

2. Attach do backup na instância MENDES\SQL05

3. Base virtual anexada à instância

Link para download.

Bom trabalho!