A recuperação NO-UNDO/REDO é realizada refazendo (REDO) a última atualização da transação com base no log. Nesse caso, sempre que um item for refeito, ele é acrescentado a uma lista de itens refeitos. Antes que o REDO seja aplicado a um item, a lista é verificada; se o item aparecer na lista, ele não é refeito novamente, pois seu último valor já foi recuperado.

Se uma transação for abortada por algum motivo (digamos, pelo método de detecção de deadlock), ela é simplesmente submetida novamente, pois não alterou o banco de dados no disco.

Uma desvantagem do método descrito aqui é que ele limita a execução concorrente das transações, porque todos os itens bloqueados para a gravação permanecem bloqueados até que a transação atinja seu ponto de confirmação. Além disso, pode ser exigido um espaço de buffer excessivo para manter todos os itens atualizados até que as transações sejam confirmadas.

O principal benefício do método é que as operações da transação nunca precisam ser desfeitas, por dois motivos:

  1. Uma transação não registra quaisquer mudanças no banco de dados em disco até que atinja seu ponto de confirmação — ou seja, até que complete sua execução com sucesso. Portanto, uma transação nunca é revertida por falha durante a execução da transação.
  2. Uma transação nunca lerá o valor de um item que é gravado por uma transação não confirmada, visto que os itens permanecem bloqueados até que uma transação atinja seu ponto de confirmação. Assim, não haverá rollback em cascata.

A figura anterior mostra um exemplo de recuperação para um sistema multiusuário que utiliza o método de recuperação e controle de concorrência que descrevemos.

Copyright © 2016 AIEC.