コミット処理を完了するタイミング｜情報処理安全確保支援士 平成30年 春期午前Ⅱ試験 問21
出典：平成30年春期 午前Ⅱ 問21
分野：データベース ／ トランザクション処理
DBMSがトランザクションのコミット処理を完了するタイミングはどれか。
- ア：アプリケーションの更新命令完了時点
- イ：チェックポイント処理完了時点
- ウ：ログバッファへのコミット情報書込み完了時点
- エ：ログファイルへのコミット情報書込み完了時点
TSUNAGARU-ADVICE
まず押さえたいこと
DBMSでは、トランザクションのコミット情報がログファイルなどの永続記憶に書き込まれた時点で、コミット処理が完了したと扱います。障害が発生しても、ログファイルにコミット記録が残っていれば復旧できるため、ポイントはログバッファではなくログファイルへの書込みです。
迷ったときの判断軸
アプリケーションの更新命令が終わっても、DBMSとして確実に更新を永続化できるとは限りません。チェックポイントは復旧処理を効率化するための区切りであり、個々のトランザクションのコミット完了時点そのものではありません。また、ログバッファは主記憶上の一時的な領域なので、障害時に失われる可能性があります。コミットは、障害後も残る場所に記録されたかで判断しましょう。
科目Bにつなげるために
科目Bでは、障害回復・ロールバック・ロールフォワード・チェックポイント・更新ログの扱いが問われることがあります。DBの信頼性を考えるときは、処理が画面上で完了したかではなく、コミット済み更新をログから復元できる状態かを確認する視点を持ちましょう。
※DB関連試験向け。
COMMITは、トランザクションの更新を「確定する」命令です。ただし、COMMITを実行した瞬間に、更新後のデータがすぐディスクなどの補助記憶装置へ書き込まれるとは限りません。
データベースでは、処理を速くするために、いったん主記憶上でデータを更新し、あとでまとめて補助記憶装置へ書き込むことがあります。
ここで問題になるのは、主記憶が揮発性メモリである点です。主記憶上のデータは、障害や電源断が起きると失われる可能性があります。
そのため、COMMIT後、まだ補助記憶装置へ更新データを書き込む前に障害が発生すると、確定したはずの更新内容が失われるおそれがあります。これでは、トランザクションの永続性を満たせません。
そこで使われるのがWALプロトコルです。WALは、実データを書き込む前に、先にログを安定した記憶装置へ書き込む考え方です。
ログが安定記憶装置に書き込まれていれば、たとえ実データがまだ補助記憶装置に反映されていなくても、障害復旧時にログを使って更新内容を再現できます。
そのため、トランザクションは、単にCOMMIT文が実行された時点ではなく、更新後ログが安定記憶装置に書き込まれた時点でコミット完了とみなされます。
つまり、COMMITの本質は「実データがすぐディスクに書かれること」ではなく、「障害が起きても更新内容を復元できる状態になること」です。
ログバッファは主記憶上にあるため、障害が発生すると内容が失われる可能性があります。そのため、コミット情報が補助記憶装置上のログファイルへ書き込まれた時点で、コミット処理が完了したとみなされます。
したがって、エが適切です。
❌他選択肢が誤りの理由ア：アプリケーションの更新命令完了時点
⇒更新命令が完了しても、まだトランザクション全体が確定したとは限りません。コミットが実行される前であれば、ロールバックによって更新内容を取り消せます。
イ：チェックポイント処理完了時点
⇒チェックポイントは、障害発生時の回復処理を効率化するために、データベースやログの状態を記録する処理です。個々のトランザクションのコミット完了時点を示すものではありません。
ウ：ログバッファへのコミット情報書込み完了時点
⇒ログバッファは主記憶上にあり、電源断などによって内容が失われる可能性があります。そのため、ログバッファへの書込みだけではコミット完了とはみなされません。