A Recuperação de Banco de Dados

Recuperação de Banco de Dados

Técnicas de atualização adiada (NO-UNDO/REDO) não atualizam fisicamente o disco até que uma transação atinja seu ponto de confirmação; as atualizações então são gravadas no BD. Antes de atingir a confirmação, todas as atualizações de transação são registradas no cache. Antes da confirmação, as atualizações são registradas no log e depois da confirmação, as atualizações são gravadas no disco. Caso uma transação falhe antes de atingir seu ponto de confirmação, ela não alterará o BD, portanto o Undo não será necessário. Porém, pode ser necessário o Redo das operações de uma transação confirmada do log, porque seus efeitos não foram registrados em disco.

Nas técnicas de atualização imediata, o BD pode ser atualizado por algumas operações de uma transação antes que ela atinja seu ponto de confirmação. Essas operações também devem ser registradas no log forçadamente antes de serem aplicadas no disco, tornando possível a recuperação. Se uma transação falhar após registrar algumas alterações no disco antes de atingir seu ponto de confirmação, suas operações no BD devem ser desfeitas (rollback). No caso geral, Undo e Redo podem ser necessários durante a recuperação e a técnica é conhecida como UNDO/REDO. Uma variação do algoritmo onde todas as atualizações precisam ser registradas no disco antes que uma transação seja confirmada só requer Undo, então é conhecida como UNDO/NO-REDO.

Duas estratégias principais podem ser empregadas ao liberar um buffer de volta ao disco. A primeira estratégia, conhecida como atualização no local, grava o buffer no mesmo local original do disco, sobrescrevendo o valor antigo de qualquer dado alterado no disco. A segunda estratégia, conhecida como sombreamento, grava um buffer atualizado num local do disco diferente (mantendo várias versões em disco). O valor antigo de um dado antes de atualizar é chamado de BFIM (before image) e o novo valor após atualizar é chamado AFIM (after image).

Quando a atualização no local é usada, é necessário usar um log para recuperação. O mecanismo de recuperação deve garantir que o BFIM seja registrado na entrada do log apropriada e que ela seja liberada no disco antes que o BFIM seja substituído pelo AFIM no disco. O processo é conhecido como Write-Ahead Logging (WAL)¸ sendo necessário para desfazer uma operação caso seja necessário durante a recuperação. Uma entrada de log do tipo REDO inclui o AFIM do item gravado pela operação visto que isso é necessário para refazer uma operação do log (definindo seu valor no disco para o seu AFIM). Entradas de log do tipo UNDO incluem o BFIM do item visto que é necessário para desfazer uma operação do log (definindo seu valor no disco para o seu BFIM). No UNDO/REDO, os dois tipos de entrada são combinados.

Os termos steal/no-steal e force/no-force especificam as regras que decidem quando uma página do BD pode ser gravada no cache:

1. Se um buffer do cache atualizado por uma transação não puder ser escrito no disco antes que a transação seja confirmada, o método de recuperação será chamado de abordagem no-steal; por outro lado, se o protocolo permite gravar um buffer atualizado antes da confirmação, será chamado de steal. A regra no-steal significa que UNDO nunca será necessário durante a recuperação, já que uma transação confirmada não terá nenhuma de suas atualizações em disco antes de ser confirmada.

2. Se todas as páginas atualizadas por uma transação forem imediatamente gravadas no disco antes da confirmação, isso será chamado de abordagem force. O caso contrário é chamado de no-force. A regra force significa que REDO nunca será necessário durante a recuperação, já que qualquer transação confirmada terá todas suas atualizações no disco antes de ser confirmada.][

A atualização adiada (NO-UNDO) segue a aproximação no-steal. Porém, os BDs tipicamente usam uma estratégia steal/no-force. A vantagem do steal é que evita a necessidade de buffer muito grande para armazenar todas as páginas atualizadas na memória. A vantagem do no-force é que uma página atualizada de uma transação confirmada ainda pode estar no buffer quando outra transação precisar atualizá-la, eliminando o custo para gravar essa página diversas vezes no disco e de possivelmente ter que ler novamente do disco.

Para permitir a recuperação na atualização no local, as entradas necessárias para recuperação devem estar gravadas no log em disco antes das alterações serem aplicadas no BD. Para facilitar o processo de recuperação, o sistema precisa manter algumas listas relacionadas às transações: a lista de transações ativas (iniciaram, mas não foram confirmadas) e a lista de transações confirmadas e abortadas desde o último checkpoint.

Um outro tipo de entrada no log é chamado de checkpoint. Um registro checkpoint é escrito no log periodicamente quando o sistema grava no disco todos os buffers que foram modificados. Como consequência, todas as transações que possuem entradas [commit, T] no log antes de [checkpoint] não precisam ter operações write refeitas no caso de falha, pois todas as atualizações serão registradas em disco no checkpoint. A lista das transações ativas no tempo do checkpoint é incluída no registro de checkpoint, para que elas possam ser facilmente identificadas na recuperação. Criar um checkpoint consiste nos seguintes passos:

1. Suspender execução das transações temporariamente

2. Forçar a gravação de dados do buffer modificados no disco

3. Escrever um registro [checkpoint] no log e gravar o log forçadamente no disco.

4. Continuar a execução das transações

Se uma transação falhar após atualizar o BD antes da sua confirmação, pode ser necessário dar um rollback. Se algum valor tiver sido alterado pela transação e gravado no BD, ele deve ser restaurado para seu BFIM. Os registros UNDO são usados para restaurar os valores antigos que devem ser revertidos. Se uma transação for revertida, qualquer outra transação que leu algum dado escrito pela primeira também deve ser revertida e assim por diante. Esse processo é conhecido como rollback em cascata.

A idéia por trás da atualização adiada é adiar qualquer atualização real no disco até