Exadata Cloud Infrastructureシステムのトラブルシューティング

機械翻訳について

Exadata Cloud Infrastructureシステムのトラブルシューティング

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

「Exadata Cloud Infrastructureの既知の問題」
一般的な既知の問題。
「ネットワーク接続のトラブルシューティング」
VMクラスタがOracle Cloud Infrastructure (OCI)サービス・ネットワークにアクセスするように適切に構成されているかどうかを確認するには、VMクラスタ内の各仮想マシンで次のステップを実行する必要があります。
「Exadata Database Service on Dedicated Infrastructureでのバックアップの失敗」
Exadata管理対象バックアップが正常に完了しない場合は、このトピックの手順を使用して問題をトラブルシューティングおよび修正できます。
「Oracle Data Guardのトラブルシューティング」
Oracle Data Guardの問題を特定して解決する方法について学習します。
「Exadata Cloud Infrastructureシステムでのパッチ適用の失敗」
「さらなる支援の取得」
「Oracle Database 11g Oracle Data Guard設定でのスイッチオーバー後にスタンバイ・データベースの再起動が失敗」

親トピック: Exadata Cloud Infrastructureリファレンス・ガイド

Exadata Cloud Infrastructureの既知の問題

一般的な既知の問題。

親トピック: Exadata Cloud Infrastructureシステムのトラブルシューティング

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アドレスのいずれかを指定できます。

親トピック: Exadata Cloud Infrastructureの既知の問題

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*

親トピック: Exadata Cloud Infrastructureの既知の問題

ネットワーク接続のトラブルシューティング

VMクラスタがOracle Cloud Infrastructure (OCI)サービス・ネットワークにアクセスするように適切に構成されているかどうかを確認するには、VMクラスタ内の各仮想マシンで次のステップを実行する必要があります。

Identity and Access Management接続の検証チェック:

opcユーザーとして、ExaDB-D VMクラスタの仮想マシンにsshします。
コマンドの実行 : ここでcurl https://identity.<region>.oci.oraclecloud.com <region>は、VMクラスタがデプロイされているOCIリージョンに対応します。 VMクラスタがアッシュバーン・リージョンにデプロイされている場合は、<region>に"us-ashburn-1"を使用する必要があります。 curlコマンドはcurl https://identity.us-ashburn-1.oci.oraclecloud.comのようになります。
Virtual Cloud Network (VCN)がOCI Services Networkにアクセスするように正しく構成されている場合は、次のようなレスポンスがただちに表示されます
```
{
 "code" : "NotAuthorizedOrNotFound",
 "message" : "Authorization failed or requested resource not found."
} 
```

ネットワークがOCIサービスにアクセスするように構成されていない場合、SSHセッションがハングし、最終的にタイムアウト
VCN設定に応じて、OCI Services Networkへのアクセスを構成するには、次のアクション・セクションで説明されているステップに従う必要があります。

Object Storage Service (OSS)接続の検証チェック:

ExaDB-D VMクラスタの仮想マシンにopcユーザーとしてsshします。
コマンドの実行 : curl https://objectstorage.<region>.oraclecloud.com、ここで<region>は、VMクラスタがデプロイされているOCIリージョンに対応します。 VMクラスタがアッシュバーン・リージョンにデプロイされている場合は、<region>に"us-ashburn-1"を使用する必要があります。 curlコマンドはcurl https://objectstorage.us-ashburn-1.oraclecloud.comのようになります。
Virtual Cloud Network (VCN)がOCI Services Networkにアクセスするように正しく構成されている場合は、次のようなレスポンスがただちに表示されます
```
{
 "code" : "NotAuthorizedOrNotFound",
 "message" : "Authorization failed or requested resource not found."
}
```

ネットワークがOCIサービスにアクセスするように構成されていない場合、SSHセッションがハングし、最終的にタイムアウト
VCN設定に応じて、OCI Services Networkへのアクセスを構成するには、次のアクション・セクションで説明されているステップに従う必要があります。

アクション:

このアクションは、VMクラスタをプライベート・サブネットにデプロイした顧客に適用されます。
OCI Services Networkにアクセスするようにサービス・ゲートウェイをまだ構成していない場合は、ドキュメントの手順を使用して、OCI Services https://docs.oracle.com/en/engineered-systems/exadata-cloud-service/ecscm/ecs-network-setup.html#GUID-51C3EC2C-20DA-4EE5-B882-CD500FA6F7C6にアクセスするためにVMクラスタで使用するサービス・ゲートウェイを構成
「このアクションは、VMクラスタをパブリック・サブネットにデプロイした顧客に適用されます」。
OCI Services Networkにアクセスするようにインターネット・ゲートウェイをまだ構成していない場合は、ドキュメントの手順を使用して、OCI Services https://docs.oracle.com/en/engineered-systems/exadata-cloud-service/ecscm/ecs-network-setup.html#GUID-D8296957-E344-4688-B626-42A99E1D164BにアクセスするためにVMクラスタで使用するようにインターネット・ゲートウェイを構成

前述の手順に従ってOCIサービス・ネットワークに到達するようにVCNを構成したら、両方の「検証チェック」セクションのステップを実行して、VMクラスタからOCIサービス・ネットワークへの接続を確立したことを確認します。

追加情報:

サービス・ゲートウェイは、「こちら」 (https://docs.oracle.com/en-us/iaas/Content/Network/Tasks/servicegateway.htm#switch_label)で更新する手順を確認できます

親トピック: Exadata Cloud Infrastructureシステムのトラブルシューティング

Exadata Database Service on Dedicated Infrastructureでのバックアップの失敗

Exadata管理対象バックアップが正常に完了しない場合は、このトピックの手順を使用して問題をトラブルシューティングおよび修正できます。

バックアップ失敗の最も一般的な原因は次のとおりです:

ホストがObject Storageにアクセスできない
ホストのデータベース構成が正しくない

次の情報は、エラー条件別に編成されています。すでに原因がわかっている場合は、推奨される解決策が記載された項にスキップできます。それ以外の場合は、「問題の特定」の手順を使用して開始します。

「問題の特定」
コンソールでは、失敗したデータベース・バックアップに「失敗」のステータスが表示されるか、「バックアップ進行中」または「作成中」状態でハングします。エラー・メッセージに解決策を示す十分な情報が含まれていない場合は、dbaascli を使用してログ・ファイルを表示することで、詳細情報を収集できます。解決策については、このトピックの該当する項を参照してください。
「データベース・サービス・エージェントの問題」
Oracle Cloud Infrastructureデータベースは、エージェント・フレームワークを使用して、クラウド・プラットフォームを介してデータベースを管理できるようにします。 dbcsagentを確認して再起動するには、次を使用します。
「オブジェクト・ストアの接続の問題」
データベースをOracle Cloud Infrastructure Object Storageにバックアップするには、ホストが該当するSwiftエンドポイントに接続できる必要があります。
「ホストの問題」
データベース・ホストでの次の条件の1つ以上が原因で、バックアップが失敗することがあります:
「データベースの問題」
データベースの状態または構成が正しくない場合、バックアップが失敗することがあります。
「TDE Walletおよびバックアップの失敗」
TDEウォレットの根本原因とバックアップの失敗を特定する方法について学習します。

親トピック: Exadata Cloud Infrastructureシステムのトラブルシューティング

問題の特定

コンソールでは、失敗したデータベース・バックアップに「失敗」のステータスが表示されるか、「バックアップ進行中」または「作成中」状態でハングします。エラー・メッセージに解決策を示す十分な情報が含まれていない場合は、dbaascli を使用してログ・ファイルを表示することで、詳細情報を収集できます。解決策については、このトピックの該当する項を参照してください。

データベース・バックアップは、RMAN構成ステージ中またはRMANバックアップ・ジョブの実行中に失敗する可能性があります。 RMAN構成タスクには、オブジェクト・ストア接続の検証、バックアップ・モジュールのインストールおよびRMAN構成の変更が含まれます。確認するログ・ファイルは、障害が発生したステージによって異なります。

rootユーザーとしてホストにログオンします。
該当するログ・ファイルを確認します:
- RMAN構成中に障害が発生した場合は、/var/opt/oracle/log/<database_name>/bkup/ディレクトリに移動し、bkup.logファイルを確認します。
- バックアップ・ジョブ中に障害が発生した場合は、/var/opt/oracle/log/<database_name>/obkup/ディレクトリに移動し、obkup.logファイルを確認します。

ノート:

bkupおよびobkupコマンドを実行するたびに個別のログ・ファイルが生成されますが、bkup.logおよびobkup.logは、最後に生成されたログ・ファイルを指すシンボリック・リンクです。
すべてのノードがオブジェクト・ストレージにバックアップ・ピースを送信するため、すべてのExadata DBシステム・コンピュート・ノードでログ・ファイルを確認してください。

親トピック: Exadata Database Service on Dedicated Infrastructureでのバックアップの失敗

データベース・サービス・エージェントの問題

Oracle Cloud Infrastructureデータベースは、エージェント・フレームワークを使用して、クラウド・プラットフォームを介してデータベースを管理できるようにします。 dbcsagentを確認して再起動するには、次を使用します。

バックアップの失敗を解決するためにステータスがstop/waitingの場合、dbcsagentプログラムの再起動が必要になることがあります。 /opt/oracle/dcs/log/dcs-agent.logファイルを表示して、エージェントの問題を識別します。

コマンド・プロンプトから、エージェントのステータスを確認します:
```
systemctl status dbcsagent.service
```
エージェントがstop/waiting状態の場合は、エージェントの再起動を試行します:
```
systemctl start dbcsagent.service
```
エージェントのステータスを再度確認して、ステータスがstop/runningであることを確認します:
```
systemctl status dbcsagent.service
```

親トピック: Exadata Database Service on Dedicated Infrastructureでのバックアップの失敗

オブジェクト・ストアの接続の問題

データベースをOracle Cloud Infrastructure Object Storageにバックアップするには、ホストが該当するSwiftエンドポイントに接続できる必要があります。

Oracleは管理対象バックアップのストレージ・バケットの実際のSwiftユーザー資格証明を制御しますが、リージョン内のオブジェクト・ストレージへの一般的な接続の検証は、オブジェクト・ストアの接続性が問題ではないことを示す適切なインジケータです。別のSwiftユーザーを使用して、この接続をテストできます。

テナンシにSwiftユーザーを作成します。認証トークンの操作に関する項を参照してください。
前のステップで作成したユーザーを使用して、次のコマンドを使用して、ホストがオブジェクト・ストアにアクセスできることを確認します。
```
curl -v -X HEAD -u <user_ID>:'<auth_token>' https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace>
```
使用する正しいリージョンについては、「Object StorageのFAQ」を参照してください。オブジェクト・ストレージ・ネームスペースの詳細は、「オブジェクト・ストレージのネームスペースについて」を参照してください。
オブジェクト・ストアに接続できない場合、オブジェクト・ストア接続の構成の詳細は、「Exadata Cloud Serviceでのバックアップの前提条件」のトピックを参照してください。

親トピック: Exadata Database Service on Dedicated Infrastructureでのバックアップの失敗

ホストの問題

データベース・ホストでの次の条件の1つ以上が原因で、バックアップが失敗することがあります:

oraenvなどの対話型コマンド、またはエラーまたは警告メッセージを返す可能性のあるコマンドが、グリッドまたはoracleユーザーの.bash_profileファイルに追加された場合、自動バックアップなどのデータベース・サービス操作は中断され、完了に失敗する可能性があります。 .bash_profileファイルでこれらのコマンドを確認し、削除します。

バックアップ操作には、ホスト・ファイル・システムの/u01ディレクトリに領域が必要です。ホストでdf -hコマンドを使用して、バックアップに使用可能な領域を確認します。ファイル・システムの領域が不十分な場合、古いログまたはトレース・ファイルを削除して領域を解放できます。

システムに必要なバージョンのバックアップ・モジュール(opc_installer.jar)がない可能性があります。この既知の問題の詳細は、「DB Systemで管理対象バックアップを使用できません」を参照してください。問題を修正するには、その項の手順に従うか、DBシステムおよびデータベースを最新のバンドル・パッチで更新します。

サイト・プロファイル・ファイル($ORACLE_HOME/sqlplus/admin/glogin.sql)を「カスタマイズ」すると、Oracle Cloud Infrastructureで管理対象バックアップが失敗する可能性があります。特に、対話型コマンドはバックアップの失敗の原因となることがあります。 Oracleでは、Oracle Cloud Infrastructureでホストされているデータベースに対してこのファイルを変更しないことをお薦めします。

親トピック: Exadata Database Service on Dedicated Infrastructureでのバックアップの失敗

データベースの問題

データベースの状態または構成が正しくない場合、バックアップが失敗することがあります。

バックアップの進行中は、データベースが(理想的にはすべてのノードで)アクティブで実行中である必要があります。

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

srvctl status database -d <db_unique_name> -verbose

データベース・インスタンスのステータスを含むメッセージが返されます。バックアップを成功させるには、インスタンス・ステータスがOpenである必要があります。データベースが稼働していない場合は、次のコマンドを使用して起動します:

srvctl start database -d <db_unique_name> -o open

データベースはマウントされているが、Openステータスがない場合は、次のコマンドを使用してSQL*Plusコマンド・プロンプトにアクセスし、ステータスをOpenに設定します:

sqlplus / as sysdba
alter database open;

新しいデータベースをプロビジョニングする場合、アーカイブ・モードはデフォルトでARCHIVELOGに設定されます。これは、バックアップ操作に必要なアーカイブ・モードです。データベースのアーカイブ・モード設定を確認し、該当する場合はARCHIVELOGに変更します。

SQL*Plusコマンド・プロンプトを開き、次のコマンドを入力します:

select log_mode from v$database;

アーカイブ・モードをARCHIVELOGに設定する必要がある場合は、(OPENステータスではなく)MOUNTステータスでデータベースを起動し、SQL*Plusコマンド・プロンプトで次のコマンドを使用します:

alter database archivelog;

db_recovery_file_destパラメータが+RECOを指し、log_archive_dest_1パラメータがUSE_DB_RECOVERY_FILE_DESTに設定されていることを確認します。

RACデータベースの場合、アーカイブ・ログ・モードを有効にするときに、1つのインスタンスのステータスがMOUNTである必要があります。 RACデータベースに対してアーカイブ・ログ・モードを有効にするには、次のステップを実行します:

すべてのデータベース・インスタンスを停止します:
```
srvctl stop database -d
```
マウント状態でデータベース・インスタンスの1つを起動します:
```
srvctl start instance -d <db_unique_name> -i <instance_name> -o mount
```
SQL*Plusコマンド・プロンプトにアクセスします:
```
sqlplus / as sysdba
```
アーカイブ・ログ・モードを有効にします:
```
alter database archivelog; 
exit;
```

データベースを停止します:

srvctl stop instance -d <db_unique_name> -i <instance_name>

すべてのデータベース・インスタンスを再起動します:
```
srvctl start database -d <db_unqiue_name>
```
SQL*Plusコマンド・プロンプトで、アーカイブ・モードが次のように設定されていることを確認 : ARCHIVELOG :
```
select log_mode from v$database;
```

データベース・インスタンスにスタックしたアーカイバ・プロセスがある場合、バックアップが失敗することがあります。たとえば、これはフラッシュ・リカバリ領域(FRA)がいっぱいの場合に発生します。 srvctl status database -db <db_unique_name> -vコマンドを使用して、この条件を確認できます。このコマンドから次の出力が返された場合、バックアップが成功するには、スタック・アーカイブ・プロセスの問題を解決する必要があります:

Instance <instance_identifier> is running on node *<node_identifier>. Instance status: Stuck Archiver

スタック・アーカイバ・プロセスの解決の詳細は、ORA-00257:Archiver Error (Doc ID 2014425.1)を参照してください。

スタック・プロセスを解決した後、コマンドからは次の出力が返されます:

Instance <instance_identifier> is running on node *<node_identifier>. Instance status: Open

デバイスまたはリソースがいっぱいまたは使用できないという根本的な問題を解決した後でインスタンス・ステータスが変更されない場合は、srvctlコマンドを使用してデータベースを再起動し、クラスタウェア内のデータベースのステータスを更新してみてください。

特定のRMAN構成パラメータを編集すると、Oracle Cloud Infrastructureでバックアップが失敗する可能性があります。 RMAN構成を確認するには、RMANコマンドライン・プロンプトでshow allコマンドを使用します。

Oracle Cloud Infrastructureのデータベースに対して変更しないRMANの構成設定の詳細は、次のパラメータのリストを参照してください。


CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 30 DAYS;

CONFIGURE CONTROLFILE AUTOBACKUP ON;

CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 5 BACKUP TYPE TO COMPRESSED BACKUPSET;

CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 2 G;

CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS  'SBT_LIBRARY=/var/opt/oracle/dbaas_acfs/<db_name>/opc/libopc.so, ENV=(OPC_PFILE=/var/opt/oracle/dbaas_acfs/<db_name>/opc/opc<db_name>.ora)';

CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO 'SBT_TAPE';

CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 2 G;

CONFIGURE ENCRYPTION FOR DATABASE ON;

オブジェクト・ストア・ウォレット・ファイルが失われると、RMANバックアップは失敗します。このオブジェクト・ストアへの接続を有効にするには、ウォレット・ファイルが必要です。

SQL*Plusを使用して、バックアップ失敗のデータベースの名前を取得します:
```
show parameter db_name
```
LinuxコマンドラインでRMANウォレット情報を含むバックアップ構成パラメータ・ファイルのファイル・パスを確認します:
```
locate opc_<database_name>.ora
```
たとえば:
```
find / -name "opctestdb30.ora" -print /var/opt/oracle/dbaas_acfs/testdb30/opc/opctestdb30.ora
```
OPC_WALLETパラメータに格納されている値を調べ、バックアップ構成パラメータ・ファイル内のウォレット・ファイルへのファイル・パスを見つけます。これを行うには、バックアップ構成パラメータ・ファイルを含むディレクトリに移動し、次のcatコマンドを使用します:
```
cat opc<database_name>.ora
```
たとえば:
```
cd /var/opt/oracle/dbaas_acfs/testdb30/opc/
```
```
ls -altr *.ora
opctestdb30.ora
```
```
cat opctestdb30.ora
OPC_HOST=https://swiftobjectstorage.us-phoenix-1.oraclecloud.com/v1/dbbackupphx
OPC_WALLET='LOCATION=file:/var/opt/oracle/dbaas_acfs/testdb30/opc/opc_wallet CREDENTIAL_ALIAS=alias_opc'
OPC_CONTAINER=bUG3TFsSi8QzjWfuTxqqExample
_OPC_DEFERRED_DELETE=false
```
cwallet.ssoファイルがOPC_WALLETパラメータで指定されたディレクトリに存在することを確認し、ファイルに正しい権限があることを確認します。ファイル・アクセス権には、8進数の値「600」(-rw-------)が必要です。次のコマンドを使用します。
```
ls -ltr /var/opt/oracle/dbaas_acfs/<database_name>/opc/opc_wallet
```
たとえば:
```
ls -altr /var/opt/oracle/dbaas_acfs/testdb30/opc/opc_wallet
-rw------- 1 oracle oinstall 0 Oct 29 01:59 cwallet.sso.lck
-rw------- 1 oracle oinstall 111231 Oct 29 01:59 cwallet.sso
```

親トピック: Exadata Database Service on Dedicated Infrastructureでのバックアップの失敗

TDE Walletおよびバックアップの失敗

TDEウォレットの根本原因とバックアップの失敗を特定する方法について学習します。

バックアップ操作が機能するには、$ORACLE_HOME/network/admin/sqlnet.oraファイルに、次のように書式設定されたENCRYPTION_WALLET_LOCATIONパラメータが含まれている必要があります:

ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/var/opt/oracle/dbaas_acfs/<database_name>/tde_wallet)))

catコマンドを使用して、TDEウォレットのロケーションの指定を確認します。たとえば:

$ cat $ORACLE_HOME/network/admin/sqlnet.ora 
ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/var/opt/oracle/dbaas_acfs/<database_name>/tde_wallet)))

TDEウォレットが適切な状態でない場合に、データベースのバックアップが失敗します。次のシナリオがこの問題の可能性があります:

データベースがSQL*Plusを使用して起動され、ORACLE_UNQNAME環境変数が設定されていない場合、ウォレットは正しく開かれません。

問題を解決するには、srvctlユーティリティを使用してデータベースを起動します:

srvctl start database -d <db_unique_name>

PDBレベルのキーストアをサポートするOracle Databaseバージョンのマルチテナント環境では、各PDBに独自のマスター暗号化キーがあります。 Oracle 18cデータベースの場合、この暗号化キーは、すべてのコンテナで使用される単一のキーストアに格納されます。 (Oracle Database 19cでは、PDBレベルのキーストアはサポートされていません。) 新しいPDBを作成した後、または新しいPDBに接続した後に、そのPDBのマスター暗号化キーを作成してアクティブ化する必要があります。そうしない場合、v$encryption_walletビューのSTATUS列に値OPEN_NO_MASTER_KEYが表示されます。

マスター暗号化キーのステータスを確認し、マスター・キーを作成するには、次の手順を実行します:

次の例に示すように、v$encryption_walletビューのSTATUS列を確認します:


SQL> alter session set container=pdb2;
Session altered.

SQL> select WRL_TYPE,WRL_PARAMETER,STATUS,WALLET_TYPE from v$encryption_wallet;

WRL_TYPE   WRL_PARAMETER                                   STATUS             WALLET_TYPE
---------- ----------------------------------------------- ------------------ -----------
FILE       /var/opt/oracle/dbaas_acfs/testdb30/tde_wallet/ OPEN_NO_MASTER_KEY AUTOLOGIN

次の例に示すように、PDBが読取り/書込みオープン・モードであり、制限されていないことを確認します:
```
SQL> show pdbs

CON_ID CON_NAME     OPEN MODE              RESTRICTED
------ ------------ ---------------------- ---------------
2      PDB$SEED     READ ONLY              NO
3      PDB1         READ WRITE             NO
4      PDB2         READ WRITE             NO
```
PDBを制限モードでオープンすることはできません(RESTRICTED列にNOが表示されている必要があります)。 PDBが現在制限モードの場合は、PDB_PLUG_IN_VIOLATIONSビューの情報を確認し、問題を解決してから続行します。 PDB_PLUG_IN_VIOLATIONSビューおよび制限付きステータスの詳細は、Oracle Databaseバージョンのプラガブル・データベースの「Oracle Multitenant管理者ガイド」を確認してください。
PDBのマスター暗号化キーを作成してアクティブ化します:
- コンテナをPDBに設定します:
```
ALTER SESSION SET CONTAINER = <pdb>;
```
- 次のコマンドを実行して、PDBのマスター暗号化キーを作成および有効化します。
```
ADMINISTER KEY MANAGEMENT SET KEY USING TAG '<tag>' 
FORCE KEYSTORE IDENTIFIED BY <keystore-password> WITH BACKUP USING '<backup_identifier>';
```
次の点に注意してください。
- USING TAG句はオプションであり、タグを新しいマスター暗号化キーに関連付けるために使用できます。
- WITH BACKUP句はオプションであり、新しいマスター暗号化キーが作成される前にキーストアのバックアップを作成するために使用できます。
dbaascliコマンドのdbaascli tde statusおよびdbaascli tde rotate masterkeyを使用して、キーを調査および管理することもできます。
ステップ1に示すようにv$encryption_walletビューを問い合せて、ウォレットのステータスがOPEN_NO_MASTER_KEYからOPENに変更されたことを確認します。

TDEウォレットに関連する構成パラメータによって、バックアップが失敗することがあります。

v$encryption_walletビューをチェックして、ウォレット・ステータスがopenで、ウォレット・タイプがauto loginであることを確認します。たとえば:


SQL> select status, wrl_parameter,wallet_type from v$encryption_wallet;

STATUS  WRL_PARAMETER                                  WALLET_TYPE
------- ---------------------------------------------- --------------
OPEN   /var/opt/oracle/dbaas_acfs/testdb30/tde_wallet/ AUTOLOGIN

プラガブル・データベース(PDB)の場合は、v$encryption_walletビューを問い合せる前に、適切なコンテナに切り替えてください。たとえば:


$ sqlplus / as sysdba

SQL> alter session set container=pdb1;

Session altered.

SQL> select WRL_TYPE,WRL_PARAMETER,STATUS,WALLET_TYPE from v$encryption_wallet;

WRL_TYPE  WRL_PARAMETER                                   STATUS   WALLET_TYPE
--------- ----------------------------------------------- -------- -----------
FILE      /var/opt/oracle/dbaas_acfs/testdb30/tde_wallet/ OPEN     AUTOLOGIN

TDEウォレット・ファイル(ewallet.p12)がない場合、またはファイル・システムの権限または所有権に互換性がない場合、バックアップが失敗することがあります。次の例に示すように、rootユーザーとしてファイルを確認します:

# ls -altr /var/opt/oracle/dbaas_acfs/<database_name>/tde_wallet/ewallet.p12
total 76
-rw------ 1 oracle oinstall 5467 Oct 1 20:17 ewallet.p12

TDEウォレット・ファイルには8進数値「600」(-rw-------)のファイル権限が必要であり、このファイルの所有者はoinstallオペレーティング・システム・グループに含まれている必要があります。

自動ログイン・ウォレット・ファイル(cwallet.sso)がない場合、またはファイル・システムの権限または所有権に互換性がない場合、バックアップが失敗する可能性があります。次の例に示すように、rootユーザーとしてファイルを確認します:


# ls -altr /var/opt/oracle/dbaas_acfs/<database_name>/tde_wallet/cwallet.sso
total 76
-rw------ 1 oracle oinstall 5512 Oct 1 20:18 cwallet.sso

自動ログイン・ウォレット・ファイルには8進数値「600」(-rw-------)のファイル権限が必要であり、このファイルの所有者はoinstallオペレーティング・システム・グループに含まれている必要があります。

親トピック: Exadata Database Service on Dedicated 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のトラブルシューティング」
問題の識別に使用するツールおよび関連するログ・ファイルのロケーションは、それらを使用するシナリオによって異なります。
「Data Guard設定プロセスのトラブルシューティング」
Data Guard設定プロセスの様々なステップで次のエラーが発生する可能性があります。一部のエラーはコンソール内に表示されますが、根本原因のほとんどはログ・ファイルで確認できます

親トピック: Exadata Cloud Infrastructureシステムのトラブルシューティング

ログ・ファイルを使用した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

親トピック: Oracle Data Guardのトラブルシューティング

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

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

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

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

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

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

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

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

クラスタがアクセス可能であることを確認します。クラスタのステータスをチェックするには、次のコマンドを実行します:
```
crsctl check cluster -all
```
クラスタが停止している場合は、次のコマンドを実行して再起動します:
```
crsctl start crs -wait
```
クラスタがアクセス可能なときにこのエラーが発生した場合は、ログで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別名を使用して接続を試みます。

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

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))))
```
別名を使用してデータベースに接続できることを確認します。たとえば、sysdbaとして次のコマンドを入力します:
```
sqlplus sys@db12c
```

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

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

TDEウォレットの問題の原因と解決策については、「TDE Walletおよびバックアップの失敗」を参照してください。

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

ノート

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

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

原因と解決策については、「データベース・エラー・メッセージ」のエラーを確認してください。

親トピック: Oracle Data Guardのトラブルシューティング

「Exadataクラウド・インフラストラクチャ」システムでのパッチ適用の失敗

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

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

親トピック: Exadata Cloud Infrastructureシステムのトラブルシューティング

問題の特定

コンソールで、「Exadataクラウド・インフラストラクチャ」システムまたは個々のデータベースのパッチ履歴を表示することで、失敗したパッチ適用操作を識別できます。

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

親トピック: Exadata Cloud Infrastructureシステムでのパッチ適用の失敗

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

「Exadataクラウド・インフラストラクチャ」コンポーネントのパッチ適用プロセス中に発生する可能性のある最も一般的な問題を診断します。

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

親トピック: Exadata Cloud Infrastructureシステムでのパッチ適用の失敗

データベース・サーバーの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サポート

親トピック: Exadata Cloud Infrastructureシステムのトラブルシューティング

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

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

DBAASCLIログ

/var/opt/oracle/log/dbaascli

dbaascli.log

親トピック: さらなる支援の取得

Oracle Diagnosticsの収集

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

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

関連トピック

DBAASツール: dbaascliを使用したクラウド・ツール・ログの収集およびクラウド・ツールのヘルス・チェックの実行

親トピック: さらなる支援の取得

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

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

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

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

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

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

My Oracle Supportにログインします。
「パッチと更新版」をクリックします。
「番号/名前またはバグ番号(シンプル)」ドロップダウン・リストから「バグ番号」を選択します。
バグ番号34741066を入力し、「検索」をクリックします。
検索結果から、最新のパッチの名前をクリックします。
「パッチ34741066: LSNRCTL RELOAD -WITH_HA LISTENER.ORA内の静的エントリの読み取りに失敗しました」ページにリダイレクトされます。
「ダウンロード」をクリックします。

親トピック: Exadata Cloud Infrastructureシステムのトラブルシューティング