| Oracle® Data Guard Broker 11gリリース2 (11.2) B56304-09 |
|
 前 |
 次 |
この章では、様々なエラーとその解決方法について説明します。この章の内容は、次のとおりです。
Data Guard Brokerのアクティビティに関する情報は、次の形式で提供されます。
データベース・ステータス情報(4.9項を参照)
Oracleアラート・ログ・ファイル
ブローカでは、ブローカ構成に含まれる各データベースのインスタンスごとのアラート・ログ・ファイルに重要情報が記録されます。Data Guardのトラブルシューティング時には、このアラート・ログ・ファイル内の情報をチェックできます。
ブローカ構成に含まれる各データベースのインスタンスごとに、ブローカのDMONプロセスにより重要な動作およびステータス情報がブローカ・ログ・ファイルに記録されます。このファイルは、Data Guardの障害を診断する際に役立ちます。
ブローカ・ログ・ファイルは、アラート・ログと同じディレクトリに作成され、drc<$ORACLE_SID>.logという名前が付けられます。
この項では、一般的な問題と解決策について説明します。この項の内容は、次のとおりです。
ブローカに対して要求が発行されましたが、接続に使用するデータベース・インスタンスはブローカ構成に含まれていません。ブローカが実行中のデータベースのブローカ構成プロファイルを検出できない場合に、このエラーが表示されることがあります。
解決策 ブローカ構成に含まれている他のデータベースを介して構成に再接続してください。ORA-16596エラーを戻したデータベースのdb_unique_name値と名前が一致するデータベースがブローカ構成に存在することを確認してください。
構成を有効化しようとして、そのデータベースの1つのブローカ構成ファイルが意図せずに削除されていた場合や陳腐化している場合にも、この問題が発生することがあります。その場合は、データベースをブローカ構成から削除し、(プライマリ・データベースではなく)そのスタンバイ・データベースの構成ファイルを手動で削除してから、構成の有効化を再試行してください。構成が有効化された後、前に削除したスタンバイ・データベースの新しいデータベース・プロファイルを作成するには、Enterprise Managerのスタンバイ・データベースの追加ウィザードを使用し、「既存のスタンバイ・データベースの追加」オプションを選択するか、DGMGRLコマンドライン・インタフェースを使用し、ADD DATABASEコマンドを発行します。
Enterprise Managerの「ログ・ファイルの詳細」ページを表示すると、ログ・ファイルがプライマリ・データベースに累積され、ブローカ構成内の一部のスタンバイ・データベースにアーカイブされていないことがわかります。
解決策 問題を絞り込むには、次の操作を実行します。
プライマリ・データベースの状態が(TRANSPORT-OFFではなく)TRANSPORT-ONであることを確認します。
問題のスタンバイ・データベースのデータベース・プロパティLogShippingの値がONであることを確認します。
監視可能なデータベース・プロパティLogXptStatusを使用して、プライマリ・データベースのREDO転送サービスのステータスをチェックします。REDO転送サービスにエラーがある場合は、エラー・メッセージを参考にして詳細なチェックおよび解決処置を判断します。次に例を示します。
スタンバイ・データベースが使用不可能であることをエラーが示している場合は、スタンバイ・データベースを再起動する必要があります。
リスナーが存在しないことをエラーが示している場合は、リスナーを再起動する必要があります。
スタンバイ・データベースにローカルの宛先がないことをエラーが示している場合は、プライマリ・データベースからのアーカイブREDOログ・ファイルを格納するスタンバイ位置を設定する必要があります。
Enterprise Managerの「パフォーマンス」ページまたは「ログ・ファイルの詳細」ページを表示すると、スタンバイ・データベースに適用されないまま累積しているログ・ファイルが多すぎることがわかります。
解決策 アーカイブREDOログ・ファイルがスタンバイ・データベースに適用されない場合は、様々な原因が考えられます。ログ・ファイルが累積されている原因を調べて、妥当な理由を排除してください。
スタンバイ・データベースの現在のステータスが正常でない場合
ログ適用サービスが予期せず停止しているかどうかを判別します。詳細は、ORA-16766(フィジカル・スタンバイ・データベースの場合)またはORA-16768(ロジカル・スタンバイ・データベースの場合)のエラーの説明と解決策を参照してください。
これがロジカル・スタンバイ・データベースの場合は、障害トランザクションが発生したかどうかを確認します。
問題の調査中にエラーを抑止する場合は、データベースのブローカ管理を一時的に無効化できます。
スタンバイ・データベースの現在のステータスが正常な場合
スタンバイ・データベースの状態が(APPLY-OFFではなく)APPLY-ONであることを確認します。
プライマリ・データベースの状態が(TRANSPORT-OFFではなく)TRANSPORT-ONであることを確認します。
ログ・ファイルが累積されている原因が、DelayMinsプロパティの設定値が大きすぎるためかどうかを調べます。(ログ適用サービスでは、スタンバイ・データベースへのアーカイブREDOログ・ファイルの適用が、指定した時間(分)だけ遅延されます。)
何もエラーが表示されない場合は、Enterprise Managerの「パフォーマンス」ページでアーカイブ率を適用率と比較して、適用率がアーカイブ率より低いかどうかを調べます。
ブローカの要求が通常のタイムアウト・パラメータ内に完了しない場合、次の処置を試行して問題を解決します。
ネットワークが適切に動作しているかどうか確認します。
構成内のすべてのノードに対してpingを試行します。
他のデータベースにより再接続を試行し、操作を再試行します。
VERIFYコマンドを実行し、ブローカが要求を処理できないデータベースを特定します。
プライマリ・データベースがフラッシュバックされる場合、構成内のスタンバイ・データベースも、スイッチオーバーまたはフェイルオーバーの実行可能なターゲットとなるように、フラッシュバックまたは再作成される必要があります。プライマリ・データベースがフラッシュバックされた場合、ブローカによりスタンバイ・データベースのエラーがレポートされます。
ブローカにより無効化されたスタンバイ・データベースの実行可能性をリストアする方法の詳細は、5.4.3項を参照してください。
ブローカ操作(たとえば、スイッチオーバー、回復、フィジカル・スタンバイへの変換、または保護モードの最大保護モードへのアップグレード)の後でDGMGRL CLIが自動的にインスタンスを開始できず、ORA-12514: TNS: リスナーは接続記述子でリクエストされたサービスを現在認識していませんエラーを受け取った場合、インスタンスを手動で開始してブローカ操作を完了または継続する必要があります。
次の手順を完了する前か後に、インスタンスを再起動できます。
次のDGMGRL CLIコマンドを発行して、DGMGRL CLIが再起動できなかったインスタンスの構成可能なプロパティStaticConnectIdentiferの値を確認します。(このコマンドを発行するには、実行中の別のインスタンスに接続する必要があります)
DGMGRL> SHOW INSTANCE VERBOSE 'instance_name' ON DATABASE db_unique_name;
StaticConnectIdentiferインスタンス・プロパティの値で指定されている静的サービス名は、プロパティ値で指定されているリスナーに登録されている必要があります。静的サービス名のデフォルト値は、次の形式をとります。
db_unique_name_DGMGRL.db_domain
ブローカを使用するための、これを含む様々な前提条件の詳細は、2.2項を参照してください。
リスナー制御ユーティリティのステータス・コマンドを使用して、静的サービス名が、構成可能なプロパティStaticConnectIdentiferの値で指定されたリスナーに登録されていることを確認します。静的サービス名が正しくリスナーに登録されている場合、次のコマンドで生成される出力に含まれます。
lsnrctl status
Oracle RAC環境で作業している場合、各インスタンスに対して手順1と2を繰り返し、静的サービス名がそれぞれのリスナーに正しく登録されていることを確認することをお薦めします。
構成に問題があるためにスイッチオーバーに失敗すると、ブローカにより検出された問題はアラート・ログ・ファイルまたはブローカ・ログ・ファイルでレポートされます(9.1項を参照してください)。通常は、スイッチオーバー用に別のデータベースを選択するか、または構成をスイッチオーバー前の状態にリストアしてから、スイッチオーバーを再試行できます。次の各項では、最も一般的ないくつかの問題からのリカバリ方法を説明します。
ファスト・スタート・フェイルオーバーが有効化されている場合、ブローカでは、ターゲット・スタンバイ・データベース以外のどのスタンバイ・データベースにもスイッチオーバーを実行できません。さらに、ターゲット・スタンバイ・データベースへのスイッチオーバーは、ターゲット・スタンバイ・データベースのV$DATABASEビュー内のFS_FAILOVER_STATUS列の値が、READYまたはSUSPENDEDのいずれかである場合にのみ可能です。
元のプライマリ・データベースとターゲット・スタンバイ・データベースでアラートおよびDRCログ・ファイルを調べて、失敗した原因を確認します。次の項ではフィジカル・スタンバイ・データベースへのスイッチオーバーの失敗からリカバリする手順を、ログ・ファイルに含まれるエラーの種類に基づいて説明します。
ブローカのスイッチオーバーが失敗して、V$DATABASEビューのDATABASE_ROLE列にPRIMARYという値が含まれている場合は、次の手順に従います。
ファスト・スタート・フェイルオーバーが有効化されている場合は、無効化します。
元のプライマリ・データベースがクローズされている場合は、オープンします。
アラートとDRCログ・ファイルで報告されたエラーを修正します。
ブローカのスイッチオーバーを再試行します。
ファスト・スタート・フェイルオーバーが手順1で無効化された場合は、再び有効化します。
V$DATABASEのDATABASE_ROLE列にPHYSICAL STANDBYという値が含まれている場合は、次のどちらかの手順を実行します。
ファスト・スタート・フェイルオーバーが有効化されている場合は、無効化します。
新規フィジカル・スタンバイ・データベース(元のプライマリ・データベース)に接続して、ブローカ構成を無効化します。
新規フィジカル・スタンバイ・データベースを再起動します。
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY DATABASE SQL文を使用して、新規フィジカル・スタンバイ・データベースを変換してプライマリ・データベースに戻します。
新規プライマリ・データベースをオープンします。
ブローカ構成を再び有効化します。
ファスト・スタート・フェイルオーバーが手順1で無効化された場合は、再び有効化します。
ブローカのスイッチオーバーを再試行します。
または
ファスト・スタート・フェイルオーバーが有効化されている場合は、無効化します。
新規フィジカル・スタンバイ・データベース(元のプライマリ・データベース)に接続して、ブローカ構成を削除します。
ターゲット・スタンバイ・データベースに接続します。
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY DATABASE SQL文を使用して、ターゲット・フィジカル・スタンバイ・データベースへのスイッチオーバーを完了します。
新規プライマリ・データベースをオープンします。
新規フィジカル・スタンバイ・データベースを停止して、再起動します。
新規プライマリ・データベースに接続して、ブローカ構成を再作成します。
ブローカ構成を有効化します。
ファスト・スタート・フェイルオーバーが手順1で無効化された場合は、再び有効化します。
ブローカのスイッチオーバーが失敗して、ターゲット・フィジカル・スタンバイ・データベースのV$DATABASEビューのDATABASE_ROLE列にPHYSICAL STANDBYという値が含まれている場合は、次の手順に従います。
ファスト・スタート・フェイルオーバーが有効化されている場合は、無効化します。
アラートとDRCログ・ファイルを調べて、スイッチオーバーの失敗の原因を確認して修正します。問題の修正が完了したら、次のどちらかの手順を実行します。
新規フィジカル・スタンバイ・データベースに接続して、構成を無効化します。
新規フィジカル・スタンバイ・データベースを停止して、再起動します。
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY DATABASE SQL文を使用して、新規フィジカル・スタンバイ・データベースを変換してプライマリ・データベースに戻します。
構成を再び有効化します。
スイッチオーバーを再試行します。
または
新規フィジカル・スタンバイ・データベース(元のプライマリ・データベース)に接続して、ブローカ構成を削除します。
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY DATABASE SQL文を使用して、ターゲット・フィジカル・スタンバイ・データベースへのスイッチオーバーを完了します。新規プライマリ・データベースをオープンします。
新規フィジカル・スタンバイ・データベースを停止して、再起動します。
新規プライマリ・データベースに接続して、ブローカ構成を再作成します。
ブローカ構成を有効化します。
ファスト・スタート・フェイルオーバーが手順1で無効化された場合は、再び有効化します。
新規プライマリ・データベースをオープンできないためにブローカのスイッチオーバーが失敗した場合は、次の手順に従います。
ファスト・スタート・フェイルオーバーが有効化されている場合は、無効化します。
新規フィジカル・スタンバイ・データベース(元のプライマリ・データベース)に接続して、ブローカ構成を削除します。
新規プライマリ・データベースのアラート・ログ・ファイルでデータベースをオープンできない原因を調べて、それを修正してからデータベースをオープンします。
新規フィジカル・スタンバイ・データベースを停止して、再起動します。
新規プライマリ・データベースに接続して、ブローカ構成を再作成します。
ブローカ構成を有効化します。
ファスト・スタート・フェイルオーバーが手順1で無効化された場合は、再び有効化します。
元のプライマリ・データベースとターゲット・スタンバイ・データベースでアラートおよびDRCログ・ファイルを調べて、失敗した原因を確認します。次の項ではロジカル・スタンバイ・データベースへのスイッチオーバーの失敗からリカバリする手順を、ログ・ファイルに含まれるエラーの種類に基づいて説明します。
プライマリ・データベースの変換時のエラーのためにブローカのスイッチオーバーが失敗した場合は、次の手順に従います。
ファスト・スタート・フェイルオーバーが有効化されている場合は、無効化します。
ブローカ構成を無効化します。
『Oracle Data Guard概要および管理』に記載されている修正処理を実行します。
修正処理の実行後の場合は、次のどちらかの状況に応じて対処します。
元のプライマリ・データベースをプライマリ・ロールにリストアしている場合は、次の手順に従います。
ブローカ構成を再び有効化します。
ブローカのスイッチオーバーを再試行します。
ターゲット・ロジカル・スタンバイ・データベースを手動でプライマリ・データベースにスイッチオーバーしている場合は、次の手順に従います。
元のプライマリ・データベースに接続して、ブローカ構成を削除します。
ターゲット・ロジカル・スタンバイ・データベースに接続して、ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY SQL文を使用してそれをプライマリ・データベースに変換します。
新規プライマリ・データベースに接続して、ブローカ構成を再作成します。
ブローカ構成を有効化します。
ファスト・スタート・フェイルオーバーが手順1で無効化された場合は、有効化します。
ブローカのスイッチオーバーが失敗してV$DATABASEビューのDATABASE_ROLE列にPRIMARYという値が含まれている場合、もしくは列にLOGICAL STANDBYという値が含まれていてスイッチオーバーを完了する場合は、次の手順に従います。
ファスト・スタート・フェイルオーバーが有効化されている場合は、無効化します。
ターゲット・ロジカル・スタンバイ・データベースに接続して、ブローカ構成を無効化します。
『Oracle Data Guard概要および管理』に記載されている修正処理を実行します。
ブローカ構成を再び有効化します。
ファスト・スタート・フェイルオーバーが手順1で無効化された場合は、有効化します。
問題: REDO転送サービスの問題が原因でブローカのスイッチオーバーに失敗します。
解決策: Enterprise ManagerのData Guardの「概要」ページの情報を参照するか、DGMGRLクライアントのSHOW DATABASEコマンドを使用して、プライマリ・データベースおよびスタンバイ・データベースの状態とステータスを検証します。
Enterprise Managerを使用している場合は、次にスイッチオーバー完了後に検証操作を実行して、新しいプライマリ・データベースのアラート・ログ・ファイルを調べて、構成のステータスを検証します。
問題: Data Guard Brokerによる検証チェック中にスイッチオーバーに失敗する場合があります(スイッチオーバーに関係するデータベース上でREDO転送サービスがエラーを戻す場合など)。
解決策: スイッチオーバー用に別のデータベースを選択するか、アーカイブREDOログ・ファイルを転送して問題を修正してください。
フェイルオーバーを停止することは可能ですが、これはお薦めしません。ほとんどのエラーは、スタンバイ・データベースがプライマリ・ロールに遷移しているときに発生します。次のガイドラインに従って問題を修正し、ブローカのフェイルオーバーを続行します。
フィジカル・スタンバイ・データベースへのブローカのフェイルオーバーの失敗からリカバリする手順は、次のとおりです。
ターゲット・スタンバイ・データベースでアラートおよびDRCログ・ファイルを調べて、失敗した原因を確認し、それを修正します。ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH SQL文でエラーが返された場合、もしくはSQL文は正常に実行されたのにデータベースがプライマリ・データベースに変換されなかった場合は、次の手順に従います。
ターゲット・スタンバイ・データベースに接続し、ファスト・スタート・フェイルオーバーが有効な場合はFORCEオプションを使用して無効化します。
次のどちらかの操作を実行します。
別のフィジカル・スタンバイ・データベースに接続して、ブローカの完全フェイルオーバーを実行します。
ターゲット・フィジカル・スタンバイ・データベースへのブローカの即時フェイルオーバーを実行します。
元のプライマリ・データベースと、回復を要求するステータス(ORA-16661)を持つその他の無効なフィジカル・スタンバイ・データベースを回復します。
ファスト・スタート・フェイルオーバーが手順1で無効化された場合は、再び有効化します。
ターゲット・スタンバイ・データベースでアラートおよびDRCログ・ファイルを調べて、失敗した原因を確認し、それを修正します。
ターゲット・スタンバイ・データベースに接続し、ファスト・スタート・フェイルオーバーが有効な場合はFORCEオプションを使用して無効化します。
ブローカのフェイルオーバーを再試行します。
元のプライマリ・データベースを回復します。その他のスタンバイ・データベースはすべて、新規プライマリ・データベースのコピーから再作成されます。
ファスト・スタート・フェイルオーバーが手順1で無効化された場合は、再び有効化します。
ブローカのフェイルオーバーが引き続き失敗する場合は、Data Guard構成ですべてのデータベース上のブローカを停止します(DG_BROKER_START初期化パラメータをFALSEに設定します)。すべてのデータベースからData Guardブローカ構成ファイルを削除します。『Oracle Data Guard概要および管理』のロール遷移に関するガイドラインを使用して、手動フェイルオーバーを実行します。
|
注意: DGMGRLのENABLE CONFIGURATIONおよびDISABLE CONFIGURATIONコマンドを使用すると、ブローカ構成を有効化または無効化できます。Enterprise Managerを使用して構成を無効化することはできません。前にDGMGRLを使用して無効化した構成は、Enterprise Managerを使用した場合のみ有効化できます。 |
オブザーバは、継続的にファスト・スタート・フェイルオーバー環境を監視して、プライマリ・データベースが使用可能であることを確認します。オブザーバのインストールおよび起動は、ファスト・スタート・フェイルオーバーの使用における必須部分です。次の各項で、オブザーバのトラブルシューティング方法について説明します。
一度に1つのオブザーバのみブローカ構成を監視できます。2つ目のオブザーバを起動しようとすると、次のいずれかのエラーが戻されます。
ORA-16647: could not start more than one observer DGM-16954: Unable to open and lock the Observer configuration file
現在ブローカ構成に関連付けられているオブザーバの位置を判別するには、DGMGRLのSHOW CONFIGURATION VERBOSEコマンドを使用します。
DGMGRL> SHOW CONFIGURATION VERBOSE;
Configuration - DRSolution
Protection Mode: MaxAvailability
Databases:
North_Sales - Primary database
South_Sales - (*) Physical standby database
(*) Fast-Start Failover target
Properties:
FastStartFailoverThreshold = '60'
OperationTimeout = '30'
FastStartFailoverLagLimit = '30'
CommunicationTimeout = '180'
FastStartFailoverAutoReinstate = 'TRUE'
FastStartFailoverPmyShutdown = 'TRUE'
BystandersFollowRoleChange = 'ALL'
Fast-Start Failover: ENABLED
Threshold: 180 seconds
Target: South_Sales
Observer: observer.example.com
Lag Limit: 30 seconds (not in use)
Shutdown Primary: TRUE
Auto-reinstate: TRUE
Configuration Status:
SUCCESS
オブザーバのホスト・マシンがクラッシュした場合、ブローカ構成は監視されなくなり、ファスト・スタート・フェイルオーバーは実行できなくなります。この場合、元のホスト・マシンを適時に修復できないときは、オブザーバを新しいホストに移動する必要があります。オブザーバを移動するには、最初のオブザーバがこのブローカ構成を監視できないようにしてから、別のホストで新規オブザーバを起動する必要があります。
DGMGRLのSTOP OBSERVERコマンドを発行し、元のオブザーバとブローカ構成の間のリンクを切り離します。
DGMGRL> STOP OBSERVER; Done.
DGMGRLのSHOW CONFIGURATION VERBOSEコマンドを発行し、構成が監視されていないことを確認します。
DGMGRL> SHOW CONFIGURATION VERBOSE;
Configuration - DRSolution
Protection Mode: MaxAvailability
Databases:
North_Sales - Primary database
South_Sales - (*) Physical standby database
(*) Fast-Start Failover target
Properties:
FastStartFailoverThreshold = '60'
OperationTimeout = '30'
FastStartFailoverLagLimit = '30'
CommunicationTimeout = '180'
FastStartFailoverAutoReinstate = 'TRUE'
FastStartFailoverPmyShutdown = 'TRUE'
BystandersFollowRoleChange = 'ALL'
Fast-Start Failover: ENABLED
Threshold: 180 seconds
Target: South_Sales
Observer: (none)
Lag Limit: 30 seconds (not in use)
Shutdown Primary: TRUE
Auto-reinstate: TRUE
Configuration Status:
SUCCESS
オブザーバが実際に停止していることを確認する際に、DGMGRLのSHOW CONFIGURATIONコマンドを発行する必要はないので注意してください。DGMGRLのSTOP OBSERVERコマンドを正常に完了すると、新規オブザーバを構成に関連付けることが可能になります。
DGMGRLの-logfileオプションを使用してオブザーバを起動できます。これにより、9.5.1項で実行したトラブルシューティング処理をすべてファイルに取得できます。次に例を示します。
% dgmgrl -logfile observer.log / "start observer"
オブザーバの出力はすべて、DGMGRLコマンドを発行した現在の作業ディレクトリ内のobserver.logファイルに記録されます。指定したログにアクセスできない場合、ログ・ファイルが指定されていない場合と同様に、オブザーバーの出力が標準出力に送信されます。
これはオブザーバの問題のトラブルシューティングに役立つだけではなく、ファスト・スタート・フェイルオーバー全般の問題のトラブルシューティングにも役立ちます。
