Interactive
WAL（先行書き込みログ）可視化
データページを書き戻す前に、その変更をログへ先に書く——これがWALの規律です。 3つのページ（A/B/C）に対して書き込み・コミット・チェックポイントを実際に行い、メモリのページはすぐ変わるがディスクは変わらないことを確かめたら、 あえてクラッシュを発生させてみてください。メモリの内容は失われますが、ログとディスクは生き残ります。 続けて実行するリカバリでは、解析→redo→undoの3フェーズが ログだけからディスクを正しい状態に戻す様子をステップごとに確認できます。
ページ A
メモリ
0
ディスク
0
ページ B
メモリ
0
ディスク
0
ページ C
メモリ
0
ディスク
0
=
ログ（先行書き込み・追記専用、チェックポイントなし）
（まだログはありません）
ここが分かる
- 書き込みはメモリ上のページとログにしか反映されない——ディスクのページはチェックポイントするまで古いまま（dirtyと表示される）。これがNo-Force（コミット時にページ書き戻しを強制しない）の実際の姿。
- コミットはコミットログレコードを1件追記するだけ。データページは一切触らないのに、この瞬間から永続性が確定する——ランダムI/Oではなくシーケンシャルなログだけで済むWALの本質的な利得。
- クラッシュで失われるのはメモリだけ。ログとディスクのページは生き残るからこそ、リカバリが決定的に成立する。
- redoはコミット済みかどうかに関わらずログの変更をすべて再適用し（repeating history）、undoはクラッシュ時に未コミットだったトランザクションだけを新しい方から逆順に取り消す。redoが先、undoが後という順番も含めてARIESの骨格そのもの。
- チェックポイントを挟んでからクラッシュさせると、リカバリがチェックポイント以降のログだけで済むことも確認できる——これがログ再生を無限に伸ばさないための仕組み。