遅延更新リカバリとは?NO-UNDO/REDOで実現する信頼性の高いデータ整合性

遅延更新リカバリ(Deferred Update Recovery)では、トランザクションがコミットされるまで、ディスク上のデータベースへの実際の変更を延期します。実行中の更新はログとキャッシュバッファにのみ記録されます。そのため、コミット前にトランザクションが失敗しても、ディスク上のデータベースは一切影響を受けません。これが「NO-UNDO」の由来です。リカバリで必要なのは、変更がまだディスクに書き込まれていないコミット済みトランザクションに対するREDO操作だけです。

遅延更新プロトコルの基本ルール

• トランザクションはコミットポイントに達するまで、ディスク上のデータベースを変更できません。
• すべてのREDOログエントリは、コミット前に強制的にディスクへ書き込む必要があります(ライトアヘッドロギング/WAL)。
• 必要なのはREDOログエントリ(新しい値/AFIM)のみで、UNDOエントリは一切不要です。

リカバリ手順(RDU_Mアルゴリズム)

厳密な2相ロックを採用するマルチユーザーシステム向けのリカバリアルゴリズムでは、次の2つのリストを管理します。

• コミットリスト: 最後のチェックポイント以降にコミットが完了したトランザクションの一覧。
• アクティブリスト: クラッシュ時点でまだアクティブ(未コミット)だったトランザクションの一覧。

REDOは、コミット済みトランザクションのWRITE操作に対して、ログの記録順序に従って適用されます。一方、アクティブ(未コミット)のトランザクションは実質的に取り消されたものとして扱われ、再実行(再送信)が必要です。

タイムラインの例

T1はチェックポイント前にコミット済みのため、REDOは不要です。T2とT3はチェックポイント後にコミットしたため、REDOの対象となります。T4とT5は最後までコミットされなかったため無視されます。遅延更新方式では未コミットの変更がディスクに反映されていないため、取り消し作業自体が発生しない点が特徴です。

REDO処理の最適化

同じ項目Xがコミット済みトランザクションによって複数回更新されていた場合、REDOが必要なのは最後の更新だけです。この最適化は以下の手順で実現できます。

• ログを逆順(新しい順)に走査します。
• すでにREDO済みの項目のリストを管理します。
• リストに既に存在する項目はスキップします(最新値はすでに復元済みのため)。
• リストに存在しない項目のみREDOを実行し、処理後にリストへ追加します。

メリットと制限

まとめ

NO-UNDO/REDO方式の遅延更新リカバリは、ディスクへの書き込みをコミットまで延期することで、障害復旧時のUNDO操作を完全に排除します。REDOが必要なのは、最後のチェックポイント以降にコミットされたトランザクションのみです。この仕組みによりリカバリ処理は大幅に簡素化されますが、その反面、同時実行性が制限され、未コミットの変更をすべて保持できる十分なバッファ領域が求められるというトレードオフがあります。