機械翻訳について

Oracle Exadata Database Service on Exascale Infrastructureシステムのトラブルシューティング

これらのトピックでは、発生する可能性のある一般的な問題とその対処方法について説明します。

Exadata Database Service on Exascale Infrastructureの既知の問題

一般的な既知の問題。

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

Oracle Data Guardの問題を特定して解決する方法について学習します。

Oracle Data Guardのトラブルシューティングでは、ライフサイクル・コマンドが入力されたときに、Data Guardの設定および初期化中またはData Guardの操作中に問題が発生するかどうかを最初に判断する必要があります。 問題を識別および解決するステップは、それらが使用されるシナリオによって異なります。

3つのライフサイクル操作があります: スイッチオーバー、フェイルオーバーおよび回復。 Data Guard Brokerは、これらのすべてのコマンドに使用されます。 ブローカ・コマンドライン・インタフェース(dgmgrl)は、問題の識別とトラブルシューティングに使用される主要なツールです。 ログ・ファイルを使用して根本原因を特定できますが、dgmgrlは、問題のチェックと識別に迅速かつ簡単に使用できます。

Data Guardの設定および有効化には複数のステップが含まれます。 ログ・ファイルはステップごとに作成されます。 いずれかのステップが失敗した場合は、関連するログ・ファイルを確認し、問題を特定して修正します。

  • プライマリ・クラウドVMクラスタおよびデータベースの検証
  • スタンバイ・クラウドVMクラスタの検証
  • スタンバイ・データベースへのファイルの再作成およびコピー(パスワード・ファイルおよびウォレット)
  • ネットワークを介したData Guardの作成(RMAN Duplicateコマンド)
  • Data Guard Brokerの構成
  • 設定の完了

ログ・ファイルを使用したData Guardのトラブルシューティング

問題の識別に使用するツールおよび関連するログ・ファイルのロケーションは、それらを使用するシナリオによって異なります。

次の手順を使用して、関連するログ・ファイルを収集し、問題を調査します。 ログ・ファイルの調査後に問題を解決できない場合は、My Oracle Supportに連絡してください。

ノート:

収集したファイルをOracle Support用に準備する場合は、ZIPファイルなどの圧縮アーカイブにバンドルします。

Data Guard構成に関連付けられている各コンピュート・ノードで、発生した問題に関連するログ・ファイルを収集します。

  • 有効化ステージのログ・ファイル(スタンバイ・データベースの作成操作を文書化するものなど)および対応するプライマリまたはスタンバイ・システムのログ。
  • 有効化ジョブIDのログ・ファイル。 たとえば: 23
  • 有効化ステージおよびExadataシステム(プライマリまたはスタンバイ)別の有効化ログ・ファイルのロケーション。
  • データベース名のログ・ファイル(ファイル・パスに応じてdb_name またはdb_unique_name)。

ノート:

対応するプライマリおよびスタンバイExadataシステムのすべてのノードをチェックしてください。 システムで実行されたコマンドは、そのノードのいずれかで実行された可能性があります。

Data Guard Deployer (DGdeployer)は、構成を実行するプロセスです。 プライマリ・データベースを構成すると、/var/opt/oracle/log/<dbname>/dgdeployer/dgdeployer.logファイルが作成されます。

このログには、プライマリ・データベースの構成に失敗した根本原因が含まれています。

  • dbaasapiコマンドライン・ユーティリティのプライマリ・ログは次のとおりです: /var/opt/oracle/log/dbaasapi/db/dg/<job_ID>.log dg_apiを含むエントリを探します。
  • dbaasapiコマンドライン・ユーティリティのスタンバイ・ログは、次のとおりです: /var/opt/oracle/log/dbaasapi/db/dg/<job_ID>.log このログで、dg_apiを含むエントリを検索します。
  • もう1つのスタンバイ・ログは: /var/opt/oracle/log/<dbname>/dgcc/dgcc.log このログはData Guard構成ログです。
  • Oracle Cloudデプロイメント・エンジン(ODCE)は、/var/opt/oracle/log/<dbname>/ocde/ocde.logファイルを作成します。 このログには、スタンバイ・データベースの作成に失敗しました。
  • dbaasapiコマンドライン・ユーティリティは、var/opt/oracle/log/dbaasapi/db/dg/<job_ID>.logファイルを作成します。 dg_apiを含むエントリを探します。
  • Data Guard構成ログ・ファイルは/var/opt/oracle/log/<dbname>/dgcc/dgcc.logです。
  • DGdeployerは、構成を実行するプロセスです。 次の/var/opt/oracle/log/<dbname>/dgdeployer/dgdeployer.logファイルが作成されます。 このログには、スタンバイ・データベースの構成に失敗した根本原因が含まれています。
  • dbaasapiコマンドライン・ユーティリティは、/var/opt/oracle/log/dbaasapi/db/dg/<job_ID>.logファイルを作成します。 dg_apiを含むエントリを探します。
  • Data Guard構成ログは/var/opt/oracle/log/<dbname>/dgcc/dgcc.logです。

DGdeployerは、構成を実行するプロセスです。 Data Guardの構成中に、/var/opt/oracle/log/<dbname>/dgdeployer/dgdeployer.logファイルが作成されます。 このログには、プライマリ・データベースの構成に失敗した根本原因が含まれています。

プライマリ・サイトおよびスタンバイ・サイトの各ノードで、関連するデータベース名(db_name)のログ・ファイルを収集します。

ノート:

プライマリとスタンバイの両方のExadataシステムのすべてのノードを確認します。 ライフサイクル管理操作は、プライマリ・システムとスタンバイ・システムの両方に影響する可能性があります。
  • データベース・アラート・ログ: /u02/app/oracle/diag/rdbms/<dbname>/<dbinstance>/trace/alert_<dbinstance>.log
  • Data Guard Brokerログ: /u02/app/oracle/diag/rdbms/<dbname>/<dbinstance>/trace/drc<dbinstance>.log
  • Data Guardのクラウド・ツール・ログ・ファイル: /var/opt/oracle/log/<dbname>/odg/odg.log

Data Guard設定プロセスのトラブルシューティング

Data Guard設定プロセスの様々なステップで発生する可能性のあるエラーを確認します。 一部のエラーはコンソール内に表示されますが、根本原因のほとんどはログ・ファイルで確認できます

Data Guardを有効にするために入力したパスワードが、SYSユーザーのプライマリ管理パスワードと一致しませんでした。 このエラーは、有効化のプライマリの検証ステージで発生します。

データベースが実行されていない可能性があります。 このエラーは、有効化のプライマリの検証ステージで発生します。 ホストでsrvctlおよびsqlを確認して、データベースがすべてのノードで稼働していることを確認します。

プライマリ・データベースを構成できませんでした。 Data Guardコマンドが無効であるか、リスナーの再構成に失敗したことが、このエラーが発生する可能性があります。

TDEウォレットを作成できませんでした。 スタンバイ・サイトに転送するためのOracle Transparent Database Encryption (TDE)キーストア(ウォレット)ファイルを準備できませんでした。 このエラーは、有効化のTDE Walletの作成ステージ中に発生します。 次のいずれかのアイテムが、このステージで失敗する可能性があります:

  • TDEウォレット・ファイルにアクセスできませんでした
  • 有効化コマンドは、ウォレット・ファイルを含むアーカイブを作成できませんでした

トラブルシューティング手順:

  1. クラスタがアクセス可能であることを確認します。 クラスタのステータスをチェックするには、次のコマンドを実行します:
    crsctl check cluster -all
  2. クラスタが停止している場合は、次のコマンドを実行して再起動します:
    crsctl start crs -wait
  3. クラスタがアクセス可能なときにこのエラーが発生した場合は、ログでTDE Walletの作成(有効化ステージ)をチェックして、エラーの原因と解決を確認します。

TDEウォレットを含むアーカイブがスタンバイ・サイトに転送されなかった可能性があります。 通常、再試行すると問題が解決します。

  • スタンバイ・データベースを構成するためにプライマリ・サイトとスタンバイ・サイトが相互に通信できない可能性があります。 これらのエラーは、有効化のスタンバイ・データベースの構成ステージ中に発生します。 このステージでは、プライマリ・データベースのRM複製を含め、スタンバイ・データベースで構成が実行されます。 この問題を解決するには:
    1. プライマリ・サイトとスタンバイ・サイトの接続ステータスを確認します。
    2. ホストがポート1521からすべてのポートと通信できるようにします。 ネットワーク・セキュリティ・グループ(NSG)、ネットワーク・セキュリティ・リストおよびリモートVCNピアリング設定(該当する場合)を含むネットワーク設定をチェックします。 ホストとその他のノードの間の通信をテストする最善の方法は、SQL*PLUSを使用してプライマリからスタンバイ、およびスタンバイからプライマリまでのデータベースにアクセスすることです。
  • SCAN VIPまたはリスナーが実行されていない可能性があります。 前述のテストを使用して、問題を識別してください。

考えられる原因:

  • SCAN VIPまたはリスナーが実行されていない可能性があります。 この問題を確認するには、任意のクラスタ・ノードで次のコマンドを使用します。
    • [grid@exa1-****** ~]$ srvctl status
                  scan
    • [grid@exa1-****** ~]$ srvctl status
                    scan_listener
  • データベースに到達できない可能性があります。 この問題を確認するには、既存のOracle Net別名を使用して接続を試みます。

トラブルシューティング手順:

  1. oracle OSユーザーとして、コンテナ・データベース(CDB)のOracle Net別名が存在することを確認します。 $ORACLE_HOME/network/admin/ <dbname> / tnsnames.oraで別名を検索します。

    次の例は、db12cという名前のコンテナ・データベースのエントリを示しています:

    cat $ORACLE_HOME/network/admin/db12c/tnsnames.ora 
    DB12C = (DESCRIPTION =(ADDRESS = (PROTOCOL = TCP)(HOST = exa1-*****-scan.********.******.******.com)(PORT = 1521)) 
    (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = db12c.********.******.******.com) 
    (FAILOVER_MODE = (TYPE = select) (METHOD = basic))))
  2. 別名を使用してデータベースに接続できることを確認します。 たとえば、sysdbaとして次のコマンドを入力します:
    sqlplus sys@db12c

このエラーの考えられる原因は、データベースのOracle Database sysまたはシステム・ユーザー・パスワードとTDEウォレットが同じでない可能性があることです。 パスワードを比較するには:

  1. 「sysユーザー」としてデータベースに接続し、TDEステータスを確認
    V$ENCRYPTION_WALLET
    .
  2. 「システム・ユーザー」としてデータベースに接続し、TDEステータスを確認
    V$ENCRYPTION_WALLET
    .
  3. 該当するパスワードを更新して一致します。 システム・ホストにopcとしてログオンし、次のコマンドを実行します:
    1. SYSパスワードを変更するには:
      sudo dbaascli database changepassword --dbname <database_name>
    2. TDEウォレット・パスワードを変更するには:
      sudo dbaascli tde changepassword --dbname <database_name>

スイッチオーバー、フェイルオーバー、および回復コマンドが実行されると、複数のエラー・メッセージが表示されることがあります。 これらのエラー・メッセージについては、Oracle Databaseのドキュメントを参照してください。

ノート

Oracleでは、Data Guard Brokerコマンドライン・インタフェース(dgmgrl)を使用して構成を検証することをお薦めします。

  1. Oracleユーザーとして、dgmgrlを使用してプライマリ・データベースまたはスタンバイ・データベースに接続し、構成およびデータベースを確認します:
    dgmgrl sys/<pwd>@<database>
    DGMGRL> VALIDATE CONFIGURATION VERBOSE
    DGMGRL> VALIDATE DATABASE VERBOSE <PRIMARY>
    DGMGRL> VALIDATE DATABASE VERBOSE <STANDBY>
  2. それぞれのエラー・メッセージを確認するには、Oracle Databaseのドキュメントを参照してください。 たとえば:
    • ORA-16766: REDO適用は停止されます。
    • ORA-16853: 適用ラグが指定のしきい値を超えました。
    • ORA-16664: メンバー(スタンバイ・データベースの下)から結果を受信できません。
    • ORA-12541: TNS: リスナーなし(プライマリ・データベースの下)

さらなる支援の取得

このトピックの情報を使用して問題を解決できなかった場合は、次の手順に従って関連するデータベースおよび診断情報を収集します。 この情報を収集したら、Oracle Supportに連絡してください。

関連トピック

クラウド・ツールのログの収集

特定の問題をさらに調査して解決するには、Oracle Supportを支援する関連ログ・ファイルを使用します。

DBAASCLIログ

/var/opt/oracle/log/dbaascli
  • dbaascli.log

Oracle Diagnosticsの収集

関連するOracle診断情報およびログを収集するには、dbaascli diag collectコマンドを実行します。

このユーティリティの使用方法の詳細は、「DBAASツール: dbaascliを使用したクラウド・ツール・ログの収集およびクラウド・ツールのヘルス・チェックの実行」を参照してください。