Log de Transação – Parte 3

Olá Pessoal!!

Vamos dar continuidade a série de post`s sobre LOG de Transação. Antes de tudo perdoem-me a demora, mas esse mês aconteceram diversas coisas que me impossibilitaram de sentar em frente ao PC e escrever para o blog. Bem…Let`s GO!!

No último post falei um pouco sobre checkpoint, que as alterações ocorrem no buffer etc e tal. Hoje vamos falar de um processo chamado de restart recovery(recuperação de reinicialização).

Quando o SQL Server é iniciado, cada banco de dados passa por um processo chamado de RESTART RECOVERY. O restart recovery ocorre em duas fases. Essas fases são chamadas de UNDO e REDO (no post anterior tem um comentário do mestre Felipe Ferreira falando sobre isso).

Durante a fase do REDO, todas as transações “commitadas” do LOG de Transações são descarregadas no disco. O REDO usa a mesma lógica do processo de checkpoint. Se o LSN armazenado na page(página) é menor ou igual ao LSN  do log record(resgistro de log)que esta sendo gravado na página, a alteração é gravada. Caso contrário, é pulada, sendo considerada como já existente no disco. Quando a fase do REDO termina, a fase UNDO começa.

A fase do UNDO percorre o LOG de Transação e invalida qualquer transação no log que ainda esteja aberta, garantindo que uma transação uncommitted(não efetivada) não possa ser gravada no disco. Quando a fase do UNDO termina, o banco de dados passa por um processo referenciado como rolling forward.

Quando um banco de dados esta no processo de rolling forward , o SQL Server lê o último LSN gravado no LOG de Transação, incrementa o LSN e grava o novo LSN no cabeçalho de todos os data file(arquivo de dados) garantindo as transações  mais antigas do que o ponto  roll-forward não possam ser gravadas nos data files.

Todo backup criado armazena o LSN mínimo e o máximo do banco de dados o qual corresponde o backup taken.

Como um backup FULL contém a porção do log de transação que foi gerado enquanto o backup está em execução, um backup FULL é consistente com o momento da sua conclusão e armazena apenas o último LSN utilizado dentro do backup. Os backups diferenciais e de log de transação gravam o LSN do banco de dados no início da operação de backup, bem como o LSN, no final da operação de backup.

Como o LSN esta sempre avançando (moving forward), o SQL Server só precisa comparar o LSN atual com o LSN(ou LSNs) gravado para o backup e assim determinar se o backup pode ser aplicado no banco de dados. Se o backup possui o próximo LSN da sequência, então pode ser restaurado. Se o backup não contém o próximo LSN da sequência, um erro é gerado e o processo  de restauração termina sem aplicar quaisquer alteração.

Por hoje é só People!! Qualquer dúvida ou sugestão fiquem a vontade para comentar!!

Anúncios

Deixe um comentário

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