Write-Ahead Logging (WAL)

Hoje nos bancos de dados relacionais todas as ações que realizamos são tratadas através de transações. A definição de transação, segundo o BOL é de uma sequência de operações realizadas numa única unidade lógica de trabalho e deve exibir quatro propriedades fundamentais que são: Atomicidade, Consistência, Isolamento e Durabilidade. Estas propriedades são conhecidas como propriedades ACID.

Atomicidade

A transação tem de ser atômica, ou seja, ou tudo é executado ou tudo é desfeito. Numa transação, não há como somente parte dela ser executada com sucesso.

Consistência

Uma vez que a transação foi completada, os dados tem de ficar num estado consistente. Por exemplo, estruturas de índices serão atualizadas e devem estar íntegras. Uma transação não pode permitir a inserção de um registro com sucesso deixando a estrutura de índices desatualizada.

Isolamento

Alterações realizadas em uma determinada transação devem ser isoladas de alterações realizadas por outras transações.

Durabilidade

Ao ser confirmada, as alterações da transação devem ser permanentes, mesmo em caso de falha do sistema.

Cada banco de dados relacional possui mecanismos para garantir estas características e isto não é diferente do SQL Server. Hoje vou falar um pouco de como funciona o protocolo Write-Ahead Logging.

Antes de falarmos do WAL em si, vale lembrar como o SQL Server realiza alterações nas páginas de dados. Toda alteração é sempre realizada em memória. A página a ser alterada é carregada para a memória (Data Cache ou Buffer Pool) e então é alterada, passando a ser chamada de Dirty Page, ou página suja, pois ainda não foi escrita novamente em disco.

Uma vez que a página foi alterada o SQL Server tem de garantir as propriedades ACID e é aqui que entra o Write-Ahead Logging. A página alterada não é escrita imediatamente em disco. Ao invés disso, ela será escrita no Transaction Log para posteriormente ser persistida novamente em disco. O Buffer Manager do SQL Server garante que uma Dirty Page jamais será escrita em disco antes de ser escrita no Transaction Log através do WAL, dai o nome Write-Ahead, ou numa tradução livre, “escreva à frente”.

Abaixo, uma imagem do BOL que descreve de maneira simples e direta este processo.

WAL

  1. A alteração é submetida para o SQL Server;
  2. A página é localizada e carregada para a memória (caso não esteja carregada ainda);
  3. O WAL se encarrega de escrever a alteração no Transaction Log;
  4. A página já pode ser escrita em disco;

A etapa 4 pode ser realizadas por 3 processos diferentes:

    • Lazy Writer
    • Eager Writer
    • Checkpoint

Cada um destes processos possui uma característica e finalidade diferentes mas a explicação de cada um deles fica para um próximo post… =)

Por enquanto, quem quiser saber um pouco mais sobre Checkpoint, recomendo a leitura deste post do Fabricio Catae.

 

Referências:

SQL Server 2000 I/O Basics

http://technet.microsoft.com/en-us/library/cc966500

SQL Server 7.0, SQL Server 2000, and SQL Server 2005 logging and data storage algorithms extend data reliability

http://support.microsoft.com/default.aspx?scid=kb;en-us;230785

Writing Pages (BOL)

http://msdn.microsoft.com/en-us/library/aa337560%28v=sql.105%29.aspx

Write-Ahead Transaction Log (BOL)

http://msdn.microsoft.com/en-us/library/ms186259%28v=sql.105%29.aspx

 

Bons Estudos!

Erickson Ricci

About these ads

3 Respostas para “Write-Ahead Logging (WAL)

  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