| Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド 11g リリース2(11.2) B56269-05 |
|
 前 |
 次 |
この章では、RMANのデータ・リカバリ・アドバイザ・ツールを使用して、データベースの障害を診断および修復する方法について説明します。この章の内容は次のとおりです。
この項では、データ・リカバリ・アドバイザの目的および基本的な概念について説明します。
データ・リカバリ・アドバイザは、データ障害を自動的に診断し、適切な修復オプションを判断して提示し、ユーザーの要求に応じて修復を実行するOracle Databaseツールです。このコンテキストでは、データ障害とはディスク上の永続的なデータの破損または損失のことです。データの自動修復用の集中化されたツールであるデータ・リカバリ・アドバイザを使用すると、Oracle Databaseの管理性および信頼性が向上し、MTTRを短縮できます。
データ障害を診断し、修復に最適な計画を立案するには、高度なトレーニングおよび経験が必要です。データ・リカバリ・アドバイザには、従来の修復手法と比較して、次のようなメリットがあります。
データ・リカバリ・アドバイザは、データベース・プロセスで破損が検出されてエラーが通知される前に、データ障害の検出、分析および修復を行うことができます。早い時期に警告することによって、破損による損害を最小限に抑えることができます。
データ障害の症状を手動で評価し、症状を関連付けて問題陳述文にまとめる作業は、複雑で時間のかかる、エラーが発生しやすい作業です。データ・リカバリ・アドバイザは、自動的に障害を診断してその影響を評価し、発見した内容をユーザーにレポートします。
通常、ユーザーは修復の影響とともに修復オプションを手動で判断する必要があります。複数の障害が発生している場合、ユーザーは修復を実行する正しい順序を判断し、修復を統合する必要があります。一方、データ・リカバリ・アドバイザは、最適な修復オプションを自動的に判断し、それらのオプションが環境に適していることを確認するためのチェックを実行します。
データの修復は、複雑でエラーが発生しやすい作業です。自動修復オプションを選択すると、データ・リカバリ・アドバイザによって修復が実行され、修復に成功したことが確認されます。
この項では、データ・リカバリ・アドバイザを使用する前に理解しておく必要がある概念について説明します。
データ・リカバリ・アドバイザには、コマンドラインおよびGUIの両方のインタフェースがあります。GUIインタフェースは、Oracle Enterprise Manager Database ControlおよびGrid Controlで使用できます。データベースのホームページの「可用性」タブにある「リカバリの実行」をクリックすると、図15-1に示すページにナビゲートできます。
RMANのコマンドライン・インタフェースでのデータ・リカバリ・アドバイザ・コマンドは、LIST FAILURE、ADVISE FAILURE、REPAIR FAILUREおよびCHANGE FAILUREです。
障害は、データベースによって自動的に検出されるか、またはVALIDATEコマンドなどの手動チェックによって検出されます。LIST FAILUREコマンドを使用すると、障害に関する問題陳述文およびデータベースの操作に対するそれらの障害の影響を表示できます。各障害は、障害番号によって一意に識別されます。同じRMANセッションでADVISE FAILUREコマンドを使用すると、修復オプションを表示できます。通常、これらのオプションには、自動オプションと手動オプションの両方があります。
ADVISE FAILUREを実行した後、障害を手動で修復するか、またはREPAIR FAILUREコマンドを実行して障害を自動的に修復することができます。修復とは、1つ以上の障害を修復する操作のことです。修復の例としては、ブロック・メディア・リカバリ、データファイル・メディア・リカバリ、Oracle Flashback Databaseなどがあげられます。自動修復オプションを選択すると、データ・リカバリ・アドバイザは修復に成功したかどうかを検証し、該当する修復済の障害をクローズします。
|
関連項目: Enterprise Managerによるバックアップおよびリカバリの実行方法は、『Oracle Database 2日でデータベース管理者』を参照してください。 |
チェッカーとは、データベースまたはデータベース・コンポーネントの状態を評価するために状態モニターに登録された診断操作またはプロシージャのことです。状態の評価はデータ整合性チェックと呼ばれ、事後対応的または事前対応的に実行できます。
通常、障害は事後対応的に検出されます。破損したデータに対するデータベース操作でエラーが発生すると、データ整合性チェックが自動的に開始され、データベースでエラーに関連する障害が調査されます。障害が診断されると、その障害は自動診断リポジトリ(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 sql 'alter database datafile 27 offline'; restore datafile 27; recover datafile 27; sql 'alter database datafile 27 online';
データ・リカバリ・アドバイザで障害を自動的に修復しない場合は、スクリプトをコピーして編集し、手動で実行できます。
現行のリリースでは、データ・リカバリ・アドバイザはシングル・インスタンス・データベースのみをサポートしています。Oracle Real Application Clusters(Oracle RAC)データベースはサポートしていません。
すべてのOracle RACインスタンスを停止するデータ障害が発生した場合は、データベースをシングル・インスタンス・モードでマウントして、データ・リカバリ・アドバイザを使用し、制御ファイル、SYSTEMデータファイルおよびデータ・ディクショナリの障害を検出および修復できます。また、データ・リカバリ・チェックを事前対応的に実行して、他のデータベース・コンポーネントのデータ障害をテストすることもできます。この方法では、他のクラスタ・インスタンスに対してローカルなデータ障害(アクセス不能なデータファイルなど)は検出されません。
Data Guard環境では、データ・リカバリ・アドバイザで次のことを行うことはできません。
フィジカル・スタンバイ・データベースから転送されたファイルを使用して、プライマリ・データベース上の障害を修復する。
スタンバイ・データベースの障害を診断し、修復する。
ただし、プライマリ・データベースを使用できない場合は、データ・リカバリ・アドバイザによって、スタンバイ・データベースへのフェイルオーバーを薦められることがあります。フェイルオーバー後に、古いプライマリ・データベースを修復できます。Enterprise Manager Grid ControlをData Guard構成で使用している場合は、データ・リカバリ・アドバイザの推奨事項ページからフェイルオーバーを開始できます。
|
関連項目: Data Guard構成でのRMANの使用方法については、『Oracle Data Guard概要および管理』を参照してください。 |
データ・リカバリ・アドバイザのワークフローは、障害の疑いが発生したときまたは障害が検出されたときに始まります。障害は、エラー・メッセージ、アラート、トレース・ファイル、データ整合性チェックの失敗などの多くの方法で検出できます。「データ整合性チェック」で説明されているように、データベースでは、エラーが発生した場合に障害を自動的に診断できます。
障害に対応する場合の基本的なプロセスでは、RMANセッションを開始し、その同じセッションで次の手順をすべて実行します。
LIST FAILUREコマンドを実行して、障害を表示します。
このタスクの詳細は、「障害の表示」を参照してください。
データベースによって自動的に診断されていない障害の存在が疑われる場合は、VALIDATE DATABASEを実行して、破損ブロックおよび欠落しているファイルを確認します。
VALIDATEによって問題が検出されると、RMANが障害の評価の実行をトリガーします。障害が検出されると、データ・リカバリ・アドバイザからアクセスできる自動診断リポジトリにログが記録されます。
このタスクの詳細は、「データベースの検証によるブロック破損の確認」を参照してください。
ADVISE FAILUREコマンドを実行して、修復オプションを決定します。
このタスクの詳細は、「修復オプションの決定」を参照してください。
修復オプションを選択します。障害は、手動で修復するか、またはREPAIR FAILUREコマンドを実行して自動的に修復することができます。
このタスクの詳細は、「障害の修復」を参照してください。
最初の手順に戻り、すべての障害が修復されていることを確認するか、または残っている障害を特定します。
この項に示すものと異なる順序で障害を診断および修復する手順を実行すると、エラーが発生する場合があります。
必要に応じて、データ・リカバリ・アドバイザのワークフロー内の任意の時点でCHANGE FAILUREコマンドを使用して、障害優先順位をLOWからHIGHに、またはHIGHからLOWに変更するか、あるいは手動で修復された障害をクローズすることができます。このタスクの詳細は、「障害のステータスおよび優先順位の変更」を参照してください。
1つ以上のデータベースの障害が発生した疑いがあるか、または発生したことがわかっている場合は、LIST FAILUREを使用して、これらの障害に関する情報を取得します。障害のすべてまたはサブセットを表示し、様々な方法で出力を制限できます。障害は、障害番号によって一意に識別されます。これらの番号は連続していないため、障害番号が離れていても問題はありません。
LIST FAILUREコマンドは、新しい障害を診断するためのデータ整合性チェックは実行しません。かわりに、以前に実行された評価の結果を表示します。したがって、LIST FAILUREを繰り返し実行すると、コマンドを実行してから次にコマンドを実行するまでの間に発生したエラーに対応してデータベースで新しい障害が自動的に診断された場合にのみ、その障害が検出されます。ただし、LIST FAILUREを実行すると、データ・リカバリ・アドバイザは既存のすべての障害を再検証します。ユーザーが障害を手動で修復した場合または一時的な障害が消滅した場合、データ・リカバリ・アドバイザは、これらの障害をLIST FAILUREの出力から削除します。別の障害などのためにこの時点で障害を再検証できない場合、LIST FAILUREによって障害がOPENとして表示されます。
データベースで発生する問題を確認する最も簡単な方法は、LIST FAILUREコマンドを使用する方法です。
すべての障害を表示する手順
RMANを起動し、ターゲット・データベースに接続します。ターゲット・データベース・インスタンスが起動されている必要があります。
LIST FAILUREコマンドを実行します。
次の例では、データ・リカバリ・アドバイザで認識されるすべての障害をレポートします(ページに収まるように出力の形式が再設定されています)。
RMAN> LIST FAILURE; List of Database Failures ========================= Failure ID Priority Status Time Detected Summary ---------- -------- --------- ------------- ------- 142 HIGH OPEN 23-APR-07 One or more non-system datafiles are missing 101 HIGH OPEN 23-APR-07 Datafile 1: '/disk1/oradata/prod/system01.dbf' contains one or more corrupt blocks
この例では、RMANは、欠落しているデータファイルのグループおよび破損ブロックが含まれているデータファイルの2つの異なる障害をレポートしています。出力には、各障害の一意の識別子(142および101)、優先順位、ステータスおよび検出時刻が示されています。
必要に応じて、LIST FAILURE ... DETAILコマンドを実行して、障害を個々に表示します。
「障害のグループ化」で説明されているように、データ・リカバリ・アドバイザは可能なかぎり障害を統合します。障害を個々に表示するには、DETAILオプションを指定します。たとえば、ファイル内で複数のブロックが破損している場合、DETAILオプションを指定すると、各ブロックの破損が表示されます。次の例では、障害101に関する詳細情報を表示します。
RMAN> LIST FAILURE 101 DETAIL;
List of Database Failures
=========================
Failure ID Priority Status Time Detected Summary
---------- -------- --------- ------------- -------
101 HIGH OPEN 23-APR-07 Datafile 1: '/disk1/oradata/prod/system01.dbf' contains one or more corrupt blocks
List of child failures for parent failure ID 101
Failure ID Priority Status Time Detected Summary
---------- -------- --------- ------------- -------
104 HIGH OPEN 23-APR-07 Block 56416 in datafile 1: '/disk1/oradata/prod/system01.dbf' is media corrupt
Impact: Object BLKTEST owned by SYS might be unavailable
「修復オプションの決定」に進み、LIST FAILUREコマンドによって表示された障害の修復方法を決定します。
LIST FAILUREでは、さらに詳しい出力を表示できるのみでなく、出力を制限することもできます。たとえば、CRITICAL、HIGH、LOWまたはCLOSEDオプションを使用してLIST FAILUREを実行すると、特定のステータスまたは優先順位を持つ障害のみを表示できます。また、EXCLUDE FAILUREを指定して、指定した障害を出力から除外することもできます。
障害のサブセットを表示する手順
RMANを起動し、ターゲット・データベースに接続します。ターゲット・データベース・インスタンスが起動されている必要があります。
必要なオプションを指定してLIST FAILUREを実行します。
次の例は、いくつかのLIST FAILUREコマンドを示しています。
LIST FAILURE LOW; LIST FAILURE CLOSED; LIST FAILURE EXCLUDE FAILURE 234234;
|
関連項目: LIST FAILUREコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』 |
「データ整合性チェック」で説明されているように、破損したデータへのアクセスをユーザーのトランザクションで試行すると、データベースはそれに対応してデータ整合性チェックを実行します。遅延障害は検出されない場合もあります。たとえば、データ・ブロック破損エラーが発生すると、データベースは、エラーが発生したブロックおよびそのブロックに隣接している他のブロックを検証する事後対応型データ整合性チェックを実行します。ただし、エラーが発生したブロックに隣接していないブロックが破損している場合もあります。また、データベースによって読み取られない破損したブロックは、事後対応型データ整合性チェックでは検出されません。
事前対応型データ整合性チェックを効果的に実行する方法の1つとして、RMANでVALIDATEまたはBACKUP VALIDATEコマンドを実行する方法があります。これらのコマンドによって、データファイルおよび制御ファイルに物理的な破損および論理的な破損がないかどうかを確認できます。RMANによってブロック破損が検出された場合、自動診断リポジトリにログが記録され、1つ以上の障害が作成されます。その後、データ・リカバリ・アドバイザを使用すると、これらの障害に関する情報を表示して、これらの障害を修復することができます。
データベースを検証する手順
RMANを起動し、ターゲット・データベースに接続します。ターゲット・データベースはマウントされている必要があります。
目的のデータベース・ファイルを検証します。
次の例では、VALIDATE DATABASEを使用して、データベース全体の物理的および論理的な破損を確認します(出力例も示します)。「障害の表示」には一部のデータファイルが消失していることが示されているため、SKIP INACCESSIBLE句が指定されています。出力には、system01.dbfデータベース・ファイルに1つの新しい破損ブロック(Blocks Failing)があり、以前にデータベースによって破損とマークされたブロック(Marked Corrupt)がないことが示されています。
RMAN> VALIDATE CHECK LOGICAL SKIP INACCESSIBLE DATABASE; Starting validate at 23-APR-07 allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=103 device type=DISK could not access datafile 28 skipping inaccessible file 28 RMAN-06060: WARNING: skipping datafile compromises tablespace USERS recoverability RMAN-06060: WARNING: skipping datafile compromises tablespace USERS recoverability channel ORA_DISK_1: starting validation of datafile channel ORA_DISK_1: specifying datafile(s) for validation input datafile file number=00001 name=/disk1/oradata/prod/system01.dbf input datafile file number=00002 name=/disk1/oradata/prod/sysaux01.dbf input datafile file number=00022 name=/disk1/oradata/prod/undotbs01.dbf input datafile file number=00023 name=/disk1/oradata/prod/cwmlite01.dbf input datafile file number=00024 name=/disk1/oradata/prod/drsys01.dbf input datafile file number=00025 name=/disk1/oradata/prod/example01.dbf input datafile file number=00026 name=/disk1/oradata/prod/indx01.dbf input datafile file number=00027 name=/disk1/oradata/prod/tools01.dbf channel ORA_DISK_1: validation complete, elapsed time: 00:00:25 List of Datafiles ================= File Status Marked Corrupt Empty Blocks Blocks Examined High SCN ---- ------ -------------- ------------ --------------- ---------- 1 FAILED 0 3536 57600 637711 File Name: /disk1/oradata/prod/system01.dbf Block Type Blocks Failing Blocks Processed ---------- -------------- ---------------- Data 1 41876 Index 0 7721 Other 0 4467 . . . File Status Marked Corrupt Empty Blocks Blocks Examined High SCN ---- ------ -------------- ------------ --------------- ---------- 27 OK 0 1272 1280 400914 File Name: /disk1/oradata/prod/tools01.dbf Block Type Blocks Failing Blocks Processed ---------- -------------- ---------------- Data 0 0 Index 0 0 Other 0 8 validate found one or more corrupt blocks See trace file /disk1/oracle/log/diag/rdbms/prod/prod/trace/prod_ora_2596.trc for details channel ORA_DISK_1: starting validation of datafile channel ORA_DISK_1: specifying datafile(s) for validation including current control file for validation including current SPFILE in backup set channel ORA_DISK_1: validation complete, elapsed time: 00:00:01 List of Control File and SPFILE =============================== File Type Status Blocks Failing Blocks Examined ------------ ------ -------------- --------------- SPFILE OK 0 2 Control File OK 0 512 Finished validate at 23-APR-07
|
関連項目:
|
RMANセッションでLIST FAILUREを実行した後、ADVISE FAILUREコマンドを使用して修復オプションを表示します。このコマンドによって、障害のサマリーが出力され、修復されているステータスがOPENのすべての障害がクローズされます。
必要に応じて、ADVISE FAILUREコマンドによって手動および自動の修復オプションのリストが表示されます。最初に、必須またはオプションのいずれかとしてカテゴリ化された手動オプションが表示されます。オプションの手動の修復によって、データファイルのリストアやリカバリなどの大規模な処理を回避できる場合もあります。通常は、データベースに及ぶ影響が最も少なく、エラーが発生する可能性が最も少ない修復手法を使用します。
1つ以上の障害が存在する場合は、通常、LIST FAILUREを使用して障害の情報を表示してから、同じRMANセッションでADVISE FAILUREを使用して修復オプションのレポートを取得します。
すべての障害に対する修復オプションを決定する手順
「すべての障害の表示」の説明に従って障害を表示します。
同じRMANセッションで、ADVISE FAILUREを実行します。
次の例では、データ・リカバリ・アドバイザで認識されるすべての障害に対する修復オプションを要求し、出力例(ページに収まるように形式が再設定されています)を示します。
RMAN> ADVISE FAILURE;
List of Database Failures
=========================
Failure ID Priority Status Time Detected Summary
---------- -------- --------- ------------- -------
142 HIGH OPEN 23-APR-07 One or more non-system datafiles
are missing
101 HIGH OPEN 23-APR-07 Datafile 1: '/disk1/oradata/prod/system01.dbf' contains one or more corrupt blocks
analyzing automatic repair options; this may take some time
using channel ORA_DISK_1
analyzing automatic repair options complete
Mandatory Manual Actions
========================
no manual actions available
Optional Manual Actions
=======================
1. If file /disk1/oradata/prod/users01.dbf was unintentionally renamed or moved, restore it
Automated Repair Options
========================
Option Repair Description
------ ------------------
1 Restore and recover datafile 28; Perform block media recovery of
block 56416 in file 1
Strategy: The repair includes complete media recovery with no data loss
Repair script: /disk1/oracle/log/diag/rdbms/prod/prod/hm/reco_660500184.hm
前述の例では、ADVISE FAILUREによって、欠落しているデータファイルおよび破損ブロックが含まれているデータファイルの2つの障害がレポートされています。このコマンドでは必須の手動処理は表示されませんが、欠落しているデータファイルの名前が誤って変更されていないこと、または欠落しているデータファイルが誤って削除されていないことを確認するように指示されています。この自動修復オプションは、ブロック・メディア・リカバリおよび欠落したデータファイルのリストアとリカバリに関連しています。ADVISE FAILUREでは、修復スクリプトの場所が表示されます。
次の類似した例では、自動修復に必要なRMANバックアップまたはアーカイブREDOログが利用できない場合の出力を示します。ADVISE FAILUREコマンドで、必須の手動処理が表示されます。
RMAN> ADVISE FAILURE;
List of Database Failures
=========================
Failure ID Priority Status Time Detected Summary
---------- -------- --------- ------------- -------
142 HIGH OPEN 23-APR-07 One or more non-system datafiles
are missing
101 HIGH OPEN 23-APR-07 Datafile 1: '/disk1/oradata/prod/system01.dbf' contains one or more corrupt blocks
analyzing automatic repair options; this may take some time
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=103 device type=DISK
analyzing automatic repair options complete
Mandatory Manual Actions
========================
1. If file /disk1/oradata/prod/users01.dbf was unintentionally renamed or moved, restore it
2. Contact Oracle Support Services if the preceding recommendations cannot be used, or if they do not fix the failures selected for repair
Optional Manual Actions
=======================
no manual actions available
Automated Repair Options
========================
Option Repair Description
------ ------------------
1 Perform block media recovery of block 56416 in file 1
Strategy: The repair includes complete media recovery with no data loss
Repair script: /disk1/oracle/log/diag/rdbms/prod/prod/hm/reco_1863891774.hm
「障害の修復」に進み、LIST FAILURE出力によって表示された障害の修復方法を決定します。
特定の障害に対する修復オプションを要求することもできます。障害は、ステータス(CRITICAL、HIGH、LOW)または障害番号で指定できます。EXCLUDE FAILUREを使用して、1つ以上の障害をレポートから除外することもできます。
障害のサブセットに対する修復オプションを決定する手順
「すべての障害の表示」の説明に従って障害を表示します。
同じRMANセッションで、必要なオプションを指定してADVISE FAILUREを実行します。
次の例では、障害101のみに対する修復オプションを要求します。
RMAN> ADVISE FAILURE 101; List of Database Failures ========================= Failure ID Priority Status Time Detected Summary ---------- -------- --------- ------------- ------- 101 HIGH OPEN 23-APR-07 Datafile 1: '/disk1/oradata/prod/system01.dbf' contains one or more corrupt blocks analyzing automatic repair options; this may take some time using channel ORA_DISK_1 analyzing automatic repair options complete Mandatory Manual Actions ======================== no manual actions available Optional Manual Actions ======================= no manual actions available Automated Repair Options ======================== Option Repair Description ------ ------------------ 1 Perform block media recovery of block 56416 in file 1 Strategy: The repair includes complete media recovery with no data loss Repair script: /disk1/oracle/log/diag/rdbms/prod/prod/hm/reco_708819503.hm
「障害の修復」に進み、LIST FAILUREコマンドによって表示された障害の修復方法を決定します。
|
関連項目: ADVISE FAILUREコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』 |
この項では、データ・リカバリ・アドバイザを使用して、障害を自動的に修復する方法について説明します。
ADVISE FAILUREで手動の修復が提示された場合は、これらの修復を最初に試行します。手動の修復が可能でない場合、または手動の修復ではすべての障害が修復されない場合は、REPAIR FAILUREを使用して、現行のRMANセッションでの最新のADVISE FAILUREコマンドで提示された障害の修復を自動的に実行することができます。
デフォルトでは、REPAIR FAILUREの実行を開始する前に確認を求められます。NOPROMPTオプションを指定して、確認のプロンプトが表示されないようにすることができます。コマンドの実行が開始されると、現行の修復フェーズが示されます。状況に応じて、RMANは、ユーザーに操作を求める場合があります。修復を実行した後、RMANは、この修復中に修復された可能性がある既存のすべての障害を再評価します。
通常は、修復を実行する前に、PREVIEWオプションを指定して修復をプレビューすることをお薦めします。RMANは、修復を行わず、すべての修復操作およびコメントが含まれているスクリプトを生成します。特定の修復オプションを指定しなかった場合、RMANは、現行セッションの最新のADVISE FAILUREコマンドの最初の修復オプションを使用します。デフォルトでは、修復スクリプトは標準出力に表示されます。SPOOLコマンドを使用すると、編集可能なファイルにスクリプトを書き込むことができます。
|
関連項目:
|
デフォルトでは、スクリプトは標準出力に表示されます。SPOOLコマンドを使用すると、編集可能なファイルにスクリプトを書き込むことができます。
障害を修復する手順
「すべての障害の表示」の説明に従って障害を表示します。
「修復オプションの決定」の説明に従って修復オプションを表示します。
必要に応じて、REPAIR FAILURE PREVIEWを実行します。
次の例では、RMANセッションの以前のADVISE FAILUREコマンドによって表示された最初の修復オプションをプレビューします。
RMAN> REPAIR FAILURE PREVIEW; Strategy: The repair includes complete media recovery with no data loss Repair script: /disk1/oracle/log/diag/rdbms/prod/prod/hm/reco_475549922.hm contents of repair script: # restore and recover data file sql 'alter database datafile 28 offline'; restore datafile 28; recover datafile 28; sql 'alter database datafile 28 online'; # block media recovery recover datafile 1 block 56416;
REPAIR FAILUREを実行します。
次の修復では、1つのデータファイルをリストアおよびリカバリし、1つの破損ブロックでブロック・メディア・リカバリを実行します。RMANによって、修復を行うかどうかの確認が求められます。ユーザーが入力したテキストは太字で示されています。
RMAN> REPAIR FAILURE;
Strategy: The repair includes complete media recovery with no data loss
Repair script: /disk1/oracle/log/diag/rdbms/prod/prod/hm/reco_475549922.hm
contents of repair script:
# restore and recover data file
sql 'alter database datafile 28 offline';
restore datafile 28;
recover datafile 28;
sql 'alter database datafile 28 online';
# block media recovery
recover datafile 1 block 56416;
Do you really want to execute the above repair (enter YES or NO)? YES
executing repair script
sql statement: alter database datafile 28 offline
Starting restore at 23-APR-07
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00028 to /disk1/oradata/prod/users01.dbf
channel ORA_DISK_1: reading from backup piece /disk2/PROD/backupset/2007_04_18/o1_mf_nnndf_TAG20070418T182042_32fjzd3z_.bkp
channel ORA_DISK_1: piece handle=/disk2/PROD/backupset/2007_04_18/o1_mf_nnndf_TAG20070418T182042_32fjzd3z_.bkp tag=TAG20070418T182042
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
Finished restore at 23-APR-07
Starting recover at 23-APR-07
using channel ORA_DISK_1
starting media recovery
media recovery complete, elapsed time: 00:00:01
Finished recover at 23-APR-07
sql statement: alter database datafile 28 online
Starting recover at 23-APR-07
using channel ORA_DISK_1
searching flashback logs for block images until SCN 429690
finished flashback log search, restored 1 blocks
starting media recovery
media recovery complete, elapsed time: 00:00:03
Finished recover at 23-APR-07
repair failure complete
必要に応じて、LIST FAILUREを実行して確認します。
CHANGE FAILUREコマンドを使用して、障害のステータスまたは優先順位を変更する必要がある場合もあります。たとえば、ブロックの破損の優先順位がHIGHで、そのブロックがほとんど使用されない表領域に存在する場合は、そのブロックの破損の優先順位を一時的にLOWに変更できます。
REPAIR FAILUREコマンド以外の方法で障害を修復すると、次回LIST FAILUREを実行した場合、データ・リカバリ・アドバイザはこの障害を暗黙的にクローズします。このため、通常はCHANGE FAILURE ... CLOSEDコマンドを実行する必要はありません。このコマンドは、自動障害再検証が正常に実行されなかったにもかかわらず、障害は存在していないと確信できる場合にのみ使用する必要があります。CHANGE FAILUREを使用して、存在したままになっている障害をクローズすると、データ・リカバリ・アドバイザは、適切なデータ整合性チェックを実行する際に別の障害IDでこの障害を再作成します。
通常、障害は障害番号で指定します。ALL、CRITICAL、HIGHまたはLOWを指定して、障害を一括で変更することもできます。障害は、CLOSED、PRIORITY HIGHまたはPRIORITY LOWに変更できます。
障害のステータスまたは優先順位を変更する手順
「すべての障害の表示」の説明に従って障害を表示します。
次の例は、破損データ・ブロックが含まれている1つの障害を示しています。
RMAN> LIST FAILURE;
List of Database Failures
=========================
Failure ID Priority Status Time Detected Summary
---------- -------- --------- ------------- -------
142 HIGH OPEN 23-APR-07 One or more non-system datafiles
are missing
101 HIGH OPEN 23-APR-07 Datafile 25: '/disk1/oradata/prod/example01.dbf' contains one or more corrupt blocks
必要なオプションを使用してCHANGE FAILUREを実行します。
次の例では、ブロックの破損障害の優先順位をHIGHからLOWに変更します。
RMAN> CHANGE FAILURE 101 PRIORITY LOW;
List of Database Failures
=========================
Failure ID Priority Status Time Detected Summary
---------- -------- --------- ------------- -------
101 HIGH OPEN 23-APR-07 Datafile 25: '/disk1/oradata/prod/example01.dbf' contains one or more corrupt blocks
Do you really want to change the above failures (enter YES or NO)? YES
changed 1 failures to LOW priority
必要に応じて、LIST FAILURE ALLを実行して変更内容を表示します。
ALLを指定せずにLIST FAILUREを実行すると、CRITICALまたはHIGHの優先順位の障害が存在しない場合にのみ、LOWの優先順位の障害が表示されます。
RMAN> LIST FAILURE ALL;
List of Database Failures
=========================
Failure ID Priority Status Time Detected Summary
---------- -------- --------- ------------- -------
142 HIGH OPEN 23-APR-07 One or more non-system datafiles
are missing
101 LOW OPEN 23-APR-07 Datafile 25: '/disk1/oradata/prod/example01.dbf' contains one or more corrupt blocks
|
関連項目: CHANGEコマンドの詳細は、『Oracle Databaseバックアップおよびリカバリ・リファレンス』 |
