Olá Pessoal, Feliz 2016.
Este é um post importante para mim, pois depois de muito tempo longe do blog por motivos profissionais e pessoais, volto a postar.
Muita coisa aconteceu na minha vida com planos que começaram no segundo semestre de 2014, onde me dediquei quase que integralmente. Desde já peço desculpas pelo silêncio no blog e minha ausência nos eventos do PASS pelo Brasil.
Mas vamos ao que interessa.
Recentemente, o meu grande amigo Edvaldo Castro [Blog | twitter] compartilhou com um grupo de amigos um post do Brent Ozar, onde ele escreve sobre realizar o backup de log a cada minuto.
Sim, é isso mesmo que você leu. Backup de log a cada minuto.
Começou então a análise sobre o custo x benefício desta prática dentro do grupo.
O Brent faz excelentes argumentações e ponderações em seu post, principalmente no que se refere (falei igual a Dilma agora. rs… putz!) a questão estratégica envolvida na política de backup e recuperação dos dados.
O post é muito interessante e vale a leitura.
Segue o link: http://www.brentozar.com/archive/2014/02/back-transaction-logs-every-minute-yes-really/
Mas o assunto deste meu post ainda não é este.
O compartilhamento deste post do Brent Ozar pelo o Edvaldo, me fez lembrar do último encontro do PASS Chapter aqui da cidade onde moro.
Neste encontro, em um determinado momento estava sendo discutido a frequência do backup de log, onde o palestrante estava justamente afirmando fazer o backup de log a cada minuto e uma pergunta foi feita por uma ouvinte na pequena plateia:
“Você já parou para pensar que a cada backup de log você está forçando um checkpoint? ”
Silêncio na sala e o palestrante responde:
“Esta é uma boa pergunta! Não pensei nisso.”
Não estava 100% certo se a pergunta feita fazia total sentido, mas no momento me pareceu coerente.
Não dei muita atenção para o assunto pois não estava trabalhando como DBA no momento e com pouca motivação para fazer um teste deste caso em casa, o que normalmente faria quando fico em dúvida sobre algum assunto em palestras que assisto. Tomo nota e faço testes.
Mas agora é outra história. Estou voltando à ativa após alguns meses de férias do SQL Server.😀
Sendo 100% correta a pergunta feita no encontro do PASS Chapter e considerando a frequência sugerida para o backup de log a cada minuto, fiquei muito preocupado com o possível overhead gerado em ambientes de alto volume transacional, em função da escrita das dirty pages em disco pelo checkpoint.
Isso me intrigou demais e estava custando a acreditar que a cada execução de um backup de log um checkpoint é executado.
Conversei com alguns amigos e 100% acreditavam que todo o backup (FULL, DIFF e LOG) força um checkpoint.
Ainda desconfiado, fui atrás de documentação pois acredito que está é a melhor forma de tirar a sua dúvida e encontrei o que procurava no documento oficial do produto.
https://technet.microsoft.com/en-us/library/ms189573(v=sql.105).aspx
Ou seja, o checkpoint somente é chamado em operações de backup de banco de dados e não de backup de log.
Para obter mais informações sobre o checkpoint, acessem os links abaixo:
https://technet.microsoft.com/en-us/library/ms188748(v=sql.105).aspx
http://www.sqlskills.com/blogs/paul/how-do-checkpoints-work-and-what-gets-logged/
O leitor amigo poderia então ponderar: “Ok Leandro, mas esta parte da documentação pode ter duplo sentido e o backup de log pode estar sendo considerado nesta afirmação.”
Ok. Apesar de considerar que a afirmação contida na documentação oficial é direta ao ponto, vamos testar.
Iniciando os testes…
Para realizar o teste, vamos fazer uso da função fn_dblog para leitura das operações realizadas no arquivo de log de uma base dados.
Você pode encontrar maiores informações sobre esta função na internet, uma vez que não é o objetivo deste post explicar maiores detalhes sobre esta função.
Primeiramente, iremos criar a nossa base de dados.
CREATE DATABASE [BkpLog_vs_Checkpoint] ON PRIMARY ( NAME = N'BkpLog_vs_Checkpoint', FILENAME = N'C:\SQLServer\Data\BkpLog_vs_Checkpoint.mdf' , SIZE = 5120KB , FILEGROWTH = 1024KB ) LOG ON ( NAME = N'BkpLog_vs_Checkpoint_log', FILENAME = N'C:\SQLServer\Log\BkpLog_vs_Checkpoint_log.ldf' , SIZE = 1024KB , FILEGROWTH = 1024KB) GO
A título de curiosidade, vamos verificar quantos VLFs temos e também quantos estão ativos (status = 2) usando o comando “DBCC LOGINFO ()”. Obviamente, deverão existir 4 VLFs neste nosso ambiente considerando o tamanho do arquivo de log na criação da base de dados.
USE [BkpLog_vs_Checkpoint] GO DBCC LOGINFO()
Está aí. 4 VLFs criados na criação da base de dados (CreateLSN = 0) e apenas um VLF ativo (Status = 2). Tudo normal.
Apesar deste banco estar em recovery model FULL, como vocês devem saber, até que seja realizado um backup FULL em uma base de dados recém-criada, o comportamento desta base de dados será como se estivesse em recovery model SIMPLE, ou seja, operando em auto-truncate mode.
Vamos confirmar o recovery model desta base de dados. Aproveito também e verifico se tem algo impactando a reutilização dos VLFs.
Como deveria ser, está tudo normal.
Fazendo o backup FULL e saindo do modo auto-truncate. Vamos usar o GETDATE para dar a noção da hora de execução, pois iremos usar esta informação mais na frente.
Após a execução do backup FULL, vamos verificar quantas operações temos no arquivo de log usando a função fn_dblog. 
Analisando estas operações existentes no transaction log.
A considerar:
- Hora aproximada de início do backup FULL: 2016-01-02 22:59:06.090
- Hora aproximada de término do backup FULL: 2016-01-02 22:59:06.167
Temos três operações de checkpoint (em vermelho), que são: LOP_BEGIN_CKPT, LOP_XACT_CKPT e LOP_END_CKPT. Resumindo:
- LOP_BEGIN_CKPT é o início da operação de checkpoint e nesta linha, temos a data de início do checkpoint através da coluna “Checkpoint_Begin”, que ocorre exatamente dentro do intervalo de hora da execução do backup FULL, executado anteriormente.
- LOP_XACT_CKPT é gerado para transações ativas (uncommitted) e informa a quantidade de transações ativas no momento em que o checkpoint inicia.
- LOP_END_CKPT é o fim da operação de checkpoint e nesta linha, também temos a data que é logicamente a de término da operação através da coluna “Checkpoint End”, que também está dentro do intervalo de hora da execução do nosso backup FULL.
Temos então o intervalo de execução do checkpoint:
- Hora de início do checkpoint: 2016-01-02 22:59:06.113
- Hora de término do checkpoint: 2016-01-02 22:59:06.113
Deste modo podemos então concluir, como esperado, que o checkpoint é executado em backup FULL.
Vamos então partir para o teste do Backup de Log que é o nosso alvo.
Primeiro, vamos criar uma tabela de teste bem básica e fazer um insert também bem básico, apenas com intuito de gerar operações no transaction log. Vou manter uma transação aberta apenas por que quero.
USE [BkpLog_vs_Checkpoint]
GO
CREATE TABLE [Test_Table] (ID_Column INT IDENTITY(1,1), Column_1 VARCHAR(100))
GO
BEGIN TRANSACTION
INSERT INTO [Test_Table] (Column_1) VALUES ('BkpLog_vs_Checkpoint')
Após a criação da tabela e a execução insert, vamos utilizar a função fn_dblog para procurar dentro do transaction log por operações de checkpoint, em nosso script abaixo, por operações que terminam com “_CKPT”.
Vemos na imagem abaixo, que temos agora 117 operações dentro do arquivo de log e apenas o checkpoint realizado durante o nosso backup FULL.
Até aqui, tudo normal.
Com a transação ainda aberta, vamos realizar então o alvo de nosso teste que é o backup de log em outra sessão, registrando também a data para podemos comparar com o possível registro a ser criado para a operação de checkpoint.
Finalizado o backup de log, vamos então procurar pela nova operação de checkpoint dentro do arquivo de log, considerando o intervalo de data e hora de execução do backup de log anterior.
Percebam que o volume de operações no transaction log aumentou, porém, continuamos apenas com os registros das operações de checkpoint do momento da execução do Backup FULL.
Podemos então concluir que o checkpoint não foi executado no backup de Log.
Mas vamos continuar….
Vamos então usar a função fn_dblog para ler o arquivo de backup de log que foi gerado.
Vemos na imagem acima que o arquivo de backup de log contém exatamente os registros de checkpoint durante a execução do Backup FULL, o que era absolutamente esperado.
Já que estamos com a transação do insert ainda em aberto, vamos fazer o commit para movimentar um pouco mais o arquivo de log e fazer novamente um backup de log para verificar se algo mudaria. (Claro que acredito que não vai mudar. rs)
Novo backup de log feito após o commit e agora é verificar se temos algum novo registro de checkpoint no arquivo de log.
Desta vez, vou acrescentar na query a função GETDATE para demonstrar que a query foi executada após a execução este último backup de log.
Continuamos apenas com a operação de checkpoint do Backup FULL.
Cai totalmente por terra a questão levantada de que em todo backup de Log é forçado uma operação de checkpoint. Esta afirmação é falsa. Ufa!
Por fim, vamos apenas ler o nosso segundo e último arquivo de backup de log e verificar se existe alguma informação de checkpoint dentro dele.
Como era esperado, nenhuma informação de checkpoint existe dentro deste último arquivo, já que esta informação já existe no primeiro arquivo de backup de log.
Bem pessoal como mensagem final deste post, sugiro que nunca confiem plenamente no que é dito nos eventos em geral.
O palestrante normalmente está bem preparado para a sua própria palestra, mas como vocês bem devem prever, ele não tem como saber tudo sobre tudo.
Muitas vezes surgem perguntas nas palestras, como esta por exemplo, que deixam uma dúvida no ar e ainda o que é pior, perguntas e/ou afirmações que nem dúvidas deixam e passam bem longe de serem verdades.
Tomem nota, principalmente daquilo que lhe parecer estranho e testem.
Documentação e posts nós temos de montão por aí.
Espero que este post seja útil em nossos estudos.
Um grande abraço e Feliz ano novo.
Leandro Ribeiro
