Clique aqui para ler esse artigo em PDF.
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”,"
[...] continue lendo...