Artigo SQL Magazine 21 - Backups com SQL Server 2000 Parte I: Modelos de Recovery

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (0)  (0)

Artigo da Revista SQL Magazine - Edição 21.

 

capaSQL21.JPG

 

Clique aqui para ler todos os artigos desta edição

 

Backups com SQL Server 2000 Parte I: Modelos de Recovery

    

Não se pode falar em backup sem discutir antes os modelos de recovery. Por isso a matéria  “Backups com SQL Server 2000” foi dividida em duas partes. Na primeira parte exploraremos a arquitetura do log de transações e modelos para recuperação de dados. Já na segunda, o foco será os tipos de backup existentes nessa plataforma. Boa leitura!

Recovery? O que é isso?

Recovery quer dizer recuperação, restauração. O termo recovery é utilizado para especificar o retorno à operação normal depois de uma falha (o servidor “caiu”, ocorreu crash na unidade de disco onde está localizado o database,  etc). Dependendo da gravidade da situação, o processo de recovery pode envolver a restauração de um backup.

Os modelos de recovery ou recovery models informam para o engine do SQL Server 2000 como tratar o log de transações com relação ao processo de log de alguns comandos, limpeza das transações já confirmadas no database e mecanismos de backup.

O modelo de recovery estipula também o grau de risco relativo à perda de dados inerente a um processo de restauração de database. Para que o risco seja pequeno, todas as transações registradas no log devem ser “backupeadas” e logadas ao nível máximo de detalhamento.

A recuperação de um database - assim como os modelos de recovery - estão intimamente relacionados com o funcionamento do log de transações, nosso próximo tópico.

Para que serve e como funciona o log de transações

Vamos exemplificar o funcionamento do log através de um exemplo clássico: você foi até um caixa-eletrônico para transferir R$ 500,00 de sua conta-corrente para a poupança. A operação foi concluída, mas você percebe no extrato emitido após a operação que o dinheiro saiu da conta-corrente, mas não entrou em sua conta-poupança. Para impedir esse tipo de situação, os SGBD´s trabalham com o que chamamos de log de transações. No exemplo anterior, uma transação seria aberta antes da retirada de R$ 500,00 da conta-corrente, sendo fechada somente após a contrapartida na conta-poupança. Se acontecer qualquer “desvio” entre a saída da conta-corrente e a entrada na poupança, a transação não é concluída e os R$ 500,00  retornam para a conta-corrente do usuário.

A função do log data file é dar suporte às transações: quando um comando T-SQL é executado para atualizar um dado, a modificação não é propagada nesse momento para o arquivo de dados. A alteração acontece primeiramente em memória e no log de transações; em um segundo momento, todo o lote de páginas alteradas em memória – conhecidas por dirty pages – serão transferidas para o disco em um processo conhecido por checkpoint. Na página em memória fica registrada a posição após a alteração. No log de transações, além da posição final (após a alteração), ficarão também registrados controles que permitem reverter a modificação: em inserções e deleções, toda a linha incluída/deletada ficará registrada. Nas atualizações ficarão registradas as posições da linha antes e após a alteração. Dessa forma, se um servidor que se encontra em produção “cair”,  o processo de recovery automático – detalhado no tópico O Processo de Recovery – se encarregará da atualização do arquivo de dados através da leitura das transações pendentes no log.

O log de transações até a versão 6.5 era representado por uma tabela de sistema chamada SYSLOGS, criada na própria área de dados do database nos limites do arquivo .MDF. A partir da versão 7.0, o log de transações passou a ser gravado em outro arquivo, separando-se definitivamente da área de dados. Pode-se pensar no arquivo de log como sendo uma extensa fila de transações, identificadas por um código seqüencial conhecido por LSN, acrônimo de Log Sequence Number (ler Nota 1).

 

Nota 1. Arquivo de log

Por questões de segurança, é interessante criar o log de transações (arquivo .LDF) em uma unidade de disco diferente daquela destinada ao arquivo de dados (arquivo .MDF). Utilizar outro disco para o log torna possível a execução do backup do log em caso de crash no disco de dados, fato que se torna inviável quando dados e log são gravados na mesma unidade. “Backupear” o log após um crash torna viável a reconstrução do database sem que sejam registradas perdas históricas – a transação de fato ocorreu, existia em memória e no log de transações mas não havia sido aplicada no arquivo de dados. Se o crash acontecesse nesse momento e o log de transações estivesse no mesmo disco, a transação ficaria perdida no tempo, acarretando perda de integridade na posição a ser restaurada.

O processo de checkpoint

A função do checkpoint é atualizar o arquivo de dados do database a partir das páginas modificadas em memória. Esse movimento é periódico e automático, sendo determinado pelo volume de alterações e não por intervalos regulares de tempo. Quando existe pouca atividade do banco, os checkpoints são mais espaçados. À medida que a atividade do servidor aumenta, os checkpoints são executados em intervalos menores.

A cada execução do checkpoint, o arquivo de log é marcado para sinalizar que as transações até aquele ponto já foram propagadas para o arquivo de dados. No próximo checkpoint, somente as transações à partir dessa marca – cujas páginas alteradas encontram-se em memória -  serão efevidadas. O  checkpoint pode ser executado manualmente por usuários pertencentes aos server roles "

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?