Exadata Cloud Infrastructureシステムのトラブルシューティング
これらのトピックでは、発生する可能性がある一般的な問題とその対処方法について説明します。
- Exadata Cloud Infrastructureの既知の問題
一般的な既知の問題。 - ネットワーク接続のトラブルシューティング
Oracle Cloud Infrastructure (OCI) Services NetworkにアクセスするようにVMクラスタが適切に構成されているかどうかを判断するには、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の既知の問題
一般的な既知の問題。
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です。
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
パラメータには、2つのIPアドレス(<IP address 1>または<IP address 2>)のいずれかを指定できます。
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.
原因: インストーラによって、Autonomous Health Framework (AHF)で作成された読取り不可能なトレース・ファイルoracle.ahf/data/scaqak03dv0104/diag/tfa/tfactl/user_root/tfa_client.trc
がOracleホームに検出され、クラスタVMの追加が失敗します。
root
として実行されたAHFは、root
の所有権でtrc
ファイルを作成しているため、grid
ユーザーは読み取ることができません。
grid
ユーザーがAHFトレース・ファイルを読取り可能であることを確認してください。権限の問題を修正するには、既存のすべての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*
ネットワーク接続のトラブルシューティング
Oracle Cloud Infrastructure (OCI) Services NetworkにアクセスするようにVMクラスタが適切に構成されているかどうかを確認するには、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
のようになります。 - 仮想クラウド・ネットワーク(VCN)がOCIサービス・ネットワークにアクセスするように適切に構成されている場合は、次のようなレスポンスがすぐに取得されます
{ "code" : "NotAuthorizedOrNotFound", "message" : "Authorization failed or requested resource not found." }
- ネットワークがOCIサービスにアクセスするように構成されていない場合、SSHセッションがハングし、最終的にタイムアウトします
- VCN設定に応じて、OCIサービス・ネットワークへのアクセスを構成するには、次の処置の項で説明されているステップに従う必要があります。
オブジェクト・ストレージ・サービス(OSS)接続の検証チェック:
opc
ユーザーとして、ExaDB-D VMクラスタの仮想マシンにsshで接続します。- コマンド
curl https://objectstorage.<region>.oraclecloud.com
を実行します。ここで、<region>は、VMクラスタがデプロイされているOCIリージョンに対応します。VMクラスタがアッシュバーン・リージョンにデプロイされている場合は、<region>に"us-ashburn-1"を使用する必要があります。curlコマンドはcurl https://objectstorage.us-ashburn-1.oraclecloud.com
のようになります。 - 仮想クラウド・ネットワーク(VCN)がOCIサービス・ネットワークにアクセスするように適切に構成されている場合は、次のようなレスポンスがすぐに取得されます
{ "code" : "NotAuthorizedOrNotFound", "message" : "Authorization failed or requested resource not found." }
- ネットワークがOCIサービスにアクセスするように構成されていない場合、SSHセッションがハングし、最終的にタイムアウトします
- VCN設定に応じて、OCIサービス・ネットワークへのアクセスを構成するには、次の処置の項で説明されているステップに従う必要があります。
処置:
- この処置は、プライベート・サブネットにVMクラスタをデプロイした顧客に適用されます。
OCIサービス・ネットワークにアクセスするようにサービス・ゲートウェイをまだ構成していない場合は、ドキュメントの手順を使用して、VMクラスタが使用するサービス・ゲートウェイを構成し、OCIサービスhttps://docs.oracle.com/en/engineered-systems/exadata-cloud-service/ecscm/ecs-network-setup.html#GUID-51C3EC2C-20DA-4EE5-B882-CD500FA6F7C6にアクセスします
- この処置は、パブリック・サブネットにVMクラスタをデプロイした顧客に適用されます。
OCIサービス・ネットワークにアクセスするようにインターネット・ゲートウェイをまだ構成していない場合は、ドキュメントの手順を使用して、VMクラスタが使用するインターネット・ゲートウェイを構成し、OCIサービスhttps://docs.oracle.com/en/engineered-systems/exadata-cloud-service/ecscm/ecs-network-setup.html#GUID-D8296957-E344-4688-B626-42A99E1D164Bにアクセスします
前述の手順に従ってOCIサービス・ネットワークにアクセスするようにVCNを構成したら、2つの検証チェックの項のステップを実行して、VMクラスタからOCIサービス・ネットワークへの接続を確立したことを確認します。
追加情報:
サービス・ゲートウェイを更新する手順は、ここ(https://docs.oracle.com/en-us/iaas/Content/Network/Tasks/servicegateway.htm#switch_label)にあります
Exadata Database Service on Dedicated Infrastructureでのバックアップの失敗
Exadata管理バックアップが正常に完了しない場合は、このトピックの手順を使用して問題をトラブルシューティングおよび修正できます。
バックアップの失敗の最も一般的な原因は次のとおりです:
- ホストがオブジェクト・ストレージにアクセスできません
- ホストのデータベース構成が正しくありません
この後の情報は、エラー状態別に整理されています。すでに原因がわかっている場合は、推奨される解決策が記載された項にスキップできます。そうでない場合は、問題の特定の手順を使用して開始します。
- 問題の特定
コンソールで、失敗したデータベース・バックアップは、「失敗」のステータスが表示されるか、「バックアップ進行中」または「作成中」の状態でハングします。エラー・メッセージに解決策を示す十分な情報が含まれていない場合は、dbaascli
を使用したりログ・ファイルを表示することで、詳細情報を収集できます。その後、解決策についてこのトピックの該当する項を参照してください。 - データベース・サービス・エージェントの問題
Oracle Cloud Infrastructureデータベースでは、エージェント・フレームワークを使用して、クラウド・プラットフォームを通じてデータベースを管理できます。エージェントを確認して再起動するには、次を使用します。 - オブジェクト・ストア接続の問題
データベースをOracle Cloud Infrastructure Object Storageにバックアップするには、ホストが適切なSwiftエンドポイントに接続できる必要があります。 - ホストの問題
データベース・ホストにおける次の1つ以上の状況が原因で、バックアップに失敗することがあります: - データベースの問題
不適切なデータベースの状態または構成によって、バックアップが失敗する可能性があります。 - TDEウォレットおよびバックアップの失敗
TDEウォレットとバックアップの失敗の根本原因の特定について学習します。
問題の特定
コンソールで、失敗したデータベース・バックアップは、「失敗」のステータスが表示されるか、「バックアップ進行中」または「作成中」の状態でハングします。エラー・メッセージに解決策を示す十分な情報が含まれていない場合は、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システムのコンピュート・ノードでログ・ファイルを確認してください。
データベース・サービス・エージェントの問題
Oracle Cloud Infrastructureデータベースでは、エージェント・フレームワークを使用して、クラウド・プラットフォームを通じてデータベースを管理できます。エージェントを確認して再起動するには、次を使用します。
ステータスが停止/待機中の場合、状況によってはバックアップの失敗を解決するためにdcsagentプログラムを再起動する必要があります。/opt/oracle/dcs/log/dcs-agent.log
ファイルを表示して、エージェントの問題を識別します。
- コマンド・プロンプトで、エージェントのステータスを確認します:
systemctl status dbcsagent.service
- エージェントの状態が停止/待機中の場合、エージェントの再起動を試みます:
systemctl start dbcsagent.service
- エージェントのステータスを再度確認して、ステータスが停止/実行中であることを確認します:
systemctl status dbcsagent.service
オブジェクト・ストア接続の問題
データベースをOracle Cloud Infrastructure Object Storageにバックアップするには、ホストが適切なSwiftエンドポイントに接続できる必要があります。
管理対象バックアップのストレージ・バケットについて、実際のSwiftユーザー資格証明はOracleによって制御されますが、リージョン内のオブジェクト・ストレージへの一般的な接続性を検証することは、オブジェクト・ストアの接続性が問題ではないことの判断材料になります。別のSwiftユーザーを使用して、この接続性をテストできます。
- テナンシにSwiftユーザーを作成します。認証トークンの作業を参照してください。
- 前のステップで作成したユーザーを使用して、次のコマンドを実行し、ホストがオブジェクト・ストアにアクセスできることを確認します。
使用する適切なリージョンについては、オブジェクト・ストレージのFAQを参照してください。オブジェクト・ストレージ・ネームスペースの詳細は、オブジェクト・ストレージ・ネームスペースの理解を参照してください。curl -v -X HEAD -u <user_ID>:'<auth_token>' https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace>
- オブジェクト・ストアに接続できない場合は、オブジェクト・ストアの接続性の構成に関するExadata Cloud Serviceでのバックアップの前提条件のトピックを参照してください。
ホストの問題
データベース・ホストにおける次の1つ以上の状況が原因で、バックアップに失敗することがあります:
oraenv
などの対話型コマンド、またはエラー・メッセージや警告メッセージを返すことのあるコマンドが、gridまたはoracleユーザーの.bash_profile
ファイルに追加された場合、自動バックアップなどのデータベース・サービス操作は中断され、完了できない可能性があります。これらのコマンドの.bash_profile
ファイルを確認して削除してください。
バックアップ操作には、ホスト・ファイル・システム上の/u01
ディレクトリの領域が必要です。バックアップに使用可能な領域を確認するには、ホストでdf -h
コマンドを使用します。ファイル・システムの領域が不十分な場合、古いログまたはトレース・ファイルを削除して領域を解放できます。
システムには、必要なバージョンのバックアップ・モジュール(opc_installer.jar
)がない可能性があります。この既知の問題の詳細は、DBシステムで管理対象バックアップを使用できませんを参照してください。問題を解決するには、この項の手順を実行するか、DBシステムおよびデータベースを最新のバンドル・パッチで更新します。
サイト・プロファイル・ファイル($ORACLE_HOME/sqlplus/admin/glogin.sql
)をカスタマイズすると、管理対象バックアップがOracle Cloud Infrastructureで失敗する可能性があります。特に、対話型コマンドはバックアップの失敗の原因となることがあります。Oracle Cloud 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
に変更します。
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;
srvctl status database -db <db_unique_name> -v
コマンドを使用して確認できます。このコマンドから次の出力が返された場合、バックアップが成功するには、スタック・アーカイバ・プロセスの問題を解決する必要があります:
Instance <instance_identifier> is running on node *<node_identifier>. Instance status: Stuck Archiver
スタック・アーカイバ・プロセスの解決方法の詳細は、ORA-00257: アーカイバ・エラー(ドキュメント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
TDEウォレットおよびバックアップの失敗
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を作成またはプラグインした後に、そのマスター暗号化キーを作成してアクティブ化する必要があります。そうしない場合、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がREAD WRITEオープン・モードであり、制限されていないことを確認します:
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データベース・バージョンのプラガブル・データベースについて『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
を使用して、キーを調査および管理することもできます。 - コンテナをPDBに設定します:
-
ステップ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
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
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
オペレーティング・システム・グループに含まれている必要があります。
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設定プロセスの様々なステップで次のエラーが発生する可能性があります。一部のエラーはコンソール内に表示されますが、根本原因のほとんどはログ・ファイルで確認できます
ログ・ファイルを使用したData Guardのトラブルシューティング
問題の識別に使用するツールおよび関連するログ・ファイルの場所は、それらが使用されるシナリオによって異なります。
次の手順を使用して、関連するログ・ファイルを収集し、問題を調査します。ログ・ファイルを調査しても問題を解決できない場合は、My Oracle Supportに連絡してください。
収集したファイルをOracleサポート用に準備する場合は、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
コマンドライン・ユーティリティのスタンバイ・ログの1つは、/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 Deployment Engine (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ウォレットの作成ステージ中に発生します。次のいずれかの項目が、このステージで失敗する原因となっている可能性があります:
- TDEウォレット・ファイルにアクセスできませんでした
- 有効化コマンドでウォレット・ファイルを含むアーカイブを作成できませんでした
トラブルシューティング手順:
- クラスタがアクセス可能であることを確認します。クラスタのステータスをチェックするには、次のコマンドを実行します:
crsctl check cluster -all
- クラスタが停止している場合は、次のコマンドを実行して再起動します:
crsctl start crs -wait
- クラスタがアクセス可能なときにこのエラーが発生する場合は、TDEウォレットの作成(有効化ステージ)のログをチェックして、エラーの原因と解決策を確認します。
TDEウォレットを含むアーカイブがスタンバイ・サイトに転送されなかった可能性があります。通常、再試行すると問題が解決します。
- スタンバイ・データベースを構成するためにプライマリ・サイトとスタンバイ・サイトが相互に通信できない可能性があります。これらのエラーは、有効化のスタンバイ・データベースの構成ステージ中に発生します。このステージでは、プライマリ・データベースのRMAN複製を含め、スタンバイ・データベースで構成が実行されます。この問題を解決するには:
- プライマリ・サイトとスタンバイ・サイトの接続ステータスを確認します。
- ホストがポート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
このエラーの考えられる原因は、データベースとTDEウォレットのOracle Database sysまたはsystemユーザー・パスワードが同じでない可能性があることです。パスワードを比較するには:
- sysユーザーとしてデータベースに接続し、次でTDEステータスをチェックします
.V$ENCRYPTION_WALLET
- systemユーザーとしてデータベースに接続し、次でTDEステータスをチェックします
.V$ENCRYPTION_WALLET
- 該当するパスワードを更新して一致させます。opcとしてシステム・ホストにログオンし、次のコマンドを実行します:
- SYSパスワードを変更するには:
sudo dbaascli database changepassword --dbname <database_name>
- TDEウォレット・パスワードを変更するには:
sudo dbaascli tde changepassword --dbname <database_name>
- SYSパスワードを変更するには:
TDEウォレットの問題の考えられる原因と解決策は、TDEウォレットおよびバックアップの失敗を参照してください。
スイッチオーバー、フェイルオーバーおよび回復コマンドを実行したときに、複数のエラー・メッセージが表示されることがあります。これらのエラー・メッセージについては、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 Applyが停止しています。
- ORA-16853: 適用ラグが指定されたしきい値を超えました。
- ORA-16664: メンバーから結果を受信できません(スタンバイ・データベース)。
- ORA-12541: TNS: リスナーがありません(プライマリ・データベース)
原因と解決策については、データベース・エラー・メッセージでこれらのエラーを確認してください。
Exadata Cloud Infrastructureシステムでのパッチ適用の失敗
パッチ適用操作は、様々な理由で失敗することがあります。通常、データベース・ノードが停止している、ファイル・システムの領域が不足している、または仮想マシンがオブジェクト・ストアにアクセスできないといった理由から、操作は失敗します。
- 問題の特定
コンソールで、Exadata Cloud Infrastructureシステムまたは個々のデータベースのパッチ履歴を表示して、失敗したパッチ適用操作を識別できます。 - トラブルシューティングおよび診断
Exadata Cloud Infrastructureコンポーネントのパッチ適用プロセス中に発生する可能性のある最も一般的な問題を診断します。
問題の特定
コンソールで、Exadata Cloud Infrastructureシステムまたは個々のデータベースのパッチ履歴を表示して、失敗したパッチ適用操作を識別できます。
正常に適用されなかったパッチには「失敗」
のステータスが表示され、失敗の原因となったエラーの簡単な説明が示されます。エラー・メッセージに解決策を示す十分な情報が含まれていない場合は、データベースCLIおよびログ・ファイルを使用して、さらに多くのデータを収集できます。その後、解決策についてこのトピックの該当する項を参照してください。
トラブルシューティングおよび診断
Exadata Cloud Infrastructureコンポーネントのパッチ適用プロセス中に発生する可能性のある最も一般的な問題を診断します。
- データベース・サーバーVMの問題
データベース・サーバーVMにおける次の1つ以上の状況が原因で、パッチ適用操作に失敗することがあります。 - Oracle Grid Infrastructureの問題
Oracle Grid Infrastructureにおける次の1つ以上の状況が原因で、パッチ適用操作に失敗することがあります。 - Oracle Databaseの問題
データベースの状態が適切ではない場合、パッチ適用に失敗することがあります。
データベース・サーバーVMの問題
データベース・サーバーVMにおける次の1つ以上の状況が原因で、パッチ適用操作に失敗することがあります。
データベース・サーバーVMの接続の問題
クラウド・ツールは、特定のVMクラスタの仮想マシン間の適切なネットワークおよび接続構成に依存します。構成が正しく設定されていない場合、ノード間処理を必要とするすべての操作で障害が発生する可能性があります。たとえば、特定のパッチの適用に必要なファイルをダウンロードできないことがあります。
この場合、次のアクションを実行できます:
- 関連する仮想マシン・アドレスをVMクラスタ内で解決できるように、DNS構成が正しいことを確認します。
- 追加のサポートが必要な場合の項の説明に従って関連するクラウド・ツールのログを参照し、Oracleサポートに連絡してください。
親トピック: トラブルシューティングおよび診断
Oracle Grid Infrastructureの問題
Oracle Grid Infrastructureにおける次の1つ以上の状況が原因で、パッチ適用操作に失敗することがあります。
Oracle Grid Infrastructureが停止している
Oracle Clusterwareを使用すると、複数のサーバーが相互に通信することにより、1つの集合単位として機能することができます。パッチ適用操作を完了するには、VMクラスタでクラスタ・ソフトウェア・プログラムが稼働している必要があります。場合によっては、Oracle Clusterwareを再起動してパッチ適用の失敗を解決する必要があります。
./crsctl check cluster
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online
crsctl start cluster -all
crsctl check cluster
親トピック: トラブルシューティングおよび診断
Oracle Databaseの問題
データベースの状態が適切ではない場合、パッチ適用に失敗することがあります。
Oracle Databaseが停止している
クラスタ全体でパッチ適用操作を正常に完了するには、データベースがアクティブで、すべてのアクティブ・ノードで実行されている必要があります。
srvctl status database -d db_unique_name -verbose
データベースのインスタンス・ステータスを含むメッセージが返されます。パッチ適用操作が成功するためには、インスタンス・ステータスがオープンである必要があります。
srvctl start database -d db_unique_name -o open
親トピック: トラブルシューティングおよび診断
追加のサポートが必要な場合
このトピックの情報を使用して問題を解決できなかった場合は、次の手順に従って、関連するデータベースおよび診断情報を収集します。この情報を収集したら、Oracleサポートに連絡してください。
- クラウド・ツールのログの収集
関連するログ・ファイルを使用して、特定の問題の詳細な調査および解決のためにOracleサポートを支援できます。 - Oracle診断情報の収集
関連トピック
クラウド・ツールのログの収集
関連するログ・ファイルを使用して、特定の問題の詳細な調査および解決のためにOracleサポートを支援できます。
DBAASCLIログ
/var/opt/oracle/log/dbaascli
dbaascli.log
親トピック: 追加のサポートが必要な場合
Oracle Database 11g Oracle Data Guard設定でのスイッチオーバー後にスタンバイ・データベースの再起動に失敗する
説明: スイッチオーバーの実行後、新しいスタンバイ(古いプライマリ)データベースは停止したままになり、再起動に失敗します。
処置: スイッチオーバーの実行後、次を実行します:
srvctl start database -db <standby dbname>
コマンドを使用してスタンバイ・データベースを再起動します。- すべてのプライマリおよびスタンバイ・クラスタ・ノードで
grid
ユーザーとしてリスナーをリロードします。- 高可用性を使用してリスナーをリロードするには、パッチ25075940をダウンロードしてGridホームに適用し、
lsnrctl reload -with_ha
を実行します。 - リスナーをリロードするには、
lsrnctl reload
を実行します。
- 高可用性を使用してリスナーをリロードするには、パッチ25075940をダウンロードしてGridホームに適用し、
リスナーのリロード後、lsnrctl status
コマンドを使用して、<dbname>_DGMGRL
サービスがリスナーにロードされていることを確認します。
パッチ25075940をダウンロードするには
- My Oracle Supportにログインします。
- 「パッチと更新版」をクリックします。
- 「番号/名前またはバグ番号(簡易)」ドロップダウン・リストから「バグ番号」を選択します。
- バグ番号34741066を入力し、「検索」をクリックします。
- 検索結果から、最新のパッチの名前をクリックします。
パッチ34741066: LSNRCTL RELOAD -WITH_HA FAILED TO READ THE STATIC ENTRY IN LISTENER.ORAページにリダイレクトされます。
- 「ダウンロード」をクリックします。