Document

Podemos declarar um protocolo de atualização adiada típico da seguinte forma:

Uma transação não pode mudar o banco de dados no disco até que atinja seu ponto de confirmação.
Uma transação não atinge seu ponto de confirmação até que todas as suas entradas de log tipo REDO sejam registradas no log e o buffer de log seja gravado à força no disco.

Observe que a etapa 2 desse protocolo é uma reafirmação do protocolo de logging write-ahead. Como o banco de dados nunca é atualizado em disco antes de a transação ser confirmada, nunca há necessidade de desfazer (UNDO) quaisquer operações. REDO é necessário caso o sistema falhe depois que a transação for confirmada, mas antes que todas as mudanças sejam gravadas no banco de dados em disco. Nesse caso, as operações da transação são refeitas das entradas de log durante a recuperação.

Para sistemas multiusuários com controle de concorrência, os processos de controle de concorrência e recuperação são inter-relacionados. Considere um sistema em que o controle de concorrência usa o bloqueio estrito em duas fases, de modo que os bloqueios nos itens permanecem em vigor até que a transação atinja seu ponto de confirmação. Depois disso, os bloqueios podem ser liberados. Isso garante schedules estritos e serializáveis (processamento sequencial de transações).