機械翻訳について

Oracle Exadata Database Service on Cloud@Customerシステムのトラブルシューティング

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

• 「Oracle Exadata Database Service on Cloud@Customerシステムでのパッチ適用の失敗」
  
• 「さらなる支援の取得」
  
• 「データベース接続のドレイン中にVMオペレーティング・システム更新がハング」
  
• 「VMクラスタへのVMの追加が失敗」
  
• 「Data Guard対応データベースのノード・リストは更新されません」
  
• 「CPUオフライン・スケーリングの失敗」
  
• 「Oracle Database 11g Oracle Data Guard設定でのスイッチオーバー後にスタンバイ・データベースの再起動が失敗」
  
• 「障害リカバリ・ネットワークでData GuardでカスタムSCANリスナー・ポートを使用すると、Data Guard関連付けの検証が失敗」
  
• 「新しいDBホーム(23ai)へのデータベースの移動後にPDBの作成が失敗する」
  

Oracle Exadata Database Service on Cloud@Customerシステムでのパッチ適用の失敗

パッチ適用操作は様々な理由で失敗する可能性があります。 通常、データベース・ノードが停止しているか、ファイル・システムの領域が不足しているか、仮想マシンがオブジェクト・ストアにアクセスできないため、操作は失敗します。

• 「問題の特定」
  コンソールで、Oracle Exadata Database Service on Cloud@Customerシステムまたは個々のデータベースのパッチ履歴を表示することで、失敗したパッチ適用操作を識別できます。
• 「トラブルシューティングと診断」
  いずれかのOracle Exadata Database Service on Cloud@Customerコンポーネントのパッチ適用プロセス中に発生する可能性のある最も一般的な問題を診断します。

問題の特定

コンソールで、Oracle Exadata Database Service on Cloud@Customerシステムまたは個々のデータベースのパッチ履歴を表示することで、失敗したパッチ適用操作を識別できます。

正常に適用されなかったパッチには、Failedのステータスが表示され、失敗の原因となったエラーの簡単な説明が含まれます。 エラー・メッセージにソリューションを指し示すのに十分な情報が含まれていない場合は、データベースCLIおよびログ・ファイルを使用して、より多くのデータを収集できます。 解決策については、このトピックの該当する項を参照してください。

トラブルシューティングと診断

いずれかのOracle Exadata Database Service on Cloud@Customerコンポーネントのパッチ適用プロセス中に発生する可能性のある最も一般的な問題を診断します。

• 「データベース・サーバーのVMの問題」
  データベース・サーバーVMで次の条件の1つ以上が原因で、パッチ適用操作が失敗する可能性があります。
• 「Oracle Grid Infrastructure問題」
  Oracle Grid Infrastructureで次の条件が発生すると、パッチ適用操作が失敗する可能性があります。
• 「Oracle Databases問題」
  データベースの状態が不適切な場合、パッチ適用が失敗する可能性があります。

データベース・サーバーのVMの問題

データベース・サーバーVMで次の条件の1つ以上が原因で、パッチ適用操作が失敗する可能性があります。

データベース・サーバーのVM接続の問題

クラウド・ツールは、特定のVMクラスタの仮想マシン間の適切なネットワーキングおよび接続構成に依存します。 構成が正しく設定されていない場合、ノード間処理を必要とするすべての操作で障害が発生する可能性があります。 ある例では、特定のパッチの適用に必要なファイルをダウンロードできません。

この場合、次のアクションを実行できます:

• 関連する仮想マシン・アドレスがVMクラスタ内で解決できるように、DNS構成が正しいことを確認します。
• 「さらなる支援の取得」の項の説明に従って関連するクラウド・ツールのログを参照し、Oracle Supportに連絡してください。

Oracle Grid Infrastructureの問題

Oracle Grid Infrastructureで次の条件が発生すると、パッチ適用操作が失敗する可能性があります。

Oracle Grid Infrastructureは停止しています

Oracle Clusterwareを使用すると、サーバーは相互に通信できるため、集合ユニットとして機能します。 パッチ適用操作を完了するには、クラスタ・ソフトウェア・プログラムがVMクラスタで稼働している必要があります。 パッチ適用の失敗を解決するために、Oracle Clusterwareの再起動が必要になる場合があります。

このような場合は、次のようにOracle Grid Infrastructureのステータスを確認します:

./crsctl check cluster
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online

Oracle Grid Infrastructureが停止している場合は、次のコマンドを実行して再起動します:

crsctl start cluster -all

crsctl check cluster

Oracle Databases問題

データベースの状態が不適切な場合、パッチ適用が失敗する可能性があります。

Oracle Databaseは停止しています

クラスタ全体でパッチ適用操作を正常に完了するには、データベースがアクティブで、すべてのアクティブ・ノードで実行されている必要があります。

次のコマンドを使用して、データベースの状態を確認し、データベースを不適切な状態にした可能性のある問題が解決されていることを確認します:

srvctl status database -d db_unique_name -verbose

データベース・インスタンスのステータスを含むメッセージが返されます。 パッチ適用操作を成功させるには、インスタンス・ステータスが「オープン」である必要があります。

データベースが稼働していない場合は、次のコマンドを使用して起動します:

srvctl start database -d db_unique_name -o open

さらなる支援の取得

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

• 「クラウド・ツールのログの収集」
  特定の問題をさらに調査して解決するには、Oracle Supportを支援する関連ログ・ファイルを使用します。
• 「Oracle Diagnosticsの収集」
  

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

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

DBAASCLIログ

/var/opt/oracle/log/dbaascli

• dbaascli.log

Oracle Diagnosticsの収集

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

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

データベース接続のドレイン中にVMオペレーティング・システム更新がハング

説明: これは断続的な問題です。 19c Grid Infrastructureおよび実行中のデータベースによる仮想マシン・オペレーティング・システムの更新中、dbnodeupdate.shは、RHPhelperが接続をドレインするのを待機します。これは既知のバグ"DBNODEUPDATE.SH HANGS IN RHPHELPER TO DRAIN SESSIONS AND SHUTDOWN INSTANCE"のために進行しません。

症状: このバグにより考えられる2つの結果があります:

1. VMオペレーティング・システムの更新がrhphelperでハングアップ
   • 自動化を推進
   • データベース接続の一部または全部がドレインされ、一部またはすべてのデータベース・インスタンスが稼働し続けます。
2. rhphelperがクラッシュしたため、VMオペレーティング・システムの更新ではデータベース接続がドレインされません
   • 自動化を妨げない
   • データベース接続のドレインの一部またはまったく完了しない

/var/log/cellos/dbnodeupdate.trcは、これを最後の行として表示します:

(ACTION:) Executing RHPhelper to drain sessions and shutdown instances. 
(trace:/u01/app/grid/crsdata/scaqak04dv0201/rhp//executeRHPDrain.150721125206.trc)

アクション:

1. Grid Infrastructureのバージョンを19.11以上にアップグレードします。

   (または)

   更新する前にrhphelperを無効にし、更新後に再び有効にします。

   更新を開始する前に無効化するには:

   /u01/app/19.0.0.0/grid/srvm/admin/rhphelper /u01/app/19.0.0.0/grid 19.10.0.0.0 -setDrainAttributes ENABLE=false

   更新の完了後に有効にするには:

   /u01/app/19.0.0.0/grid/srvm/admin/rhphelper /u01/app/19.0.0.0/grid oracle-home-current-version -setDrainAttributes ENABLE=true

   rhphelperを無効にすると、オペレーティング・システムが更新される前に、データベース・サービスおよびインスタンスがノード上で停止する前に、データベース接続がドレインされることはありません。

2. RHPhelperを無効にし、アップグレードが進行中でハングしていない場合、サービスのドレインに時間がかかっていることがわかります:
   1. 次のような段落を含む/var/log/cellos/dbnodeupdate.trcトレース・ファイルを調べます:

      (ACTION:) Executing RHPhelper to drain sessions and shutdown instances. 
      (trace: /u01/app/grid/crsdata/<nodename>/rhp//executeRHPDrain.150721125206.trc)

   2. /var/log/cellos/dbnodeupdate.trcトレース・ファイルを開きます。
      rhphelperが失敗した場合、トレース・ファイルには次のようなメッセージが表示されます:

      "Failed execution of RHPhelper"

      rhphelperがハングすると、トレース・ファイルに次のようなメッセージが表示されます:

      (ACTION:) Executing RHPhelper to drain sessions and shutdown instances.

   3. オペレーティング・システム・レベルで実行されているrhphelperプロセスを特定し、強制終了します。

      名前に「rhphelper」という文字列を指定する2つのコマンドがあります - Bashシェル、およびrhphelperを実行する基礎となるJavaプログラム。

      rhphelperはrootとして実行されるため、root (opcのsudo)として強制終了する必要があります。

      たとえば:

      [opc@<HOST> ~] pgrep –lf rhphelper
      191032 rhphelper
      191038 java
      

      [opc@<HOST> ~] sudo kill –KILL 191032 191038

   4. dbnodeupdate.trcファイルが移動し、ノードのGrid Infrastructureスタックが停止していることを確認します。

   RHPhelperの詳細は、「RHPhelperを使用したExadataでの計画メンテナンス中のダウンタイムの最小化(ドキュメントID 2385790.1)」を参照してください。

VMクラスタへのVMの追加が失敗

説明: VMをVMクラスタに追加するときに、次の問題が発生する可能性があります:

[FATAL] [INS-32156] Installer has detected that there are non-readable files in oracle home.
CAUSE: Following files are non-readable, due to insufficient permission oracle.ahf/data/scaqak03dv0104/diag/tfa/tfactl/user_root/tfa_client.trc
ACTION: Ensure the above files are readable by grid.

原因: インストーラは、OracleホームのAutonomous Health Framework (AHF)によって作成された読取り不可能なトレース・ファイルoracle.ahf/data/scaqak03dv0104/diag/tfa/tfactl/user_root/tfa_client.trcを検出し、クラスタVMの追加に失敗します。

AHFはrootとして実行され、gridユーザーが読み取ることができないroot所有権を持つtrcファイルが作成されました。

アクション: VMクラスタに追加する前に、AHFトレース・ファイルがgridユーザーによって読取り可能であることを確認してください。 権限の問題を修正するには、既存のすべてのVMクラスタVMでrootとして次のコマンドを実行します:

chown grid:oinstall /u01/app/19.0.0.0/grid/srvm/admin/logging.properties

chown -R grid:oinstall /u01/app/19.0.0.0/grid/oracle.ahf*

chown -R grid:oinstall /u01/app/grid/oracle.ahf*

Data Guard対応データベースのノード・リストは更新されません

説明: VMクラスタへのVMの追加は正常に完了しましたが、Data Guardが有効なデータベースの場合、新しいVMは/var/opt/oracle/creg/<db>.iniファイルのノード・リストには追加されません。

原因: Data Guard対応のデータベースは、新しく追加されたVMに拡張されません。 そのため、データベース・インスタンスが新しいVMで構成されていないため、<db>.iniファイルも更新されません。

アクション: インスタンスをプライマリ・データベースとスタンバイ・データベースと新しいVM (非Data Guard)に追加し、Data Guard環境からインスタンスを削除するには、My Oracle Supportノート2811352.1を参照してください。

CPUオフライン・スケーリングの失敗

説明: 次のエラーで、CPUオフライン・スケーリングが失敗します:

** CPU Scale Update **An error occurred during module execution. Please refer to the log file for more information

原因: VMクラスタのプロビジョニング後、Database as a Service (DBaaS)によって自動的に生成される/var/opt/oracle/cprops/cprops.iniファイルは、common_dcs_agent_bindHostおよびcommon_dcs_agent_portパラメータで更新されず、CPUオフライン・スケーリングが失敗します。

アクション: rootユーザーとして、/var/opt/oracle/cprops/cprops.iniファイルに次のエントリを手動で追加します。

common_dcs_agent_bindHost=<IP_Address>
common_dcs_agent_port=7070

ノート:

common_dcs_agent_port値は常に7070です。

次のコマンドを実行して、IPアドレスを取得します:

netstat -tunlp | grep 7070

たとえば:

netstat -tunlp | grep 7070
tcp 0 0 <IP address 1>:7070 0.0.0.0:* LISTEN 42092/java
tcp 0 0 <IP address 2>:7070 0.0.0.0:* LISTEN 42092/java

common_dcs_agent_bindHostパラメータには、<IP address 1>または<IP address 2>の2つのIPアドレスのいずれかを指定できます。

Oracle Database 11g Oracle Data Guard設定でのスイッチオーバー後にスタンバイ・データベースの再起動が失敗

説明: スイッチオーバーの実行後、新しいスタンバイ(古いプライマリ)データベースは停止したままになり、再起動に失敗します。

アクション: スイッチオーバーの実行後、次の手順を実行します:

1. srvctl start database -db <standby dbname>コマンドを使用してスタンバイ・データベースを再起動します。
2. すべてのプライマリおよびスタンバイ・クラスタ・ノードでgridユーザーとしてリスナーをリロードします。
   • 高可用性を使用してリスナーを再ロードするには、パッチ25075940をダウンロードしてGridホームに適用し、lsnrctl reload -with_haを実行します。
   • リスナーをリロードするには、lsrnctl reloadを実行します。

リスナーのリロード後、lsnrctl statusコマンドを使用して、<dbname>_DGMGRLサービスがリスナーにロードされていることを確認します。

パッチ25075940をダウンロードするには

1. My Oracle Supportにログインします。
2. 「パッチと更新版」をクリックします。
3. 「番号/名前またはバグ番号(シンプル)」ドロップダウン・リストから「バグ番号」を選択します。
4. バグ番号34741066を入力し、「検索」をクリックします。
5. 検索結果から、最新のパッチの名前をクリックします。

   「パッチ34741066: LSNRCTL RELOAD -WITH_HA LISTENER.ORA内の静的エントリの読み取りに失敗しました」ページにリダイレクトされます。

6. 「ダウンロード」をクリックします。

障害リカバリ・ネットワークでData GuardでカスタムSCANリスナー・ポートを使用すると、Data Guard関連付けの検証が失敗

説明: クライアント・ネットワークと障害リカバリ・ネットワーク(DRネットワーク)のSCANリスナー・ポートが異なる場合、Data Guard (DG)構成は、データ・ガード関連付けの作成の検証フェーズ中に失敗します。

アクション: すべてのネットワークで同じSCANリスナー・ポート(またはデフォルト・ポート)を使用します。 クラスタの構成後にリスナー・ポートを修正するには、GI home/bin/srvctl modify listener -listener listener_name -endpoints endpointsコマンドを実行します。 詳細は、「Oracle Real Application Clusters管理およびデプロイメント・ガイド」のsrvctl modify listenerを参照してください。

新しいDBホーム(23ai)へのデータベースの移動後にPDBの作成が失敗する

説明: データベースを別のDBホームに再配置すると、新しいプラガブル・データベース(PDB)の作成が失敗します。 PDBサービスの起動に失敗し、次のエラーが発生します:

[FATAL] [DBAAS-60022] Command '/u02/app/oracle/product/23.0.0.0/dbhome_3/bin/srvctl 'start' 'service' '-db' 'db23ano' '-service' 'db23ano_PDBJULY242.paas.oracle.com'' has failed on nodes [localnode].

アクション: Grid Infrastructureのバージョンが23.4.0.24.05の場合は、バージョン23.5.0.24.07にアップグレードしてこの問題を解決します。