O esquema de recuperação com atualização adiada (NO-UNDO) segue uma técnica no-steal. Porém, os sistemas de banco de dados típicos empregam uma estratégia steal/no-force. A vantagem do steal é que ele evita a necessidade de um espaço 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 assim o custo de Entrada/Saída para gravar essa página várias vezes em disco, e possivelmente ter de lê-la novamente do disco. Isso pode oferecer uma economia substancial no número de operações de E/S de disco quando uma página específica é bastante atualizada por várias transações.
Para permitir a recuperação quando a atualização no local é usada, as entradas apropriadas exigidas precisam ser permanentemente gravadas no log em disco antes que as mudanças sejam aplicadas ao banco de dados. Por exemplo, considere o seguinte protocolo de logging write-ahead (WAL) para um algoritmo de recuperação que exige tanto UNDO quanto REDO:
- A imagem antes (BFIM) de um item não pode ser modificada por sua imagem depois (AFIM) no banco de dados em disco até que todos os registros de log do tipo UNDO para a transação em atualização, até este ponto, tenham sido gravados à força no disco.
- A operação de confirmação de uma transação não pode ser concluída até que todos os registros de log tipo REDO e tipo UNDO para essa transação tenham sido gravados à força no disco.
|
Para facilitar o processo de recuperação, o subsistema de recuperação do SGBD pode manter uma série de listas relacionadas às transações que estão sendo processadas no sistema. Estas incluem uma lista para transações ativas que começaram, mas ainda não foram confirmadas, e também podem incluir listas de todas as transações confirmadas e abortadas desde o último checkpoint (ver a próxima seção). Manter essas listas torna o processo de recuperação mais eficiente.
|