この章では、RMANのデータ・リカバリ・アドバイザ・ツールを使用して、データベースの障害を診断および修復する方法について説明します。この章の内容は次のとおりです。
この項では、データ・リカバリ・アドバイザの目的および基本的な概念について説明します。
データ・リカバリ・アドバイザは、データ障害を自動的に診断し、適切な修復オプションを判断して提示し、ユーザーの要求に応じて修復を実行するOracle Databaseツールです。このコンテキストでは、データ障害とはディスク上の永続的なデータの破損または損失のことです。データの自動修復用の集中化されたツールであるデータ・リカバリ・アドバイザを使用すると、Oracle Databaseの管理性および信頼性が向上し、MTTRを短縮できます。
データ障害を診断し、修復に最適な計画を立案するには、高度なトレーニングおよび経験が必要です。データ・リカバリ・アドバイザには、従来の修復手法と比較して、次のようなメリットがあります。
データ・リカバリ・アドバイザは、データベース・プロセスで破損が検出されてエラーが通知される前に、データ障害の検出、分析および修復を行うことができます。早い時期に警告することによって、破損による損害を最小限に抑えることができます。
データ障害の症状を手動で評価し、症状を関連付けて問題陳述文にまとめる作業は、複雑で時間のかかる、エラーが発生しやすい作業です。データ・リカバリ・アドバイザは、自動的に障害を診断してその影響を評価し、発見した内容をユーザーにレポートします。
通常、ユーザーは修復の影響とともに修復オプションを手動で判断する必要があります。複数の障害が発生している場合、ユーザーは修復を実行する正しい順序を判断し、修復を統合する必要があります。一方、データ・リカバリ・アドバイザは、最適な修復オプションを自動的に判断し、それらのオプションが環境に適していることを確認するためのチェックを実行します。
データの修復は、複雑でエラーが発生しやすい作業です。自動修復オプションを選択すると、データ・リカバリ・アドバイザによって修復が実行され、修復に成功したことが確認されます。
この項では、データ・リカバリ・アドバイザを使用する前に理解しておく必要がある概念について説明します。
この項の内容は、次のとおりです。
データ・リカバリ・アドバイザには、コマンドラインおよびGUIの両方のインタフェースがあります。Oracle Enterprise Manager Cloud Controlでは、GUIインタフェースを使用できます。
RMANのコマンドライン・インタフェースでのデータ・リカバリ・アドバイザ・コマンドは、LIST FAILURE
、ADVISE FAILURE
、REPAIR FAILURE
およびCHANGE FAILURE
です。
障害は、データベースによって自動的に検出されるか、またはVALIDATE
コマンドなどの手動チェックによって検出されます。LIST FAILURE
コマンドを使用すると、障害に関する問題陳述文およびデータベースの操作に対するそれらの障害の影響を表示できます。各障害は、障害番号によって一意に識別されます。同じRMANセッションでADVISE FAILURE
コマンドを使用すると、修復オプションを表示できます。通常、これらのオプションには、自動オプションと手動オプションの両方があります。
ADVISE FAILURE
を実行した後、障害を手動で修復するか、またはREPAIR FAILURE
コマンドを実行して障害を自動的に修復することができます。修復とは、1つ以上の障害を修復する操作のことです。修復の例としては、ブロック・メディア・リカバリ、データファイル・メディア・リカバリ、Oracle Flashback Databaseなどがあげられます。自動修復オプションを選択すると、データ・リカバリ・アドバイザは修復に成功したかどうかを検証し、該当する修復済の障害をクローズします。
チェッカーとは、データベースまたはデータベース・コンポーネントの状態を評価するために状態モニターに登録された診断操作またはプロシージャのことです。状態の評価はデータ整合性チェックと呼ばれ、事後対応的または事前対応的に実行できます。
通常、障害は事後対応的に検出されます。破損したデータに対するデータベース操作でエラーが発生すると、データ整合性チェックが自動的に開始され、データベースでエラーに関連する障害が調査されます。障害が診断されると、その障害は自動診断リポジトリ(ADR)に記録されます。ADRは、データベースの外部に格納されているディレクトリ構造です。データベースによって障害が検出され、ADRに格納された後にのみ、データ・リカバリ・アドバイザを使用して、修復アドバイスを生成し、障害を修復できます。
データ整合性チェックを事前対応的に実行することもできます。チェックは状態モニターを介して実行します。状態モニターによって、事後対応的にチェックが実行された場合と同じ方法で障害が検出され、格納されます。また、「データベースの検証によるブロック破損の確認」で説明するように、VALIDATE
およびBACKUP VALIDATE
コマンドを使用してブロック破損をチェックすることもできます。
障害とは、データ整合性チェックによって検出される永続的なデータの破損のことです。障害は、エラー・メッセージやアラートなどの目に見える症状として示される場合がありますが、診断された問題を表すため、症状とは異なります。データベースによって問題が障害として診断された後、データ・リカバリ・アドバイザを使用して、障害に関する情報を取得し、障害の修復を行うことができます。
障害情報はデータベース自体には格納されていないため、この障害情報にアクセスするためにデータベースをオープンまたはマウントする必要はありません。障害は、データベースがNOMOUNT
モードで起動されている場合に表示できます。したがって、制御ファイルおよびリカバリ・カタログの可用性が、検出された障害の表示に影響することはありません。ただし、修復の可能性に影響を与えることはあります。
データ・リカバリ・アドバイザでは、次のような障害を診断できます。
存在しない、適切なアクセス権限がない、オフラインになっているなどの理由でアクセスできないデータファイルや制御ファイルなどのコンポーネント
ブロック・チェックサム障害、無効なブロック・ヘッダー・フィールド値などの物理的な破損
他のデータベース・ファイルより古いデータファイルなどの矛盾
ハードウェア・エラー、オペレーティング・システムのドライバの障害、オペレーティング・システムのリソース制限(たとえば、オープンしているファイルの数)の超過などのI/O障害
データ・リカバリ・アドバイザが、論理的な破損の一部を検出または処理することがあります。一般的に、このタイプの破損の場合は、Oracleサポート・サービスに連絡する必要があります。
すべての障害には、OPENまたはCLOSEDの障害ステータス
があります。障害ステータスは、適切な修復操作が行われるまで
OPEN
のままです。障害が修復されると、ステータスはCLOSED
に変更されます。
LIST
FAILURE
を実行するたびに、データ・リカバリ・アドバイザは、ステータスがOPENのすべての障害を再検証し、存在しなくなった障害をクローズします。したがって、別の手順の一部として障害を修復した場合、または障害が自然に消滅した一時的な問題であった場合、LIST FAILURE
を実行すると、障害は自動的にクローズされます。
CHANGE FAILURE
を使用すると、ステータスがOPENの障害を手動で修復した場合にそのステータスをCLOSED
に変更できます。ただし、CHANGE FAILURE ... CLOSED
は、なんらかの理由で障害が自動的にクローズされなかった場合にのみ使用することをお薦めします。CHANGE
を使用して手動でクローズした障害が存在したままになっている場合、データ・リカバリ・アドバイザは、適切なデータ整合性チェックを実行する際に別の障害IDでこの障害を再作成します。
すべての障害には、CRITICAL、HIGHまたはLOWの障害優先順位
があります。データ・リカバリ・アドバイザは、診断された障害に対して
CRITICAL
またはHIGH
の優先順位のみを割り当てます。
優先順位がCRITICAL
の障害は、データベース全体を使用できなくするため、すぐに対応する必要があります。たとえば、現行の制御ファイルを格納するディスクに障害が発生した場合などがあります。優先順位がHIGH
の障害は、データベースの一部を使用できなくしたり、リカバリできなくするため、通常は迅速に修復する必要があります。これらの障害の例としては、ブロック破損やアーカイブREDOログの欠落などがあります。
障害に優先順位HIGH
が割り当てられていても、データベースの可用性およびリカバリ可能性にはほとんど影響がない場合は、優先順位をLOW
に下げることができます。優先順位LOW
は、より重要な障害が修復されるまで、この障害を無視できることを示します。
デフォルトでは、LIST FAILURE
を実行すると、優先順位がCRITICAL
およびHIGH
の障害のみが表示されます。CHANGE
コマンドを使用して、LOW
およびHIGH
の障害のステータスは変更できますが、CRITICAL
の障害のステータスは変更できません。優先順位をLOW
に変更する主な理由としては、LIST FAILURE
の出力を削減することがあげられます。別の障害などのためにこの時点で障害を再検証できない場合、LIST FAILURE
には障害がOPENとして表示されます。
ADVISE FAILURE
コマンドでは、手動および自動の両方の修復オプションを表示できます。データ・リカバリ・アドバイザは、手動処理を必須またはオプションのいずれかとしてカテゴリ化します。
場合によっては、手動処理のみが可能であることがあります。消失した制御ファイルのバックアップが存在しないとします。この場合、手動処理では、CREATE CONTROLFILE
文を実行します。自動修復が利用可能ではないため、データ・リカバリ・アドバイザでは、この手動処理を必須として表示します。これに対して、欠落したデータファイルに対してRMANバックアップが存在するとします。この場合、REPAIR FAILURE
コマンドを実行すると、データファイルをリストアおよびリカバリすることによって、修復を自動的に実行できます。データファイルが誤って名前変更されたり移動された場合は、オプションの手動処理として、データファイルをリストアします。データ・リカバリ・アドバイザは、データファイルのリストアやリカバリなどの大規模な修復を回避できる場合に、オプションの手動処理を推奨します。
手動処理とは異なり、自動修復はデータ・リカバリ・アドバイザによって実行されます。ADVISE FAILURE
コマンドによって、各自動修復オプションのオプションIDが表示され、処理の要約が示されます。
データ・リカバリ・アドバイザでは、自動修復を推奨する前に、実行可能性チェックを実行します。たとえば、データ・リカバリ・アドバイザは、メディア・リカバリに必要なすべてのバックアップおよびアーカイブREDOログが存在しており、一貫性があるかどうかをチェックします。データ・リカバリ・アドバイザでは、特定のバックアップおよびアーカイブREDOログを必要とすることがあります。リカバリに必要なファイルが利用できない場合、リカバリを行うことはできません。
注意:
パフォーマンス上の理由から、データ・リカバリ・アドバイザは、全ファイルの全バイトを完全にチェックするわけではありません。このため、バックアップまたはアーカイブREDOログ・ファイルの破損が原因で、実行可能な修復が失敗する場合があります。
データ・リカバリ・アドバイザは、可能なかぎり複数の障害が1回で修復されるように修復を統合します。統合された修復では、手順が複数にわたる場合があります。
修復は統合できないこともあります。1つの障害によって、他の障害の修復を作成できない場合があるためです。たとえば、制御ファイルが欠落している場合、データファイルの修復の可能性を判断することはできません。 このような場合、データ・リカバリ・アドバイザは、修復可能な障害に対して1つの修復オプションを生成し、この時点では修復できない障害が存在することを示すメッセージをユーザーに出力します。提示された修復を実行した後、LIST
、ADVISE
およびREPAIR
を繰り返し実行すると、残りの障害を修復できます。
データ・リカバリ・アドバイザは、自動修復オプションの生成時に常に、RMANで障害の修復に使用されるコマンドに関するスクリプトを作成します。データ・リカバリ・アドバイザは、このスクリプトの場所を出力します。このスクリプトは、オペレーティング・システムに存在するテキスト・ファイルです。例15-1に、修復スクリプトの例を示します。この例は、データ・リカバリ・アドバイザによる消失したデータファイル27
の修復計画を示しています。
例15-1 修復スクリプトのサンプル
# restore and recover data file ALTER DATABASE DATAFILE 27 OFFLINE; restore datafile 27; recover datafile 27; ALTER DATABASE DATAFILE 27 ONLINE;
データ・リカバリ・アドバイザで障害を自動的に修復しない場合は、スクリプトをコピーして編集し、手動で実行できます。
現行のリリースでは、データ・リカバリ・アドバイザはシングル・インスタンス・データベースのみをサポートしています。Oracle Real Application Clusters(Oracle RAC)データベースはサポートしていません。
すべてのOracle RACインスタンスを停止するデータ障害が発生した場合は、データベースをシングル・インスタンス・モードでマウントして、データ・リカバリ・アドバイザを使用し、制御ファイル、SYSTEM
データファイルおよびデータ・ディクショナリの障害を検出および修復できます。また、データ・リカバリ・チェックを事前対応的に実行して、他のデータベース・コンポーネントのデータ障害をテストすることもできます。この方法では、他のクラスタ・インスタンスに対してローカルなデータ障害(アクセス不能なデータファイルなど)は検出されません。
Data Guard環境では、データ・リカバリ・アドバイザで次のことを行うことはできません。
フィジカル・スタンバイ・データベースから転送されたファイルを使用して、プライマリ・データベース上の障害を修復する。
スタンバイ・データベースの障害を診断し、修復する。
ただし、プライマリ・データベースを使用できない場合は、データ・リカバリ・アドバイザによって、スタンバイ・データベースへのフェイルオーバーを薦められることがあります。フェイルオーバー後に、古いプライマリ・データベースを修復できます。Enterprise Manager Cloud ControlをData Guard構成で使用している場合は、データ・リカバリ・アドバイザの推奨事項ページからフェイルオーバーを開始できます。
関連項目:
Data Guard構成でのRMANの使用方法については、『Oracle Data Guard概要および管理』を参照してください。
現行のリリースでは、データ・リカバリ・アドバイザは、非CDBおよびマルチテナント・コンテナ・データベース(CDB)のrootのデータ破損の診断および修復のみに使用できます。データ・リカバリ・アドバイザは、プラガブル・データベース(PDB)ではサポートされていません。
データ・リカバリ・アドバイザのワークフローは、障害の疑いが発生したときまたは障害が検出されたときに始まります。障害は、エラー・メッセージ、アラート、トレース・ファイル、データ整合性チェックの失敗などの多くの方法で検出できます。「データ整合性チェックについて」で説明されているように、データベースでは、エラーが発生した場合に障害を自動的に診断できます。
障害に対応するには、RMANセッションを開始し、次に示すすべての手順を同じセッションで、示されている順序で実行します。
この項に示すものと異なる順序で障害を診断および修復する手順を実行すると、エラーが発生する場合があります。
必要に応じて、データ・リカバリ・アドバイザのワークフロー内の任意の時点でCHANGE FAILURE
コマンドを使用して、障害優先順位をLOW
からHIGH
に、またはHIGH
からLOW
に変更するか、あるいは手動で修復された障害をクローズすることができます。このタスクの詳細は、「障害のステータスおよび優先順位の変更」を参照してください。
関連項目:
データ・リカバリ・アドバイザを使用したデータベースのリカバリの完全な例は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
1つ以上のデータベースの障害が発生した疑いがあるか、または発生したことがわかっている場合は、LIST FAILURE
を使用して、これらの障害に関する情報を取得します。障害のすべてまたはサブセットを表示し、様々な方法で出力を制限できます。障害は、障害番号によって一意に識別されます。これらの番号は連続していないため、障害番号が離れていても問題はありません。
LIST FAILURE
コマンドは、新しい障害を診断するためのデータ整合性チェックは実行しません。かわりに、以前に実行された評価の結果を表示します。したがって、LIST FAILURE
を繰り返し実行すると、コマンドを実行してから次にコマンドを実行するまでの間に発生したエラーに対応してデータベースで新しい障害が自動的に診断された場合にのみ、その障害が検出されます。ただし、LIST FAILURE
を実行すると、データ・リカバリ・アドバイザは既存のすべての障害を再検証します。ユーザーが障害を手動で修復した場合または一時的な障害が消滅した場合、データ・リカバリ・アドバイザは、これらの障害をLIST FAILURE
の出力から削除します。別の障害などのためにこの時点で障害を再検証できない場合、LIST FAILURE
によって障害がOPENとして表示されます。
この項の内容は、次のとおりです。
「データ整合性チェックについて」で説明されているように、破損したデータへのアクセスをユーザーのトランザクションで試行すると、データベースはそれに対応してデータ整合性チェックを実行します。遅延障害は検出されない場合もあります。たとえば、データ・ブロック破損エラーが発生すると、データベースは、エラーが発生したブロックおよびそのブロックに隣接している他のブロックを検証する事後対応型データ整合性チェックを実行します。ただし、エラーが発生したブロックに隣接していないブロックが破損している場合もあります。また、データベースによって読み取られない破損したブロックは、事後対応型データ整合性チェックでは検出されません。
事前対応型データ整合性チェックを効果的に実行する方法の1つとして、RMANでVALIDATE
またはBACKUP VALIDATE
コマンドを実行する方法があります。これらのコマンドによって、データファイルおよび制御ファイルに物理的な破損および論理的な破損がないかどうかを確認できます。RMANによってブロック破損が検出された場合、自動診断リポジトリにログが記録され、1つ以上の障害が作成されます。その後、データ・リカバリ・アドバイザを使用すると、これらの障害に関する情報を表示して、これらの障害を修復することができます。
データベースを検証する手順
関連項目:
VALIDATEコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
Oracle Databaseが診断データを管理する方法については、『Oracle Database管理者ガイド』を参照してください。
RMANセッションでLIST FAILUREを実行した後、ADVISE FAILUREコマンドを使用して
修復オプションを表示します。このコマンドによって、障害のサマリーが出力され、修復されているステータスがOPENのすべての障害がクローズされます。
必要に応じて、ADVISE FAILURE
コマンドによって手動および自動の修復オプションのリストが表示されます。最初に、必須またはオプションのいずれかとしてカテゴリ化された手動オプションが表示されます。オプションの手動の修復によって、データファイルのリストアやリカバリなどの大規模な処理を回避できる場合もあります。通常は、データベースに及ぶ影響が最も少なく、エラーが発生する可能性が最も少ない修復手法を使用します。
この項の内容は、次のとおりです。
1つ以上の障害が存在する場合は、通常、LIST FAILURE
を使用して障害の情報を表示してから、同じRMANセッションでADVISE FAILURE
を使用して修復オプションのレポートを取得します。
すべての障害に対する修復オプションを決定する手順
ADVISE FAILURE
で手動の修復が提示された場合は、これらの修復を最初に試行します。手動の修復が可能でない場合、または手動の修復ではすべての障害が修復されない場合は、REPAIR FAILURE
を使用して、現行のRMANセッションでの最新のADVISE FAILURE
コマンドで提示された障害の修復を自動的に実行することができます。
デフォルトでは、REPAIR FAILURE
の実行を開始する前に確認を求められます。NOPROMPT
オプションを指定して、確認のプロンプトが表示されないようにすることができます。コマンドの実行が開始されると、現行の修復フェーズが示されます。状況に応じて、RMANは、ユーザーに操作を求める場合があります。修復を実行した後、RMANは、この修復中に修復された可能性がある既存のすべての障害を再評価します。
通常は、修復を実行する前に、PREVIEW
オプションを指定して修復をプレビューすることをお薦めします。RMANは、修復を行わず、すべての修復操作およびコメントが含まれているスクリプトを生成します。特定の修復オプションを指定しなかった場合、RMANは、現行セッションの最新のADVISE FAILURE
コマンドの最初の修復オプションを使用します。デフォルトでは、修復スクリプトは標準出力に表示されます。SPOOL
コマンドを使用すると、編集可能なファイルにスクリプトを書き込むことができます。
関連項目:
REPAIR FAILUREコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
SPOOLコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。
CHANGE FAILURE
コマンドを使用して、障害のステータスまたは優先順位を変更する必要がある場合もあります。たとえば、ブロックの破損の優先順位がHIGH
で、そのブロックがほとんど使用されない表領域に存在する場合は、そのブロックの破損の優先順位を一時的にLOW
に変更できます。
REPAIR FAILURE
コマンド以外の方法で障害を修復すると、次回LIST FAILURE
を実行した場合、データ・リカバリ・アドバイザはこの障害を暗黙的にクローズします。このため、通常はCHANGE FAILURE ... CLOSED
コマンドを実行する必要はありません。このコマンドは、自動障害再検証が正常に実行されなかったにもかかわらず、障害は存在していないと確信できる場合にのみ使用する必要があります。CHANGE FAILURE
を使用して、存在したままになっている障害をクローズすると、データ・リカバリ・アドバイザは、適切なデータ整合性チェックを実行する際に別の障害IDでこの障害を再作成します。
通常、変更する障害は障害番号で指定します。ALL
、CRITICAL
、HIGH
またはLOW
を指定して、障害を一括で変更することもできます。障害は、CLOSED
、PRIORITY HIGH
またはPRIORITY LOW
に変更できます。
障害のステータスまたは優先順位を変更する手順
関連項目:
CHANGEコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』を参照してください。