データベースの障害回復とバックアップ
データベースの障害回復とは、障害によって失われた更新や途中で止まった処理を取り除き、データベースを整合性のある状態に戻す仕組みである。回復では、どの更新を取り消し、どの更新を再び反映するかを判断しなければならないため、トランザクションの処理履歴であるログと、定期的に取得するバックアップが用いられる。障害は、処理が途中で止まるシステム障害と、ディスクなどの記憶媒体が壊れる媒体障害に大別され、回復の手順はそれぞれ異なる。両者を混同すると誤った手順を選んでしまうため、障害の種類を最初に判断することが重要である。
回復の土台となるログとチェックポイント
データベースの更新は、ログに更新前の情報(更新前イメージ)と更新後の情報(更新後イメージ)を記録して行われる。更新前情報は、未完了のトランザクションが行った更新を取り消すときに使い、更新後情報は、確定済みの更新を再び反映するときに使う。 チェックポイントは、ある時点までに更新がデータベースへ反映されたことを記録し、回復時に読むべきログの範囲を絞るための目印である。媒体障害以外の障害で停止した場合は、チェックポイント以前にコミットしたトランザクションについて回復作業が不要になる。 そのため、チェックポイント以降の処理だけが回復の検討対象となり、その範囲をどこで区切るかが回復の効率を左右する。
システム障害からの回復の手順
システム障害では記憶媒体は壊れていないため、回復はログを使って行う。チェックポイント以降にコミットしたトランザクションは、更新後情報を使って再実行する前進復帰(ロールフォワード)の対象になる。これは、コミット済みの更新がデータベースに反映されていない可能性があるためである。一方、障害の時点でまだコミットしていないトランザクションは、更新前情報を使って更新を取り消すロールバックの対象になる。チェックポイント取得後から障害発生前までにコミットしたトランザクションは、いずれも再実行の対象であり、一部だけを挙げると判断として不完全になる。 DBMS を再び立ち上げる場面でも、同じ基準で判断する。読み取りだけを行ったトランザクションは、データベースの値を変えていないため、取り消しも再実行も必要としない。 チェックポイントより前にコミット済みのトランザクションは、再実行の対象に含めない。
この節の続き
- 媒体障害からの回復の手順
- 運用での判断と必要な媒体の数
- 試験で問われやすい区別
ここまでが冒頭部分です。ログインすると、無料でも1日2節まで全文をお読みいただけます。
アプリでこの節を読む