|
Um sistema de computador, como qualquer outro dispositivo elétrico/mecânico, está sujeito à falhas. Existem várias causas de tais falhas, incluindo quebra de disco, queda de tensão, erros de software, dentre outras. Em cada um desses casos, informações que se referem ao sistema de banco de dados se perdem. Uma parte essencial do sistema de banco de dados é um esquema de recuperação responsável pela detecção de falhas e pela restauração do banco de dados para um estado consistente que existia antes da ocorrência da falha.
Frequentemente, diversas operações do banco de dados formam uma única unidade lógica de trabalho. Ex. Transferência de fundos de uma conta para outra. Neste caso, a transferência de fundos ou deve ocorrer por inteiro ou não deve ocorrer. Este requerimento de tudo ou nada denomina-se atomicidade.
Uma transação é uma coleção de operações que executa uma função lógica única numa aplicação de banco de dados. Cada transação é uma unidade atômica.
7.1. Classificação de falhas
Existem vários tipos de falhas que podem ocorrer em um sistema, cada uma das quais necessitando ser tratada de uma maneira diferente. Um esquema de recuperação precisa ser chamado como resultado dessas falhas. A seguir, vamos tratar quatro desses tipos de falhas.
v Erros lógicos. A transação não pode mais continuar com sua execução normal devido a alguma condição interna, como uma má entrada, dado não encontrado, overflow, etc...
v Erros do sistema. O sistema entrou em um estado não desejável (por exemplo, paralização completa). E, como resultado, a transação não pode continuar sua execução normal. A transação, no entanto pode ser reexecutada mais tarde. (ex. Deadlock)
v Queda do sistema. As disfunções do hardware causam a perda de conteúdo do armazenamento volátil. O conteúdo do armazenamento não-volátil permanece intacto.
v Falha no disco. Um bloco do disco perde seu conteúdo como resultado de uma falha durante a transferência de dados ou de quebra da cabeça.
7.2. Correção e atomicidade
Requerimentos de uma transação: v Correção. Cada transação precisa ser um programa que preserve a consistência do banco de dados. v Atomicidade. Todas as operações associadas a uma transação precisam ser executadas por completo, ou tudo ou nada.
Assegurar a correção é responsabilidade dos desenvolvedores que projetam e codificam sistemas. Assegurar a atomicidade é tarefa do próprio sistema de banco de dados. Na ausência de falhas, todas as transações são completadas com sucesso. Entretanto, quando ela não terminar sua execução com sucesso, é determinada abortada. Uma transação abortada não deve ter efeito no estado do banco de dados. Assim, o banco de dados deve ser restaurado ao estado que se encontrava logo antes de, a transação em questão, ter se reiniciado.
Uma transação que complete com sucesso sua execução é chamada de comprometida. Uma transação comprometida transforma o banco de dados em um novo estado consistente. O efeito de uma transação executada não pode ser desfeito abortando a transação. Pode ser desfeito apenas gravando uma nova transação de compensação. Que ficará sobre a responsabilidade do usuário.
7.3. Recuperação baseada em LOG
A estrutura mais largamente utilizada para registrar modificações no banco de dados é o log. Cada registro log descreve uma única gravação no banco de dados e tem os seguintes campos:
v Nome da transação. O nome único da transação que executou a operação write. v Nome do item de dado gravado. O único nome do item de dado gravado. v Valor antigo. O valor do item de dado anterior à gravação. v Valor novo. Valor que o item de dado terá depois da gravação.
Outros registros especiais log existem para registrar eventos significativos durante o processamento da transação, tais como o início de uma transação ou a execução do aborto da transação. Representamos vários tipos de registros de log como se segue:
v <Ti start>. Indica o início da transação Ti v <Ti, Xj, V1, V2>. A transação Ti executou uma gravação num item de dado Xj. Xj tem o valor V1 antes da gravação e terá o valor V2 depois. v <Ti commit>. A transação Ti foi executada.
Afim de que os registros log sejam úteis para recuperar falhas do disco e do sistema, o log precisa residir num armazenamento estável. Observe também que o log contém um registro completo de todas as atividades do banco de dados. Como resultado, o volume de dados armazenados no log pode se tornar excessivamente grande.
7.3.1. Modificação do banco de dados adiada
A técnica de adiar a modificação do banco de dados assegura a atomicidade da transação gravando todas as modificações do banco de dados no log, mas adiando a execução de todas as operações write de uma transação até que a transação seja parcialmente executada.
Quando uma transação é parcialmente executada, a informação no log associado à transação é usada na execução de gravações proteladas. Se o sistema cair antes que a transação seja executada, ou se a transação for abortada, então, a informação é simplesmente ignorada.
A execução da transação Ti procede da seguinte maneira. Antes que Ti inicie sua execução, um registro <Ti, start> é escrito no log. Uma operação write(X,Xj) por Ti resulta na gravação de um novo registro para o log. Finalmemte, quando Ti é parcialmente executada, um registro <Ti commit> é escrito no log.
Quando Ti é parcialmente executada, os registros associados a ela no log são usados na execução de gravações adiadas. Uma vez que uma falha pode ocorrer enquanto esta atualização estiver ocorrendo, precisamos assegurar-nos de que, antes do início destas atualizações, todos os registros log estejam gravados em meio estável. Uma vez que isto tenha sido feito, a atualização real toma lugar e a transação entra no estado executado.
Observe que apenas o novo valor de item de dado é requerido pela técnica da modificação adiada. Assim, podemos simplificar a estrutura geral do log que vimos na seção anterior omitindo o valor do campo antigo.
Para ilustrar, vamos considerar o sistema bancário simplificado. Digamos que To seja uma transação que transfere R$50,00 da conta A para a conta B. Esta transação pode ser definida como:
T0: read (A,a1) a1 = a1 - 50 write (A,a1) read (B,b1) b1 = b1 + 50 write (B, b1)
Digamos que T1 seja uma transação que saque R$100,00 da conta C. Esta transação pode ser escrita como: T1: read (C,c1) c1 = c1 - 100 write (C,c1)
Considere que A, B e C tenham R$1000,00, R$2000,00 e R$700,00 respectivamente, antes das transações serem executadas. A seguir, são mostrados estados do log e do banco de dados correspondentes a To e T1.
Log Banco de Dados <To starts> <To, A, 950> <To, B, 2050> <To commits> A=950 B=2050 <T1 starts> <T1, C, 600> <T1 commits> C=600
Usando o log, o sistema pode recuperar qualquer falha que resultar na perda de informações em meio volátil. O esquema de recuperação usa o seguinte procedimento:
v redo(Ti) que ajusta o valor de todos os itens de dados atualizados pela transação Ti para os novos valores.
Depois de uma falha ter ocorrido, o subsistema de recuperação consulta o log para determinar que transações precisam ser refeitas. A transação Ti precisa ser refeita se e somente si o log contiver o registro <Ti starts> e o registro <Ti commits>. Assim, se o sistema cair depois que a transação completar sua execução, a informação no log será usada para restaurar o sistema para o estado consistente anterior.
Considere que haja uma queda no sistema após a execução de write(B, b1) no log. Quando o sistema voltar, nenhuma ação de recuperação precisa ser feita.
Agora vamos considerar que a queda aconteça logo após o passo write(C, c1). Quando o sistema voltar, a operação redo (To) será executada uma vez que <To commits> apareça no log do disco.
Assuma que a queda agora ocorra logo após que o registro <T1 commits> for gravado no log. Quando o sistema voltar, as operações redo(To) e redo(T1) serão executadas. (Obs. Todas as transações do log serão refeitas)
Para cada registro <Ti commits> encontrado no log, a operação redo (Ti) será executada. Em outras palavras, as ações de recuperação serão iniciadas desde o início. Uma vez que redo grava valores para o banco de dados independente dos valores correntemente do banco de dados, o resultado de uma segunda tentativa com sucesso para o redo é o mesmo que se redo tivesse sido executado pela primeira vez.
7.3.2. Modificação imediata no banco de dados
A técnica de atualização imediata permite modificações na saída do banco de dados enquanto a transação está ainda no estado ativo. As modificações gravadas por transações ainda ativas são chamadas modificações descomprometidas. Se ocorrer o evento de uma queda ou falha da transação, o campo valor antigo dos registros log descritos nas seções anteriores pode ser usado para restaurar os itens de dados modificados aos valores que tinham antes do início da transação. Isto é feito através da operação undo descrita a seguir.
v Undo(Ti), restaura o valor de todos os itens de dados atualizados pela transação Ti aos valores antigos.
v Redo(Ti), ajusta o valor de todos os itens de dados atualizados pela transação Ti aos novos valores.
Log Banco de Dados <To starts> <To, A, 1000, 950> A=950 <To, B, 2000, 2050> B=2050
<To commits> <T1 starts> <T1, C, 700, 600> C=600 <T1 commits>
Depois a ocorrência de uma falha, o esquema de recuperação consulta o log para saber quais transações precisam ser refeitas e quais precisam ser desfeitas. Esta classificação de transação é feita assim:
v A transação Ti precisa ser desfeita se o log contiver o registro <Ti starts> e não contiver o registro <Ti commits>.
v A transação Ti precisa ser refeita se o log contiver os registros <Ti starts> e <Ti commits>.
7.3.3. Pontos de verificação (checkpoints)
Quando uma falha no sistema ocorre, é necessário consultar o log para determinar quais transações precisam ser refeitas ou desfeitas. Em princípio, o log inteiro precisa ser vasculhado afim de determinar isto. Existem duas dificuldades principais nesta abordagem:
v O processo de vasculhamento consome tempo;
v A maioria das transações que, de acordo com nosso algorítmo, precisam ser refeitas já tem escritas suas atualizações no banco de dados. Embora refazê-la não cause nenhum mal, isto todavia atrasará a recuperação.
Afim de ganhar produtividade, introduzimos um novo conceito, o de checkpoint. O sistema de banco de dados executa periodicamente o checkpoint, que requer a seguinte sequência de ações:
1) Emissão de todos os registros log correntes residentes na memória para o meio estável.
2) Emissão de todos os blocos buffer modificados para o disco.
3) Emissão do registro log <checkpoint> para o meio estável.
Assim, quando houver algum erro, no momento da recuperação, não há necessidade de executar a operação redo para aquelas transações que se encontram antes do registro <checkpoint>.
7.4. Falhas com perda de memória não-volátil
Embora as falhas nas quais o conteúdo do meio estável sejam raras, precisamos estar preparados para lidar com este tipo de falhas.
O esquema básico é fazer um backup de todo o conteúdo do banco de dados, periodicamente. Se uma falha ocorrer resultando na perda dos blocos físicos do banco de dados, a carga mais recente é usada na restauração do banco de dados para um estado anterior consistente. Uma vez que isto tenha acontecido, o log pode ser usado para trazer o sistema para o estado consistente mais recente. |