1. Broker
  2. Oracle Data Guardのトラブルシューティング

9 Oracle Data Guardのトラブルシューティング

一般的な問題および解決策に関するこの情報を使用して、Oracle Data Guard環境を維持します。

9.1 診断情報のソース

Oracle Data Guard Brokerのアクティビティに関する情報は、次の形式で提供されます。

  • データベース・ステータス情報(「データベース・ステータス」を参照)

  • Oracleアラート・ログ・ファイル

    ブローカでは、ブローカ構成に含まれる各データベースのインスタンスごとのアラート・ログ・ファイルに重要情報が記録されます。Oracle Data Guardをトラブルシューティングする場合は、このような情報のアラート・ログ・ファイルを確認できます。

  • Oracle Data Guardのブローカ・ログ・ファイル

    ブローカ構成に含まれる各データベースのインスタンスごとに、ブローカのDMONプロセスにより重要な動作およびステータス情報がブローカ・ログ・ファイルに記録され、このファイルは、Oracle Data Guardの障害を診断する際に役立ちます。TraceLevel構成プロパティ(「TraceLevel」を参照)は、ブローカ・ログ・ファイルで報告される診断情報のレベルを指定するために使用されます。

    ブローカ・ログ・ファイルは、アラート・ログと同じディレクトリに作成され、drc<$ORACLE_SID>.logという名前が付けられます。

9.2 一般的な問題と解決策

次のトピックでは、Oracle Data Guard Brokerを使用する際の一般的な問題と解決策について説明します。

9.2.1 ORA-16596: データベースがOracle Data Guard Broker構成に含まれていない

ブローカに対して要求が発行されましたが、接続に使用するデータベース・インスタンスはブローカ構成に含まれていません。

解決策

ブローカ構成に含まれている他のデータベースを介して構成に再接続してください。ORA-16596エラーを戻したデータベースのdb_unique_name値と名前が一致するデータベースがブローカ構成に存在することを確認してください。

構成を有効化しようとして、そのデータベースの1つのブローカ構成ファイルが意図せずに削除されていた場合や陳腐化している場合にも、この問題が発生することがあります。その場合は、データベースをブローカ構成から削除し、(プライマリ・データベースではなく)そのスタンバイ・データベースの構成ファイルを手動で削除してから、構成の有効化を再試行してください。構成が有効化された後は、Cloud Controlのスタンバイ・データベースの追加ウィザードを使用して「既存のスタンバイ・データベースの追加」オプションを選択するか、DGMGRLコマンドライン・インタフェースを使用してADD DATABASE コマンドを発行できます。

9.2.2 プライマリ・データベースに累積されたREDOが一部のスタンバイ・データベースに送信されない場合

Cloud Controlの「ログ・ファイルの詳細」ページを表示すると、ログ・ファイルがプライマリ・データベースに累積され、ブローカ構成内の一部のスタンバイ・データベースにアーカイブされていないことがわかります。

解決策

問題を絞り込むには、次の手順を実行します。

  • プライマリ・データベースの状態が(TRANSPORT-OFFではなく)TRANSPORT-ONであることを確認します。

  • 問題のスタンバイ・データベースのデータベース・プロパティLogShippingの値がONであることを確認します。

  • 監視可能なプロパティLogXptStatusを使用して、プライマリ・データベースのREDO転送サービスのステータスをチェックします。REDO転送サービスにエラーがある場合は、エラー・メッセージを参考にして詳細なチェックおよび解決処置を判断します。次に例を示します。

    • スタンバイ・データベースが使用不可能であることをエラーが示している場合は、スタンバイ・データベースを再起動する必要があります。

    • リスナーが存在しないことをエラーが示している場合は、リスナーを再起動する必要があります。

    • スタンバイ・データベースにローカルの宛先がないことをエラーが示している場合は、プライマリ・データベースからのアーカイブREDOログ・ファイルを格納するスタンバイ位置を設定する必要があります。

9.2.3 スタンバイ・データベース上で多数のログ・ファイルが受信されるが適用されない場合

Cloud Controlの「パフォーマンス」ページまたは「ログ・ファイルの詳細」ページを表示すると、スタンバイ・データベースに適用されないまま累積しているログ・ファイルが多すぎることがわかります。

解決策

アーカイブREDOログ・ファイルがスタンバイ・データベースに適用されない場合は、様々な原因が考えられます。ログ・ファイルが累積されている原因を調べて、妥当な理由を排除してください。

スタンバイ・データベースの現在のステータスが正常でない場合

  • ログ適用サービスが予期せず停止しているかどうかを判別します。詳細は、ORA-16766(フィジカル・スタンバイ・データベースの場合)またはORA-16768(ロジカル・スタンバイ・データベースの場合)のエラーの説明と解決策を参照してください。

  • これがロジカル・スタンバイ・データベースの場合は、障害トランザクションが発生したかどうかを確認します。

  • 問題の調査中にエラーを抑止する場合は、データベースのブローカ管理を一時的に無効化できます。

    関連項目:

    DGMGRLコマンドライン・インタフェースを使用してデータベースを無効化する方法の詳細は、「Oracle Data Guardコマンドライン・インタフェース・リファレンス」を参照してください

スタンバイ・データベースの現在のステータスが正常な場合

  • スタンバイ・データベースの状態が(APPLY-OFFではなく)APPLY-ONであることを確認します。

  • プライマリ・データベースの状態が(TRANSPORT-OFFではなく)TRANSPORT-ONであることを確認します。

    関連項目:

    データベース・プロパティLogShippingの詳細は、「Oracle Data Guard Brokerのプロパティ」を参照してください

  • ログ・ファイルが累積されている原因が、DelayMinsプロパティの設定値が大きすぎるためかどうかを調べます。(ログ適用サービスでは、スタンバイ・データベースへのアーカイブREDOログ・ファイルの適用が、指定した時間(分)だけ遅延されます。)

    関連項目:

    データベース・プロパティDelayMinsの詳細は、「Oracle Data Guard Brokerのプロパティ」を参照してください

  • 何もエラーが表示されない場合は、Cloud Controlの「パフォーマンス」ページでアーカイブ率を適用率と比較して、適用率がアーカイブ率より低いかどうかを調べます。

9.2.4 要求がタイムアウトしたか、Cloud Controlのパフォーマンスが低い場合

ブローカの要求が通常のタイムアウト・パラメータ内に完了しない場合、次の処置を試行して問題を解決します。

  1. ネットワークが適切に動作しているかどうか確認します。

  2. 構成内のすべてのノードに対してpingを試行します。

  3. 他のデータベースにより再接続を試行し、操作を再試行します。

  4. VERIFYコマンドを実行し、ブローカが要求を処理できないデータベースを特定します。

9.2.5 プライマリ・データベースがフラッシュバックされる場合

プライマリ・データベースがフラッシュバックされる場合、構成内のスタンバイ・データベースも、スイッチオーバーまたはフェイルオーバーの実行可能なターゲットとなるように、フラッシュバックまたは再作成される必要があります。

プライマリ・データベースがフラッシュバックされた場合、ブローカによりスタンバイ・データベースのエラーがレポートされます。

ブローカにより無効化されたスタンバイ・データベースの実行可能性をリストアする方法の詳細は、「ロール変更後の無効化されたデータベースの再有効化」を参照してください。

9.2.6 不明なサービスのためにスタンバイが自動開始できない場合(ORA-12514)

DGMGRL CLIがブローカ操作(たとえば、スイッチオーバー、回復、またはフィジカル・スタンバイへの変換)の後にインスタンスの自動起動に失敗した場合、ORA-12514エラーが生成される場合があります。

完全なエラー・テキストは、ORA-12514: TNS: リスナーは接続記述子でリクエストされたサービスを現在認識していませんです。このエラーが発生し、データベースがOracle Clusterwareによって管理されていない場合は、インスタンスを手動で起動して、ブローカ操作を完了または続行する必要があります。

ノート:

この項のトラブルシューティング情報は、Oracle Clusterwareで管理されていないデータベースにのみ適用されます。

次のステップを完了する前か後に、インスタンスを再起動できます。

  1. 次のDGMGRL CLIコマンドを発行して、DGMGRL CLIが再起動できなかったインスタンスの構成可能なプロパティStaticConnectIdentiferの値を確認します。(このコマンドを発行するには、実行中の別のインスタンスに接続する必要があります) 

    SHOW DATABASE db_unique_name StaticConnectIdentifier;

  2. StaticConnectIdentiferインスタンス・プロパティの値で指定されている静的サービス名は、プロパティ値で指定されているリスナーに登録されている必要があります。静的サービス名のデフォルト値は、次の形式をとります。 

    db_unique_name_DGMGRL.db_domain

    ブローカを使用するための、これを含む様々な前提条件の詳細は、「前提条件」を参照してください。

  3. リスナー制御ユーティリティのステータス・コマンドを使用して、静的サービス名が、構成可能なプロパティStaticConnectIdentiferの値で指定されたリスナーに登録されていることを確認します。静的サービス名が正しくリスナーに登録されている場合、次のコマンドで生成される出力に含まれます。 

    lsnrctl status

9.3 スイッチオーバー操作時の問題のトラブルシューティング

構成に問題があるためにスイッチオーバーに失敗すると、ブローカにより検出された問題はアラート・ログ・ファイルまたはブローカ・ログ・ファイルでレポートされます。

ログ・ファイルの詳細は、診断情報のソースを参照してください。報告された問題が修正できる場合、スイッチオーバー操作を再試行でき、それは通常成功します。報告された問題が修正できないか、修正した後でもスイッチオーバー操作が失敗する場合、スイッチオーバー用に別のデータベースを選択するか、または構成をスイッチオーバー前の状態にリストアしてから、スイッチオーバーを再試行できます。

ファスト・スタート・フェイルオーバーが有効化されている場合、ブローカでは、ターゲット・スタンバイ・データベース以外のどのスタンバイ・データベースにもスイッチオーバーを実行できません。さらに、ターゲット・スタンバイ・データベースへのスイッチオーバーは、ターゲット・スタンバイ・データベースのV$DATABASEビュー内のFS_FAILOVER_STATUS列の値が、READYまたはSUSPENDEDのいずれかである場合にのみ可能です。

関連項目:

ファスト・スタート・フェイルオーバーの有効化およびオブザーバの実行

9.4 フェイルオーバー操作時の問題のトラブルシューティング

フェイルオーバー操作を停止することは可能ですが、これはお薦めしません。エラーが発生した場合は、ガイドラインに従って問題を修正してから、Brokerフェイルオーバーを再試行します。

9.4.1 フィジカル・スタンバイ・データベースへのフェイルオーバーの失敗

次の各ステップで、フィジカル・スタンバイ・データベースへのブローカのフェイルオーバーの失敗からリカバリする方法を説明します。

9.4.1.1 ブローカの完全フィジカル・フェイルオーバーの失敗

ターゲット・スタンバイ・データベースでアラート・ログ・ファイルおよびブローカ・ログ・ファイル(drc*.log)を調べて、失敗した原因を確認し、それを修正します。

報告された問題が修正できる場合、スイッチオーバー操作を再試行します。報告された問題が修正できないか、報告された問題を修正した後でもフェイルオーバー操作がまだ失敗する場合、次のステップを実行します。

  1. ターゲット・スタンバイ・データベースに接続し、ファスト・スタート・フェイルオーバーが有効な場合はFORCEオプションを使用して無効化します。

  2. 次のどちらかの操作を実行します。

    • 別のフィジカル・スタンバイ・データベースに接続して、ブローカの完全フェイルオーバーを実行します。

    • ターゲット・フィジカル・スタンバイ・データベースへのブローカの即時フェイルオーバーを実行します。

  3. 元のプライマリ・データベースと、回復を要求するステータス(ORA-16661)を持つその他の無効なフィジカル・スタンバイ・データベースを回復します。

  4. ファスト・スタート・フェイルオーバーがステップ1で無効化された場合は、再び有効化します。

9.4.1.2 ブローカの即時フィジカル・フェイルオーバーの失敗

ターゲット・スタンバイ・データベースでアラート・ログ・ファイルおよびブローカ・ログ・ファイル(drc*.log)を調べて、失敗した原因を確認し、それを修正します。

問題が修正可能な場合は、ブローカの即時フェイルオーバーを再試行します。それ以外の場合は、別のフィジカル・スタンバイ・データベースに接続して、ブローカの完全フェイルオーバーまたは即時フェイルオーバーを実行します。

9.4.2 ロジカル・スタンバイ・データベースへのフェイルオーバーの失敗

ロジカル・スタンバイ・データベースへのフェイルオーバーが失敗した場合に従うステップは、次のとおりです。

  1. ターゲット・スタンバイ・データベースでアラート・ログ・ファイルおよびブローカ・ログ・ファイル(drc*.log)を調べて、失敗した原因を確認し、それを修正します。

  2. ターゲット・スタンバイ・データベースに接続し、ファスト・スタート・フェイルオーバーが有効な場合はFORCEオプションを使用して無効化します。

  3. ブローカのフェイルオーバーを再試行します。

  4. 元のプライマリ・データベースを回復します。その他のスタンバイ・データベースはすべて、新規プライマリ・データベースのコピーから再作成されます。

  5. ファスト・スタート・フェイルオーバーがステップ1で無効化された場合は、再び有効化します。

ブローカのフェイルオーバーが引き続き失敗する場合は、Oracle Data Guard構成ですべてのデータベース上のブローカを停止します(DG_BROKER_START初期化パラメータをFALSEに設定します)。すべてのデータベースからOracle Data Guard Broker構成ファイルを削除します。『Oracle Data Guard概要および管理』のロール遷移に関するガイドラインを使用して、手動フェイルオーバーを実行します。

ノート:

DGMGRLのENABLE CONFIGURATIONおよびDISABLE CONFIGURATIONコマンドを使用すると、ブローカ構成を有効化または無効化できます。Cloud Controlを使用して構成を無効化することはできません。前にDGMGRLを使用して無効化した構成は、Cloud Controlを使用してのみ有効化できます。

9.5 オブザーバに関する問題のトラブルシューティング

オブザーバは、継続的にファスト・スタート・フェイルオーバー環境を監視して、プライマリ・データベースが使用可能であることを確認します。

オブザーバのインストールおよび起動は、ファスト・スタート・フェイルオーバーの使用における必須部分です。次の各項で、オブザーバのトラブルシューティング方法について説明します。

9.5.1 オブザーバが停止したことによる問題

オブザーバのホスト・マシンがクラッシュした場合、ブローカ構成は監視されなくなり、ファスト・スタート・フェイルオーバーは実行できなくなります。

この場合、元のホスト・マシンを適時に修復できないときは、オブザーバを新しいホストに移動する必要があります。

  1. DGMGRLのSTOP OBSERVERコマンドを発行し、元のオブザーバとブローカ構成の間のリンクを切り離します。 

    DGMGRL> STOP OBSERVER;
Done.

  2. DGMGRLの SHOW CONFIGURATION VERBOSEコマンドを発行し、構成が監視されていないことを確認します。 

    DGMGRL> SHOW CONFIGURATION VERBOSE;
 
Configuration - DRSolution
 
  Protection Mode: MaxAvailability
  Members:
    North_Sales - Primary database
    Warning: ORA-16819: fast-start failover observer not started
 
    South_Sales - (*) Physical standby database
    Warning: ORA-16819: fast-start failover observer not started
 
(*) Fast-Start Failover target
 
Properties:
  FastStartFailoverThreshold     = '30'
  OperationTimeout               = '30'
  TraceLevel                     = 'USER'
  FastStartFailoverLagLimit      = '30'
  CommunicationTimeout           = '180'
  ObserverReconnect              = '0'
  FastStartFailoverAutoReinstate = 'TRUE'
  FastStartFailoverPmyShutdown   = 'TRUE'
  BystandersFollowRoleChange     = 'ALL'
  ObserverOverride               = 'FALSE'
  ExternalDestination1           = ''
  ExternalDestination2           = ''  
  PrimaryLostWriteAction         = 'CONTINUE'
  ConfigurationWideService       = 'North_Sales_CFG' 

Fast-Start Failover: ENABLED
 
  Threshold: 30 seconds
  Target: South_Sales
  Observer: observer.example.com
  Lag Limit: 30 seconds (not in use)
  Shutdown Primary: TRUE
  Auto-reinstate: TRUE
  Observer Reconnect: (none)
  Observer Override: FALSE
 
Configuration Status:
WARNING

  3. オブザーバが実際に停止していることを確認する際に、DGMGRLのSHOW CONFIGURATIONコマンドを発行する必要はないので注意してください。DGMGRLのSTOP OBSERVERコマンドを正常に完了すると、新規オブザーバを構成に関連付けることが可能になります。

9.5.2 オブザーバ・ログ・ファイルでのオブザーバの処理の取得

START OBSERVERコマンドのLOGFILE ISオプションを使用すると、オブザーバによって実行されたアクティビティを取得できます。

次に例を示します。

% dgmgrl START OBSERVER observer1 IN BACKGROUND LOGFILE IS observer.log CONNECT IDENTIFIER IS North_Sales TRACE_LEVEL IS SUPPORT;

オブザーバの出力はすべて、DGMGRLコマンドを発行した現在の作業ディレクトリ内のobserver.logファイルに記録されます。指定したログにアクセスできない場合、ログ・ファイルが指定されていない場合と同様に、オブザーバーの出力が標準出力に送信されます。