データベース

第６章トランザクション管理
６．１トランザクションの概念
６．２同時実行制御
６．３障害回復
６．３障害回復
１．障害とその回復
(a) トランザクションと障害
【目的】
データベース操作中や実行後に何らかの障害やエ
ラーが起きたとき、データベースの一貫性を保つこと。
システムがダウンしたとき、処理結果を保存して
あれば、その結果は残っているがセーブしていな
いデータは失われてしまう。
途中で障害が起きても良いケース
残高チェックの処理のとき障害が起きた場合
データベースは更新されていないので、
データベースの内容は正常に保たれている。
（最初からやりなおせばよい）
途中で障害が起きたら困るケース（１）
①残高チェック
②引き落とし処理（ここで障害が起きた場合）
③振込処理
A. ②の更新が行われているが、③の受取人への振込が
行われていない。
B. 最初からやり直すと２回分の引落としが行われる。
C. ③からやり直すと、バッファからまだ書き込まれていな
い状態で障害が起きていたら、引落しされないで受取
人の口座に振込が行われる。
トランザクションの原子性
トランザクションを一体として扱う。
トランザクションを
すべて有効とするか/すべて無効とするか
のどちらかを保証する。
途中で障害が起きたら困るケース（２）
予約送金（ここで障害が起きた場合）
A. ハードディスクの内容が壊れていなければ、そのまま
でよい。
B. ハードディスクが壊れていたら、データ内容を回復する
必要がある。
(b) 障害の種類
①トランザクション障害
プログラムバグや端末障害などによるトランザクションの異常終
了（単一のトランザクションに限定される）
②システム障害
ハードウェア異常やソフトウェアのバグでシステムダウンし、すべ
ての処理が停止する障害。主記憶装置の内容はすべて失われる。
③メディア障害
ディスク内容が失われる障害。ディスククラッシュ、誤操作、意図
的な消去などがある。
バッファのフラッシュ
①データベースへのアクセスは、通常バッファを用いて行う。
②書込み時にバッファに書き込まれていないデータが残っている
かどうかが問題となる。
③未書込みのバッファをディスクに書き込み（バッファのフラッシュ
という）、書込みを保証する。
(c) UNDO, REDOと障害回復
【障害回復の基本的な処理】
①UNDO
・トランザクションがデータベースに対して行ったすべての処理の
取り消しを行う。
・トランザクション開始前の状態に戻す。
②REDO
・コミットしたトランザクションの再実行を行う。
・応用プログラムを再実行するのではなく、データベースへ内容
が再実行した場合と同じであればよい。
UNDO, REDOを障害別に適用
①トランザクション障害の回復
・該当トランザクションをUNDOする。
・トランザクションの再実行はユーザの責任で行う。
②システム障害の回復
ハードウェア修理やOSによるシステム回復処理後、
データベースの回復処理を行う。
・実行中トランザクションはUNDOする（全局的UNDO）。
・コミットしたトランザクションの更新データが失われた場合
REDOする（局所的REDO）。
(d) メディア障害
ディスク内容が失われるので、
多くのトランザクションが影響をうける。
ハードウェア故障の場合、修理してシステムを回復後、以下を行う。
① アーカイブ（あらかじめ保存しておいたデータ）を元にデータ
ベースを以前の状態に戻す（実行中トランザクション結果はなく
なるのでUNDOしなくてよい）。
② データ保存後に実行されたトランザクションのうちコミットしたトラ
ンザクションをREDOする（全局的REDO）。
③ アーカイブ作成の頻度が高いほど作成のオーバーヘッドが増え
るが、障害を早く回復できる（全局的REDOが少なくて済む）。
２．障害回復の方法
(a)ロギングによる障害回復
データベース処理の記録（ログまたはジャーナルという）を用いる
方法
最も重要な情報はデータベースへの書込み記録
①データ更新前の内容と更新後の内容をログに書き込む。
②REDOでは、更新後の内容を書き込む。
③UNDOでは、更新前の内容を書き込む。
（通常、データベース本体の情報とは別のエリア、別のディスクに
書き込まれる）
ログをとるタイミング
①ログをとる前にデータベース更新を行うとUNDOできなくなる。
②コミットしたトランザクションのログがとっていないとREDOできな
くなる（バッファから書き込まれるタイミングが問題となる）
【WAL(Write-Ahead Logging)プロトコル】
①データベースの更新前にログに書く。
②コミットする前に該当トランザクションのすべてのデータ更新をロ
グに書く。
UNDO/REDOアルゴリズムでの処理
（システム障害後の回復処理に用いられる）
①トランザクション開始をログに記録。
②読込みは、ログをとらずに行う。
③書込みは、まずログに書き込み、次にデータを書き込む。このと
き、ログとデータはバッファ内に残っていてもよい。
④コミット時は、ログを書き込んだ後、ログをフラッシュし、ディスク
に確実に書き込む。
⑤トランザクションのロールバック時は、ログに書き込んだ後で、
データをUNDOする。
システム障害後の回復処理
① ログを逆順に調べる。
② コミットしていないトランザクション（終了していないかロールバッ
クがログの中にある）をUNDOする。
③ コミットしたトランザクションを順にREDOする。
その他のアルゴリズム
データベース内容のバッファからディスクへの
書込みタイミングを制限する。
① UNDO/NO-REDO（REDOを行わない）
② NO-UNDO/REDO（UNDOを行わない）
③ シャドーページ方式
トランザクション中はデータをカレントページとシャドーページに
２重化し、トランザクション終了時に一本化する。
(b) チェックポイント
回復時の効率
アーカイブとすべてのログを用いた回復
① アーカイブをとるには時間がかかるので頻繁に行うのは困難
② アーカイブをとってから障害までの時間が長いと、回復処理に
時間がかかる。
③ システム障害の場合、すべてのログを参照して回復処理を行う
のは時間がかかるだけでなく、不要な処理（２回更新されてい
れば、２回処理を行う）も行わざるを得ない。
コミットやロールバックのとき、バッファをすべてフラッシュする？
効率が悪い。フラッシュ途中の障害への対処も必要
チェックポイントという考え方
定期的にバッファをフラッシュ（この時点をチェックポイントという）し、
それ以降のログだけを用いて障害回復を行う。
① 新たなトランザクションの開始を禁止。
② 実行中のトランザクション処理のデータベース処理を一時停止
させる。
③ バッファ内容をフラッシュし、データベースに書き出す。
④ 実行中のトランザクションをログに記録。
チェックポイントの例
チェックポイント
障害
T1
時間
T1はチェックポイント前に完了
（処理の対象外）
T2 はチェックポイント時実行中で、
その後完了している。
T2
REDO
T3
UNDO
T3とT4は再実行
T4
REDO
T5
UNDO
T3 はチェックポイント時実行中で、
障害時も実行中
T4 はチェックポイント後に開始され、
その後完了している。
T5 はチェックポイント後に開始され、
障害時も実行中

Download Report