遅延更新リカバリ:NO-UNDO と REDO を使用して信頼性の高いデータ整合性を実現

遅延更新リカバリでは、ディスク上の実際のデータベース変更は、トランザクションがコミットされるまで延期されます。更新は、実行中にログおよびキャッシュ バッファーにのみ記録されます。トランザクションがコミット前に失敗した場合、ディスク上のデータベースは影響を受けないため、元に戻すことはできません。変更がディスクに書き込まれていない、コミットされたトランザクションには REDO のみが必要です。

遅延更新プロトコル

• トランザクションは、コミット ポイントに到達するまでディスク上のデータベースを変更できません。
• すべての REDO ログ エントリは、コミット前にディスクに強制的に書き込まれる必要があります (先行書き込みログ)。
• REDO ログ エントリ（新しい値/AFIM）のみが必要で、UNDO エントリは必要ありません。

回復手順 (RDU_M)

厳密な 2 フェーズ ロックを備えたマルチユーザー システムの場合、回復アルゴリズムは 2 つのリストを維持します。

• コミット リスト 最後のチェックポイント以降にコミットされたトランザクション。
• アクティブ リスト まだアクティブだった (コミットされていない) トランザクション。

REDO は、コミットされたトランザクションの WRITE 操作にログ順に適用されます。アクティブな (コミットされていない) トランザクションは事実上キャンセルされるため、再送信する必要があります。

タイムラインの例

チェックポイント (t1) クラッシュ (t2) T1 (コミット) T2 → REDO T3 → REDO T4 → 無視 (コミットなし) T5 → 無視 (コミットなし)

T1 はチェックポイントの前にコミットされました。やり直しは必要ありません。チェックポイント後にコミットされた T2、T3 はやり直す必要があります。 T4、T5 はコミットされず、無視されました (遅延更新ではディスク上に変更はありません)。

REDO の最適化

アイテム X がコミットされたトランザクションによって複数回更新された場合、やり直す必要があるのは最後の更新だけです。

• 逆の順序でログを調べます。
• すでにやり直した項目のリストを維持します。
• リストにすでにある項目をスキップします (最後の値はすでに復元されています)。
• まだリストにない項目のみをやり直して、追加します。

利点と制限

利点 制限事項 失敗時にロールバックは必要ありません (NO-UNDO) 書き込みロックされたアイテムはコミットまでロックされたままになります カスケード ロールバックはありません (アイテムはコミットまでロックされます) コミットされるまですべての更新にバッファ スペースが必要です 中止されたトランザクションは単純に再送信されます 変更がほとんどない短いトランザクションでのみ実用的です

結論

NO-UNDO/REDO 遅延更新では、ディスクへの書き込みがコミットされるまで延期されるため、リカバリ中に UNDO 操作が必要なくなります。 REDO が必要なのは、最後のチェックポイントの後にコミットされたトランザクションのみです。これによりリカバリが簡素化されますが、同時実行性が制限され、コミットされていないすべての変更を保持するのに十分なバッファ スペースが必要になります。