Analisando seu log file – Parte 03

Continuando a série sobre o transaction log (t-log), gostaria de falar um pouco mais sobre a estrutura interna dele.

Vamos então analisar o fluxo “normal” que ocorre no arquivo de log quando realizamos uma transação para alterar algum dado (não vou entrar nos detalhes de locks e latches, apenas na parte que se relaciona ao funcionamento do t-log):

  1. Transação é iniciada
  2. Páginas de dados são alteradas no buffer pool
  3. Operações são registradas no log buffer
  4. COMMIT é feito / log buffer é descarregado no t-log

Como eu ainda não citei o log buffer em meus artigos, vou escrever uma rápida explicação sobre o mesmo agora, para depois entrar em mais detalhes.

log buffer é uma pequena área contínua de memória, com tamanho de 60kb, que serve para armazenar os logs de transação e existe para cada banco de dados. A ideia por trás do log buffer é agrupar os logs de transação para então executar as escritas para o arquivo de log de uma vez, otimizando o processo de IO.

Bem, no processo que citei (passos 1 a 4) o COMMIT “força” a descarga do log buffer devido a técnica de WAL utilizada pelo SQL Server, que garante que as operações sejam sempre escritas no t-log ANTES da alteração do arquivo de dados.

Esse seria o processo “normal”, pois algumas situações podem fazer com que o log buffer seja descarregado antes mesmo do COMMIT, sendo elas:

  • log buffer fica completamente cheio
  • Checkpoint

No caso do log buffer ficar completamente cheio, como isso impediria as transações de executarem novas operações, o SQL Server se vê obrigado a descarregar o log buffer para o t-log, mesmo que ainda não tenha ocorrido um COMMIT.

Já no caso do checkpoint, como esse processo descarrega as dirty pages do buffer pool para o disco, novamente o WAL “obriga” que os registros no t-log sejam escritos previamente.

Em todos os casos quem descarrega o log buffer no t-log é o processo de “Log Writer“, que é único em cada instância.

Durante a descarga dos dados devido a um COMMIT, o Log Writer bloqueia a sessão do usuário até que sua operação de IO seja concluída. Durante esse bloqueio ele ainda pode trabalhar atendendo ao log buffers dos outros bancos de dados.

Nas outras situações (ex: log buffer cheio) o Log Writer trabalha de forma assíncrona com a sessão do usuário.

Voltando agora a explicação sobre o log buffer, preciso lembrar que, como expliquei em um post anterior, o t-log é composto de sub-partes chamadas de Virtual Log Files (VLFs).

Só que internamente os VLFs ainda são subdivididos em estruturas menores, os log blocks, cujo tamanho varia de 512 bytes até 60kb***, com incrementos de 512 bytes.

***Aqui há uma certa “confusão”, algumas fontes citam o tamanho máximo como 64kb (inclusive uma das fontes que cito ao final do artigo!), mas as que acredito serem mais confiáveis citam 60kb, até pelo fato do log buffer ter 60kb!

Na verdade o tamanho dos log blocks é definido por um algoritmo interno, mas seu tamanho está diretamente relacionado (múltiplo) ao sector size do disco, cujo tamanho mais comum é 512 bytes e também ao perfil dos registros de log que estão sendo gerados.

Em um log block podem ser escritas operações de diversas transações, mas vale lembrar que se QUALQUER uma delas realizar um COMMIT, todo o log buffer será descarregado.

Outro ponto importante é que o log block é a unidade de IO da descarga (flush) do log buffer, ou seja, cada log block gera um IO para o disco, que será sempre um múltiplo de 512 bytes (ou seja, se o log block tiver 5100 bytes, serão adicionados vários zeros em seu final, até completar 5120 bytes).

Não temos como controlar o tamanho do log block, mas podemos controlar o tamanho das nossas transações que é o fator mais importante! Nunca é demais lembrar, sempre devemos manter nossas transações com o menor tamanho/duração possível!

Caso queira, você pode inclusive analisar o que uma determinada transação escreve no t-log. Para isso, basta executar o comando abaixo

SELECT *  FROM fn_dblog (NULL, NULL)

e então analisar todos os registros para o “Transaction ID” que você deseja analisar. Outro ponto interessante é que você pode ver o tamanho dos registros no log, vendo os valores da coluna “Log Record Length”, que demonstra os valores em bytes.

Essas operações que são exibidas são exatamente o conteúdo dos log blocks.

Uma última informação, relativa a verificação de integridade dos log blocks. Antes do SQL Server escrever o log block em disco ele calcula um CHECKSUM para esse log block e grava o resultado no header do mesmo. Assim, quando o t-log é lido, esse CHECKSUM é novamente calculado e comparado ao valor armazenado no header, para verificar se não houve alguma corrupção no mesmo. O processo é bastante similar ao que ocorre com as data pages.

Essa verificação de CHECKSUM dos log blocks é ativada automaticamente ao se ativar o CHECKSUM para o banco de dados com o comando: ALTER DATABASE BANCO SET PAGE_VERIFY CHECKSUM. O modo TORN_PAGE_DETECTION não afeta e não é aplicado aos log blocks.

 

*Não deixe de ler a seção “What is the role of the sector size for the transaction log?” na primeira fonte/referência que cito abaixo, material bem interessante!

 

Fontes/Referências:

Esse post foi publicado em Artigos, Virtual PASS BR. Bookmark o link permanente.

Uma resposta para Analisando seu log file – Parte 03

  1. Pingback: Transações no SQL Server (Commit e RollBack Transaction) « Alex Souza

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s