情報処理安全確保支援士 2025年 秋期 午前2 問21

トランザクションのコミット完了のタイミング【午前2 解説】

要点まとめ

• 結論：トランザクションのコミット完了は、コミット情報（コミットログ）がログファイルへ書き込まれ安定記憶へ確実に格納された時点です。
• 根拠：耐久性（Durability）の保証のため、コミット応答はログレコードがメモリ上ではなくディスクなどの永続媒体にフラッシュされたことを前提とします。
• 差がつくポイント：ログバッファへの書込みは一時的で、チェックポイントは後処理。実務では fsync 等による同期書込みや group commit の有無が性能と保証を左右します。

正解の理由

よくある誤解（2〜3 行）

• 「アプリの更新命令完了＝コミット完了」とする誤解：更新命令は単に処理の完了を意味し、永続化（ディスクへのフラッシュ）を伴わないことが多いです。
• 「チェックポイント完了でコミット保証」とする誤解：チェックポイントは復旧負荷を下げる処理であり、個々のコミットの耐久性保証とは別です。

解法ステップ

1. ACID のうち D（Durability：永続性）がコミット応答で何を要求するかを確認する。
2. メモリ上のログバッファとディスク上のログファイルの違い（揮発性か否か）を意識する。
3. チェックポイント処理の目的（復旧効率化や古いログの破棄）を理解する。
4. 「コミット完了」とは、障害後もトランザクション効果が残ることを保証できる状態であると定義する。
5. 以上から、ログファイル（永続媒体）への書込み完了が必要であると結論づける。

選択肢別の誤答解説

• ア: アプリケーションプログラムによるデータ更新命令完了時点
  誤り。アプリが更新処理を終えても、その変更やコミット情報がメモリ上だけで完結している場合、電源断で消失する恐れがあります。耐久性が保証されません。
• イ: チェックポイント処理完了時点
  誤り。チェックポイントはデータページを書き出して復旧を容易にする後処理であり、コミット完了の同期条件ではありません。コミットはチェックポイントの完了を待たずに完了しうるため不適切です。
• ウ: ログバッファへのコミット情報書込み完了時点
  誤り。ログバッファは主記憶上の一時領域で、ここへの書込みだけでは障害耐性がなく、Durability を満たしません。ディスクへのフラッシュ（同期書込み）が必要です。
• エ: ログファイルへのコミット情報書込み完了時点
  正解。コミットログが永続記憶へ確実に書き込まれた段階で、トランザクションの耐久性が保証され、コミット完了と見なされます。

補足コラム（関連知識など）

• Write-Ahead Logging（WAL）原則：データページを書き換える前に、その変更を表すログを先に永続化することで一貫性と耐久性を確保します。多くのDBMS（InnoDB、PostgreSQL 等）はこの方式を採用しています。
• ARIES アルゴリズムでは、コミット時にコミットログのフラッシュを強制し、その後にデータページの遅延書込みを行う設計が一般的です。
• 実装上の注意点：fsync や fdatasync による同期書込みはコストが高く、性能改善のために group commit（複数トランザクションのコミットログをまとめてフラッシュ）や遅延 Durability オプションが使われます。ただし遅延設定は耐久性要件に影響するため運用ポリシーに注意が必要です。

FAQ