※用語はなるべく、Oracle® Databaseリファレンス 12c リリース1 (12.1) より抜粋しております。
【重要】：試験最重要ポイント
【理解】：試験問題を解くために必要な理解
太字：試験重要ポイント
赤字：最低限押さえておきたい知識
■公式チェックリストより出題範囲
データベースのリカバリの実行
・リカバリを実行する必要があるかどうかを判断する
・Recovery Manager（RMAN）とデータ・リカバリ・アドバイザを使用して制御ファイル、REDOログ・ファイルおよびデータ・ファイルのリカバリを実行する
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
要点
バックアップ、リカバリーに関係するアーキテクチャは頻出トピック。
何度も復習し、用語が出てきたらそれを他人に説明できるようになるよう理解しよう
出題範囲に書かれていることが全て、かつ最重要。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
データベースのリカバリの実行
Oracleサーバーのディスク障害が発生した時のリカバリ方法。
ARCHIVELOGモード時とNOARCHIVELOGモード時でリカバリ方法が変わることを理解しよう。
データベースのオープンに必要な条件
メディア障害タイプによっては、データベースは停止することなく、オープンした状態を続けることが出来ます。
ただし、クリティカルな障害の場合は、障害発生時にデータベースが停止し、データベースをオープンすることができないという状況も発生します。
■データベースが停止する時
Oracleデータベースは、制御ファイル、REDOログファイル、データファイルで構成されており、すべてのデータベースファイルの整合が取れている状態でなければいけません。データベースファイルの中で、次の障害が発生するとOracleデータベースは停止します。
●制御ファイルの損失
制御ファイルが多重化されていても、1つの制御ファイルに障害が発生すると、制御ファイルにアクセスが必要となったときにOracleサーバーは停止します。
●SYSTEM表領域アクティブなUNDO表領域に属するデータファイルの損失
SYSTEM表領域に属するデータファイル、UNDO_TABLESPACE初期化パラメータに指定されているUNDO表領域に属するデータファイルに障害が発生すると、これらのデータファイルにアクセスが必要になった時にOracleサーバーは停止します。
●REDOロググループ内にあるすべてのREDOログメンバーの喪失
REDOロググループに属するすべてのREDOログメンバーに損失が発生すると、LGWRによる書込みが発生した時にOracleサーバーは停止します。
※注意※
Oracleサーバーの停止とは、インスタンスまたはデータベースが機能しなくなる状態をいいます。
制御ファイル、SYSTEM表領域とアクティブなUNDO表領域に属するデータファイルおよび、REDOロググループ内にあるすべてのREDOログメンバーの損失が発生しても必ずしもインスタンスが停止するとは限りません。
■データベースが起動できる時
Oracleサーバーの起動は、インスタンス起動、データベースのマウント、データベースのオープンの3段階で行われます。
①インスタンスの起動
初期化パラメータファイルノオープン
→CONTOROL_FILES初期化パラメータにて制御ファイルの認識
②データベースのマウント
制御ファイルのOracleインスタンスに対応付け
制御ファイルのオープン
→制御ファイル内の情報から、REDOログファイル、データファイルを認識
③データベースノオープン
REDOログファイルとデータファイルのオープン
→一般ユーザーの接続も可能になる
✖マウント失敗
→制御ファイルの障害（インスタンス起動のみで停止する。）
✖データベースオープンの失敗
→REDOログファイルとデータファイルの障害（データベースのマウントで停止する）
→通常のデータファイルが損失している場合（一時表領域の一時ファイルの場合はオープン可能）
■制御ファイルの損失からのリカバリ
制御ファイルを損失している場合、Oracleサーバーはマウントできません。
制御ファイルを多重化している場合であっても、そのうちの1つを損失するとマウントできません。
【重要】
制御ファイルに障害があると「ORA-00205」エラーが発生し、データベースをマウントできません。詳細はアラートログを確認してください。
■多重化された制御ファイルの1つが損失した場合のリカバリ
【重要】
多重化された制御ファイルの一部が損失したのであれば、正常な制御ファイルを再度コピーするだけでリカバリは完了です。
■多重化された制御ファイルのすべてが損失した場合のリカバリ
制御ファイルが全滅した時のリカバリ方法は2つあります。
●バックアップ制御ファイルとリストアし、リカバリコマンドを使用する
ＲＥＳＥＴＬＯＧ句付きでオープンするという処理が必要になるため、できれば制御ファイルを再作成することを検討したほうがよいでしょう。
●制御ファイルを再作成する
制御ファイルのトレースがあるなら、スクリプトを実行するだけで完了できる。スクリプトはテキストファイルなので必要に応じて編集することも可能
■REDOログファイルの損失からのリカバリ
REDOロググループ内の一部のREDOログメンバーが損失している場合、Oracleサーバーをオープンすることができます。この場合は、アラートログに情報が格納されます。
■REDOロググループの一部のREDOログメンバーが損失した場合のリカバリ
REDOロググループの一部のREDOログメンバーが損失したのであれば、正常なログメンバーをコピーするだけでリカバリは完了です。
■REDOロググループのすべてのREDOログメンバーが損失した場合のリカバリ
アーカイブREDOログファイルが作成済で、回復に必要がなくなったREDOロググループであれば、次のコマンドで再作成することができます。
ALTER DATABASE CLEAR LOGFILE GROUP グループ番号；
回復が必要なくなったREDOロググループであれば、アーカイブREDOログファイルの作成ができていなくても、次のコマンドで再作成することができます。
ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP グループ番号
※ただし、アーカイブREDOログファイルが欠落することになるので、この構文を使用する際はバックアップ計画を見直しましょう
V$LOGビューを確認することで、アーカイブREDOログファイルが作成済であることと、回復処理に必要が無くなっていることが確認できます。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
データファイルの損失からのリカバリ
■NOARCHIEVELOGモードのデータファイルの損失からのリカバリ
NOARCHIVELOGモードの場合、REDOログファイルにのみ変更内容が存在します。
そのため、バックアップからの変更履歴がREDOログファイルに残っているのであれば、損失したデータファイルのバックアップをリストアしたリカバリもできますが、REDOログファイルに残っているかどうかは保証できません。
そのため、基本的には、一部のデータファイルに障害があった場合でも、全体バックアップをリストアし、データベースをオープンするというのがNOARCHIVELOGモード時のリカバリ方法です。
①Oracleサーバーの停止
②データベース全体をバックアップからリストア
③データベースをオープン
■ARCHIVELOGモードのデータファイルの損失からのリカバリ
ARCHIVELOGモードの場合、全体バックアップだけでなく、部分バックアップもできます。
データベースに対する変更は、REDOログファイルの内容をアーカイブREDOログファイルとして保存しています。そのため、データファイルが損失した場合は、そのデータファイルのみをリストアし、アーカイブREDOログファイルを適用するリカバリを行うことで障害発生時直前の状態にすることができます。
■非クリティカルデータファイルの損失からのリカバリ
非クリティカルデータファイルとはSYSTEM表領域に属したデータファイルとアクティブなUNDO表領域に属したデータファイルを除くファイルのことです。
データベースのオープン時にオフラインにできるデータファイルが「非クリティカルデータファイル」となります。
非クリティカルデータファイルの場合は、データベースをオープンしたままでリストア、リカバリを実行できます。
①表領域、またはデータファイルをオフラインにする
②損失したデータファイルをリストアする
③損失したデータファイルに対するリカバリを行う
④表領域、またはデータファイルをオンラインにする
【重要】
●バックアップファイルがないデータファイルのリカバリには、データファイルが作成されてからのアーカイブREDOログファイルが必要
■クリティカルデータファイルの損失からのリカバリ
●SYSTEM表領域、アクティブなUNDO表領域がクリティカルデータファイルに該当します。
非クリティカルデータファイルの損失のリカバリとは反対に、データベースがオープンしている状態ではリカバリできません。データベースはマウントしている状態でリカバリする必要があります。
①データベースが起動している場合は、データベースを停止する
②データベースをマウントする
③損失したデータファイルをリストアする
④損失したデータファイルに対するリカバリを行う
⑤データベースをオープンする
■データリカバリアドバイザ
データファイルの破損やデータブロック破損に対するリカバリを提供します。自動診断リポジトリ（ADR)とRMANを使用して、問題の表示、修復スクリプトの生成、修復の実行を自動化することが出来ます。
■データリカバリアドバイザの概要
データリカバリアドバイザを使用することで、現在発生しているデータベースファイル障害に対し、効率的なリカバリ方法を選択できます。
ブロック破損が発生している場合、対象となるブロック数が少なければブロックメディアリカバリの方がリカバリ時間が短くて済みますが、ブロック数が多い場合は、データファイルのリストアとリカバリの方がよい場合があります。
データリカバリアドバイザは、最適とされるリカバリ方法を提示します。
出題例：データリカバリアドバイザで解決できる障害を選択しなさい
→ブロックチェックサムの障害
→アクセスできない制御ファイル
→ハードウェア障害で認識できないREDOログファイル
→ブロックヘッダーの障害
【理解】想定される障害
・データベースファイルに起きた障害
・破損ブロック障害（ブロックチェックサム障害、無効なブロックヘッダー）
・ハードウェアやOSからのI/O障害
想定される障害のどれに該当するかを考えよう
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
RMANコマンドの使用
■LIST FAILURE
自動診断リポジトリ（ADR）内の障害を一覧表示する。
デフォルトでは、CRITICALとHIGHの障害のみ表示される。
■ADVISE FAILURE
障害に対し、推奨される修復オプションを表示し、可能であれば修復スクリプトを作成する。
データリカバリアドバイザとして認識している障害のサマリーと修復オプションを表示します。
自動修復オプションが生成されると、修復スクリプトも自動的に生成されます。
【重要】
同じセッションでLIST FAILUREコマンドが実行されていない場合、オプションを指定しないと、次のエラーが表示されます。
RMAN-07211:障害オプションが指定されていません
■REPAIR FAILURE
ADVISE FAILURE にて作成された修復スクリプトを使用して障害を修復し、障害をクローズする。
【重要】
同じセッションでADVISE FAILUREコマンドが実行されていない場合、次のエラーが表示されます。
RMAN-06954：同じセッション内では、REPAIR コマンドの前にADVISE コマンドがある必要があります
■CHANGE FAILURE
障害優先度は自動的に設定されますが、CHANGE FAILURE を使用して優先度を変更できます。障害が修復されれば自動的にクローズされます。 既存の障害の優先度を変更したり明示的にクローズしたりすることができます。ただし、障害優先度の変更では、CRITICALをHIGHやLOWにすることはできません。
出題例
出題例：フラッシュバックトランザクションを実行するための前提条件
→Flashback Databaseを有効にする
→トランザクションをフラッシュバックするユーザーにDBMS_FLASHBACKパッケージ対するEXECUTE権限が付与されている必要がある