※用語はなるべく、Oracle® Databaseリファレンス 12c リリース1 (12.1) より抜粋しております。
【重要】：試験最重要ポイント
【理解】：試験問題を解くために必要な理解
太字：試験重要ポイント
赤字：最低限押さえておきたい知識
■公式チェックリストより出題範囲
バックアップとリカバリの概念
・チェックポイント、REDOログ・ファイルおよびアーカイブ・ログ・ファイルの重要性について説明する
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
要点
バックアップ、リカバリーに関係するアーキテクチャは頻出トピック。
Oracleサーバーに起こりうる障害パターンを理解した上でDBAの介入が必要な障害か、また不要であるかを覚えよう。
それに関する機能として、チェックポイントや、インスタンスリカバリを理解しよう。
何度も復習し、用語が出てきたらそれを他人に説明できるようになるよう理解しよう
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
バックアップとリカバリの概念
障害のカテゴリ
障害とはデータベースが使用できない状態、または実行したい処理が何らかの原因でエラーになることです。
Oracleサーバーでは次の障害パターンが考えられます。
| 障害パターン | 説明 |
|---|---|
| 文障害 | データベース操作（SQL）が失敗する |
| ユーザープロセス障害 | アプリケーションの異常終了などにより、ユーザーセッションが強制終了される |
| ネットワーク障害 | リスナーに接続できていない、ネットワーク接続ができない |
| ユーザーエラー | データベース操作としては正常だが、システムとしては不正な処理が行われた。 |
| インスタンス障害 | メモリー障害、OS障害などによりOracleインスタンスが強制停止された |
| メディア障害 | Oracleデータベースファイルの一部が損失した。 |
■文障害の解決
SQLの実行が失敗することで起きる障害のため、そのSQLのエラーを解決する必要があります。
●無効なデータの入力 例.ORA-01722：数値が無効です
→解決策：実際のSQL表の定義を確認し、正しいデータ入力ができるようにする
●権限が不十分 例.ORA-01031：権限が不足しています。
→解決策：適切なオブジェクト権限、システム権限をユーザーに付与する
●領域不足 例：ORA-01653：表スキーマ名.テーブル名を拡張できません。
ORA－01658：表領域 ●●にセグメント用のINITIALエクステントを作成できません。
→解決策：表領域の空き不足が原因であれば、表領域に領域を追加する。
→解決策：ユーザーの領域割当制限が原因であれば割当制限を増やす。
→解決策：再開領域割当機能を有効化する
●アプリケーションの論理エラー
→解決策：プログラムロジックを確認し、正しいロジックに修正する
■ユーザープロセス障害の解決
アプリケーションのプログラムエラーなどによって、ユーザーセッションが異常終了/強制終了することです。データベース管理者が解決する必要はありません。
ユーザーセッションが異常終了したことをPMONプロセスが検出するとPMONによってコミットされていない変更がロールバックされ、ロックが解放されサーバープロセスのクリーンアップを行います。
■ネットワーク障害の解決
ネットワークに接続できないことが原因で、セッションが確立できない、またはセッションが切断されることです。
ネットワーク接続の冗長性を検討します。
●リスナーへの接続エラー 例.ORA-12541： TNS：リスナーがありません。
→解決策：リスナーを複数構成にし、クライアントの接続記述子でフェイルオーバーを有効にする。
●ネットワークインターフェイスカードの障害 例.ORA-12154： TNS：指定された接続識別子を解決できませんでした。
→解決策：複数のネットワークインターフェイスカードを構成する等、ハードウェアを見直す。
■ユーザーエラーの解決
ユーザーが意図したものとは違う変更をデータに加えてしまうこと。変更の内容によってエラーの解決方法が違う。
●誤って表を削除した。
→解決策：ゴミ箱から復活させる。（フラッシュバックドロップ）
※同じオブジェクト名で複数のオブジェクトがある場合は、システム生成されたゴミ箱内のオブジェクト名で明示的に復活させます。
●誤って表を切り捨てた。
→解決策：フラッシュバックデータベースにて巻き戻しを行う。
→解決策：表領域のPoint-in-Timeリカバリを行う。
●誤って変更をコミットした。
→解決策：UNDOデータが残っているのであれば、フラッシュバックテーブルを使用する。
→解決策：UNDOデータが残っていないのであれば、LogMinerを使用してREDOログエントリを問い合わせる。
フラッシュバック機能
▶フラッシュバックデータベース
データベース全体を過去に戻す（フラッシュバックログが必要）
▶フラッシュバックテーブル
特定の表を過去に戻す機能。フラッシュバックテーブルを行うには、事前に行移動の有効化が必要です。
▶フラッシュバックドロップ
削除した表を復活させる機能。（ごみ箱に表が残っている必要がある）
▶フラッシュバック問合せ
表の過去の状態を問い合わせる
▶フラッシュバックトランザクション問合せ
1つのトランザクション内で行われた変更を表示する。
■インスタンス障害の解決
インスタンス障害は、サーバーマシンの電源断やバックグラウンドの異常停止、Oracleインスタンスの強制停止が原因で、Oracleサーバーが停止することです。
データベース管理者が行う必要があるのは、データベースの再起動だけです。
Oracleサーバーを再起動すると、SMONプロセスがインスタンス障害を検出し、REDOログファイルを使用してロールフォワード、ロールバック操作が自動的に行われます。
■メディア障害の解決
メディア障害は、Oracleデータベースファイルの損失や、ディスクドライブ、ディスクコントローラーの障害が原因で発生します。
これを解決するには、基本的にはバックアップファイルのリストア処理とREDOログエントリを適用するリカバリ処理が必要です。
ただし、REODログファイルと制御ファイルが多重化されている場合は、バックアップを使用するのではなく再作成で済むものもあるので、事前のバックアップ体制とデータベース構成が重要です。
インスタンスリカバリの理解
■インスタンスリカバリで行われる処理
チェックポントにより、メモリーとディスクの整合性が取れた状態になりますので、チェックポイント前のREDOログエントリは回復処理には不要になります。
インスタンス障害が発生した場合は、最後のチェックポイント以降のREDOログエントリをデータファイルに適用することで、最新の状態にリカバリすることが出来ます。
インスタンス障害の再起動時には、SMONプロセスが制御ファイルのチェックポイント番号と、データファイルヘッダーのチェックポイント番号を比較し、どこからのインスタンスリカバリが必要かを判断します。
REDOログエントリは最後にCOMMITされた時の状態まで適用されます、最後のCOMMIT以降のトランザクションはロールバックされます。
■チェックポイント
DMLによって行われるデータの変更は、データベースバッファキャッシュ上で行われますが、この変更ではトランザクションがコミットされてもデータファイルへの書き出しは行われていません。
代わりにコミットした場合はREDOログバッファ内のすべてのREDOログエントリがLREGプロセスによってREDOログファイルに書き出されています。
データベースバッファキャッシュ内の変更は「チェックポイント」というイベントが発生した時にデータファイルに書き出されています。チェックポイントではDBWｎ（データベースライター）プロセスとCKPT（チェックポイント）プロセスによって次の処理が行われます
●DBWｎによるデータファイルへの変更済みブロックの書き出し
●CKPTによる制御ファイル内のチェックポイント番号の更新
●CKPTによるデータファイルヘッダー内のチェックポイント番号の更新
チェックポイントは次のタイミングで行われます。
●管理者によるコマンド発行
●表領域のオフライン（IMMEDIATE以外）
●データベースの停止
●ログスイッチが起きたとき
●データベースが正常に停止した場合
■インスタンスリカバリの調整
●REDOログファイルのサイズを調整することで、チェックポイントの頻度を調整できる。
●MTTRアドバイザを使用する。
現在の状態において、インスタンスリカバリにどのくらいの時間がかかるのかを見積もるために使用することができる。
FAST_START_MTTR_TARGET初期化パラメータ（平均リカバリ時間）を設定することで調整できる。
→インスタンスリカバリを5分以内に終了させたい場合
FAST_START_MTTR_TARGET = 300
・チェックポイントの頻度が多いとインスタンスリカバリ時間は短くなるが、その分多くのディスクに書き込みが発生することになるため、パフォーマンスに影響が出ます。
・FAST_START_MTTR_TARGETの値を小さくすると、データファイルへの書き込みが多くなるため、I/Oオーバーヘッドが大きくなりパフォーマンスに影響が出ます。
リカバリの可能性を高める事前タスク
他のトピックでも記載しているのでおさらい程度に。
制御ファイルの多重化
多重化の目的：制御ファイルが損失した場合のリカバリ時間を短くするため。
制御ファイルは多重化していても1つでも損失するとデータベースは停止する。
多重化しておけば、損失していない正常な制御ファイルをコピーして再設置するだけでリカバリすることができる。
制御ファイルをコピーする場合、データベースは停止させる必要がある点に注意
REDOログファイルの多重化
同じ内容を書き込むREDOログファイルの集まりを「REDOロググループ」といいます。
REDOロググループは最低2つ必要です。
多重化の方法：REDOロググループ内に複数のREDOログファイルを指定すること。
REDOロググループの情報はV$LOGビューからも確認できます。REDOログメンバーの情報はV$LOGFILEビューから確認できます。
同じグループ内に正常なREDOログファイルが1つでも残っていればデータベースは正常に稼働します。
REDOログファイルに障害が発生した場合は、アラートログファイルにその情報が追加されます。
出題例
出題例：MTTRアドバイザに関する説明として正しいものを選択しなさい
→FAST_START_MTTR_TARGETパラメータが0の場合、使用することはできない。
→V$MTTR_TARGET_ADVICEビューで結果を確認することが出来る。
→MTTR時間に対するI/O量を見積もることが出来る
出題例：データベース管理者が介入してリカバリを行う必要のある障害は？
→ユーザーエラー
誤った表の削除によるフラッシュバック操作
→メディア障害
ディスク障害、データベースファイル障害によるハードウェアの修復、リストア、リカバリ
誤った選択肢として
ユーザープロセス障害（PMONが自動でクリーンアップする）
インスタンス障害（自動でインスタンスリカバリされる）
ネットワーク障害（そもそもリカバリではない）
が出題される
出題例：インスタンスリカバリについて正しい選択肢を選びなさい
→最後のチェックポイント以降のREDOログエントリをデータファイルに適用する
言い換えるとチェックポイントのSCNより小さいSCNを持つすべてのコミット済の変更が適用する処理を行っている。
→最後のCOMMIT以降のトランザクションはロールバックする
出題例：インスタンスリカバリで行われる処理の「ロールフォワード」「ロールバック」について正しい選択肢を選びなさい
→「ロールフォワード」最後にCOMMITされたREDOログエントリがデータファイルに適用される。
→「ロールバック」最後のCOMMIT以降のトランザクションをロールバックする
出題例：チェックポイントの頻度が多いため減らしたい。どのような操作を行うべきか。
→REDOログファイルのサイズを大きくする。
→MTTRアドバイザを使用し、FAST_START_MTTR_TARGET初期化パラメータを（大きい数字に）設定する。
インスタンスリカバリにかかる時間を短縮するためには、上記の逆の操作を行う。