My Oracle Support Banner

フィジカルスタンバイデータベースで MRP が動作しない問題を解決する方法 (Doc ID 2207872.1)

Last updated on OCTOBER 23, 2020

適用範囲:

Oracle Database - Enterprise Edition - バージョン 10.1.0.2 から 12.1.0.2 [リリース 10.1 から 12.1]
Oracle Database Cloud Schema Service - バージョン N/A 以降
Oracle Database Exadata Express Cloud Service - バージョン N/A 以降
Gen 1 Exadata Cloud at Customer (Oracle Exadata Database Cloud Machine) - バージョン N/A 以降
Oracle Cloud Infrastructure - Database Service - バージョン N/A 以降
この文書の内容はすべてのプラットフォームに適用されます。
本文書利用上のご注意
  本文書は英語の文書 <Document 1221163.1> (最終メジャー更新日: 2016年10月18日) の日本語翻訳版です。
  英語の文書のメジャー更新に応じて本文書を随時更新いたします。


目的

grid control からフィジカルスタンバイデータベースにおいて適用済みの sequence# が増加しないことに気付いた時、または MRP (Managed Recovery Process) が動作せず、ログを適用しない場合、フィジカルスタンバイデータベースをプライマリ・データベースと同期させるために、問題の原因を突き止めて、問題を解決するにはどうすればよいですか。

一般的には、次の手順を実行してください:

  1. MRP が適用中のアーカイブログファイルを見つけるには、次のいずれかの方法を使用してください。

a. MRP が起動していれば、スタンバイデータベースで v$managed_standby を検索して下さい。

 

% ps -ef |grep -i mrp 
SQL>select process, thread#, sequence#, status from v$managed_standby where process='MRP0';
PROCESS  THREAD#   SEQUENCE#  STATUS
-------- --------- ---------- ------------

MRP0     1         548        WAIT_FOR_GAP

注: 12.2 以降では、v$managed_standby の代わりに V$DATAGUARD_PROCESS ビューを使用してください。
 

b. 管理リカバリを停止し、手動のリカバリを開始してください。

SQL>recover managed standby database cancel;
SQL>recover automatic standby database;

もし、Data Guard Broker を使用していれば、DGMGRL または grid control より行う必要があります。

11g の Data Guard Broker の場合

DGMGRL> EDIT DATABASE '<standby db_unique_name>' SET STATE='APPLY-OFF';
DGMGRL> EDIT DATABASE '<standby db_unique_name>' SET STATE='APPLY-ON';

 


スタンバイが RAC データベースの場合
DGMGRL> EDIT DATABASE '<standby db_unique_name>' SET STATE='APPLY-ON' WITH APPLY INSTANCE = <instance-name>;

 
<instance-name> は、適用インスタンスにするインスタンスの名前です。

10g の Data Guard Broker の場合

DGMGRL> EDIT DATABASE '<standby db_unique_name>' SET STATE='LOG-APPLY-OFF'; DGMGRL> EDIT DATABASE '<standby db_unique_name>' SET STATE='ONLINE';


スタンバイが RAC データベースの場合

DGMGRL> EDIT DATABASE '<standby db_unique_name>' SET STATE='ONLINE' WITH APPLY INSTANCE = <instance-name>;

10g および 11g のスタンバイデータベースのスタンバイデータベースの状態を grid control から変更するには、次の手順を実行します。

1. Data Guard Overview ページより変更したいスタンバイデータベースを選択します。
2. 編集をクリックして、プロパティの編集ページに移動します。
3. ログ適用オフ (またはオンライン) を選択します。
4. 適用をクリックします。
5. 処理が完了すると、成功を示すメッセージが返されます。


9i の Data Guard Broker の場合

DGMGRL> ALTER RESOURCE '<resource name>' ON SITE '<site name>' SET STATE='PHYSICAL-APPLY-READY';
DGMGRL> ALTER RESOURCE '<resource name>' ON SITE '<site name>' SET STATE='PHYSICAL-APPLY-ON';

9i のスタンバイデータベースのスタンバイデータベースの状態を grid control から変更するには、次の手順を実行します。

1. ナビゲータ・ツリーで、スタンバイデータベースリソースを選択します。
2. 右側のプロパティシートで、Set State をクリックします。
3. Apply Off (またはOnline) をクリックします。
4. OK をクリックします。


c. データファイルのヘッダーで最も低い checkpoint_change# を使用して、復旧に必要なアーカイブログを探します。

SQL>select min(fhscn),fhrba_Seq SEQUENCE from x$kcvfh group by fhrba_Seq;


  2. 手順 1 で見つかったアーカイブログファイルがスタンバイサイトのスタンバイ初期化パラメータ standby_archive_dest または standby_archive_dest がスタンバイで定義されていない場合は log_archive_dest_1 で指定された場所に存在するかどうかを確認します。

もしあれば、プライマリにあるものと同じサイズのものがスタンバイにあるかどうかを cksum コマンドで比較してください。例.

% cksum <archive log file full path/file name>
  

注:unix プラットフォームで cksum が利用できない場合は、SHA-1 や MD5 チェックサムユーティリティなど、より多くのコマンドを提供する以下のドキュメントを参照してください。

Note 549617.1 How To Verify The Integrity Of A Patch/Software Download?

  

また、スタンバイサイトまたはプライマリサイトでアーカイブログファイルが破損しているかどうかを確認することもできます。

SQL>alter system dump logfile '<full path/archive log file name>' validate;


SQL プロンプトがエラーなしに戻った場合、アーカイブログファイルは破損していません。

  3. 手順 1 のアーカイブログファイルがスタンバイに存在しないか、破損している場合は、プライマリサイトから新しいコピーを取得する必要があります。 ギャップを手動で解決する方法については、以下の文書を参照してください。

 <Note 1537316.1> Data Guard Gap Detection and Resolution Possibilities


  4. アーカイブログファイルがスタンバイサイトに存在し、破損していない場合は、v$archived_log を問い合せてスタンバイ制御ファイルに登録されているかどうかを確認してください。 例.

SQL>select name from v$archived_log where (thread#=1 and sequence#=192917) or (thread#=2 and sequence#=26903);


スレッド 1 の最後に適用された sequence# が 192916 であり、スレッド 2 の最後に適用された sequence# が 26902 の場合です。または thread# と sequence# は、MRP がとどまるステップ 1 のものです。
アーカイブログファイル名が上記のクエリから戻ってきた場合、それらはスタンバイ制御ファイルに登録されています。 そうでなければ、スタンバイ制御ファイルはそれらを認識しません。

 

2. 転送の遅れや適用の遅れがあるかどうかを判断するため、以下のクエリを使用して、各スレッドのプライマリの現在の sequence#、スタンバイの最後の受信 sequence#、および各スレッドのスタンバイの最後に適用されたsequence# を確認して、スタンバイが同期しているかどうかを確認してください


<Note 290817.1> Rolling a Standby Forward using an RMAN Incremental Backup in 9i
<Note 836986.1> Steps to perform for Rolling forward a standby database using RMAN incremental backup when primary and standby are in ASM filesystem

解決策

To view full details, sign in with your My Oracle Support account.

Don't have a My Oracle Support account? Click to get started!


本書の内容
目的
解決策
 原因 1 : ログ転送の問題
 解決策 1 : cksum コマンドを使用して、プライマリサイトとスタンバイサイトのパスワー・ファイルのサイズを確認してください。また、11g 以上のデータベースで SEC_CASE_SENSITIVE_LOGON が false に設定されていることを確認してください。
 原因 2 : ファイアウォールが部分的なアーカイブログの転送の原因となります。
 
解決策 2: 以下のファイアウォールの機能が無効になっていることを確認してください。
 原因 3 : bug 6113783 のため、ネットワークハートビートを担当するプライマリの ARC プロセスが動作できなくなります。
 解決策 3 : bug 6113783 は 11.2.0.2 で修正されました。プライマリデータベースの arch プロセスを kill することで問題に対処することが可能です。
 原因 4 : スタンバイのリカバリが、スタンバイに適用済みの古い sequence # を要求します。
 解決策 4 : bug 6029179 の修正を適用するか、プライマリが RAC データベースであれば、プライマリの各インスタンスのハートビート arch プロセスを kill してください。
 原因 5 誤った場所からのリカバリ
 解決策 5 フィジカルスタンバイ上で standby_archive_dest を log_archive_dest_1 と同じ場所に指定してください。手動でのリカバリ句で from 'location' 属性を使用してください。
 原因 6 : スタンバイデータベースで全てのスタンバイ REDO ログがアクティブです。
 
解決策 6 : アーカイブ先に十分なスペースがあることを確認してください。
log_archive_dest_1 が適切な valid_for 値と db_unique_name で定義されています。
standby_archive_dest は正しく指定されています。
 
原因 7 : スタンバイデータベース上で、部分的なアーカイブログファイルが適用されています。
 解決策 7 : フィジカルスタンバイデータベースをロールフォワードするため、RMAN の増分バックアップを使用します。
 
原因 8 : アーカイブログファイルは Data Guard ログ転送サービスではなく、手動でスタンバイに転送されました。
 
解決策 8 : アーカイブログファイルを Register するか、手動のリカバリを使用してください。
 原因 9 : 転送、スタンバイに適用される前にプライマリよりアーカイブログファイルが削除されます。
 解決策 9 : バックアップよりアーカイブログファイルをリストアし、register してリカバリするために管理リカバリを使用します。または、register をせずに手動のリカバリを使用します。
 原因 10 : プライマリに新しいデータファイルが追加されますが、スタンバイに自動的に追加されません。
 解決策 10 : スタンバイデータベースに手動で新しいデータファイルを追加します。
 原因 11 : スタンバイで制御ファイルの競合が発生した後、MRP がストールする可能性があります。
 解決策 11 : 10.2.0.4 で修正されます。回避策はスタンバイの再起動です。
 原因 12 : 管理リカバリのキャンセルがハングします。
 解決策 12 : スタンバイを shutdown abort し、startup mount します。そして、クリーンな shutdown を行い、スタンバイに残っているサーバプロセスがあるかを確認してください。
参照情報

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.