(０)目次＆概説
(１) 障害復旧について
(１-１) インスタンス障害
(１-２) メディア障害
(１-２-１) 制御ファイル
(１-２-２) REDOログファイル
(１-２-３) データベースファイル
(１) 障害復旧について
(１-１) インスタンス障害
サーバー電源障害やバックグラウンドプロセスの異常停止などによりインスタンスが強制停止した場合の対処についてです。基本のアプローチとして、データベースの再起動を行います。再起動を行うと自動的にSMONプロセスによるインスタンスリカバリが行われます。
①リカバリ地点の確認
SMONプロセスが制御ファイルのSCNとデータファイルのSCNを比較し、リカバリを開始する地点を決定します。SCN(※注)はバッファキャッシュの内容をデータファイルに書き出すタイミングで更新されます(チェックポイントイベントが引き金)。この直後はメモリ上の情報と、ディスク上のデータファイルの情報は同期が取れていますので、インスタンス障害の復旧にはチェックポイント以降のREDOログのみがあればOK)。
(※注)SCNは「System Change Number」の略でトランザクションのCOMMIT時、タイムアウト時など、特定の条件を満たす時に採番される管理番号です。
②ロールフォワードの実行
リカバリ開始地点のSCN以降のREDOログをデータファイルに適用していき、最新のSCNまでロールフォワードを行います。また、この間にロールバック用のUNDOデータも作成します。
③ロールバックの実行
前の手順にて作成したUNDOデータを用いて、未COMMITの取引をロールバックします。
(１-２) メディア障害
OracleDBにおけるメディア障害はデータベースファイル(データファイル／REDOログ／制御ファイル)の一部消失やディスク障害を指します。
(１-２-１) 制御ファイルの可用性UP
制御ファイルの可用性を高める方法として、多重化を実施する事により、破損時にバックアップをコピーするのみで復旧が可能となります。しかし、多重化している場合であっても制御ファイルが１つでも破損すると動作停止するためにミラーリング等のHW観点の冗長化も検討があるとより万全となります。
(１-２-２) REDOログファイルの可用性UP
REDOログの可用性を高める方法として、以下の方法があります。
・REDOロググループの追加
REDOログは最低２グループ必要で、ログスイッチの待機（CKPTとARCN完了待ち）を防止するには３グループ以上が望ましい。
・REDOログメンバーの追加
Oracleはどれか一つのREDOログメンバーに書き込みが出来れば動作停止しないため、REDOログのグループに２つ以上のREDOログメンバを持たせ「多重化」を行います。
(備考)
Oracleの「データファイル」は「データそのもの」が保存され、「REDOログ」は「データの変更履歴」が保存されています。
(１-２-３) データベースファイルの可用性UP
データベースファイルの破損に対する可用性を高める方法としてARCHIVELOGモードで運用する方法があります。
・ARCHIVELOGモード
インスタンス障害＆メディア障害にも対応可能です。データベースがオープン状態でもバックアップが可能。またリストアの際は、障害が発生した特定のデータベースファイルのリストアのみで良い。
・NOARCHIVELOGモード
インスタンス障害のみに対応可能（※古いアーカイブログをバックアップしないため、CKPT以前のデータは復旧できない）。バックアップを取得するには、データベースを停止する必要あり。またリストア時にはデータベース全体のバックアップが必要（一貫性バックアップ）
