Estrutura Interna do arquivo de Log - Parte 1

Parte 1 - Introdução ao Log de Transações e "Recovery"

Neste primeiro post vou escrever sobre a estrutura interna do arquivo de Log (.LDF) além de uma pequena introdução a operação de Recovery.

Um arquivo de Log de Transações no SQL Server 2005 mantém registros das operações de atualização que ocorrem em um Banco de Dados. Cada banco de dados no SQL Server possui um ou mais arquivos de LOG (vou utilizar o termo LOG para fazer referências ao Log de Transações), sendo o mais comum utilizar um único arquivo. O SQL Server utiliza múltiplos arquivos de LOG em serial, um após o outro, por este motivo não existe ganho de performance no uso de arquivos de LOG em discos diferentes. O único motivo para se ter mais de um arquivo de LOG é por necessidades de espaço em disco.

Um componente do SQL Server chamado de "Buffer Manager" garante que a atualização do LOG ocorra antes da atualização do arquivo de dados ("write-ahead logging"). Quando uma conexão executa uma instrução de atualização, o SQL Server altera as páginas em memória e registra a operação no arquivo de LOG no disco, retornando mensagem indicando o sucesso da operação para a conexão. Posteriormente, de modo assíncrono, o arquivo de DADOS é atualizado por dois processos "Lazywriter" e "Checkpoints". Podemos concluir que na maior parte do tempo existe uma diferença nos dados que estão no arquivo de LOG e no arquivo de DADOS! A porção do arquivo de LOG que contém as informações que ainda não foram sincronizadas com o arquivo de DADOS é chamada de Porção Ativa do Log.

Cada registro em um arquivo de LOG recebe um número seqüencial chamado de "Log Sequence Number" (LSN). Ao final de cada "Checkpoint" o SQL Server registrar o valor do LSN que representa o último registro lido (MinLSN - "Minimum Log Sequence Number"). No próximo "Checkpoint" o SQL Server analisa apenas os registros do MinLSN até o fim.

Quando o SQL Server atualiza uma página de dados durante o "Lazywriter" ou o "Checkpoints", o "Header" (cabeçalho) da página é atualizado com o LSN correspondente ao registro no LOG que gerou a atualização. Desta maneira o SQL consegue determinar se um registro no LOG já foi aplicado ou não na página de dados, comparando o LSN do registro do LOG com o LSN do "Header" da página. Na Figura 1 a página está com o LSN 2:200, porém existe um registro no Transaction Log com LSN posterior (2:210) indicando a necessidade de aplicar o UPDATE definido no LOG na Página.

Se o Servidor SQL for desligado (queda de energia, por exemplo), os arquivos de DADOS e LOG estarão em diferentes estados. Quando o Servidor for reinicializado o SQL Server executa um processo chamado de "Restart Recovery" em cada banco de dados, verificando a existência de uma porção ativa do LOG e sincronizando os dados com o arquivo de DADOS.

No próximo post vou escrever com maior detalhe o processo de “Restart Recovery”, até lá!