第６章　トランザクション管理 ６．１ トランザクションの概念 ６．２ 同時実行制御 ６．３ 障害回復

６．３ 障害回復 １．障害とその回復 (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する。 ③ コミットしたトランザクションを順にREDOする。

その他のアルゴリズム データベース内容のバッファからディスクへの 書込みタイミングを制限する。 ① UNDO/NO-REDO（REDOを行わない） ② NO-UNDO/REDO（UNDOを行わない） ③ シャドーページ方式 　トランザクション中はデータをカレントページとシャドーページに ２重化し、トランザクション終了時に一本化する。

コミットやロールバックのとき、バッファをすべてフラッシュする？ 効率が悪い。フラッシュ途中の障害への対処も必要 (b) チェックポイント 回復時の効率 アーカイブとすべてのログを用いた回復 ① アーカイブをとるには時間がかかるので頻繁に行うのは困難 ② アーカイブをとってから障害までの時間が長いと、回復処理に時間がかかる。 ③ システム障害の場合、すべてのログを参照して回復処理を行うのは時間がかかるだけでなく、不要な処理（２回更新されていれば、２回処理を行う）も行わざるを得ない。 コミットやロールバックのとき、バッファをすべてフラッシュする？ 効率が悪い。フラッシュ途中の障害への対処も必要

チェックポイントという考え方 定期的にバッファをフラッシュ（この時点をチェックポイントという）し、 それ以降のログだけを用いて障害回復を行う。 ① 新たなトランザクションの開始を禁止。 ② 実行中のトランザクション処理のデータベース処理を一時停止させる。 ③ バッファ内容をフラッシュし、データベースに書き出す。 ④ 実行中のトランザクションをログに記録。

チェックポイントの例 チェックポイント 障害 時間 T1 T2 T3 T4 T5 T3とT4は再実行 （処理の対象外） REDO UNDO その後完了している。 REDO T3 T3 はチェックポイント時実行中で、 障害時も実行中 UNDO T4 T4 はチェックポイント後に開始され、 その後完了している。 T3とT4は再実行 REDO T5 T5 はチェックポイント後に開始され、 障害時も実行中 UNDO