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

1. rootユーザーとしてホストにログオンします。

2. 適切なログ・ファイルを確認します:

   • RMAN構成中に障害が発生した場合、/var/opt/oracle/log/<database_name>/bkup/ディレクトリに移動し、bkup.logファイルを確認します。
   • バックアップ・ジョブ中に障害が発生した場合、/var/opt/oracle/log/<database_name>/obkup/ディレクトリに移動し、obkup.logファイルを確認します。

1. コマンド・プロンプトで、エージェントのステータスを確認します:

   systemctl status dbcsagent.service

2. エージェントの状態が停止/待機中の場合、エージェントの再起動を試みます:

   systemctl start dbcsagent.service

3. エージェントのステータスを再度確認して、ステータスが停止/実行中であることを確認します:

   systemctl status dbcsagent.service

1. テナンシにSwiftユーザーを作成します。認証トークンの作業を参照してください。
2. 前のステップで作成したユーザーを使用して、次のコマンドを実行し、ホストがオブジェクト・ストアにアクセスできることを確認します。

   curl -v -X HEAD -u <user_ID>:'<auth_token>' https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace>

   使用する適切なリージョンについては、オブジェクト・ストレージのFAQを参照してください。オブジェクト・ストレージ・ネームスペースの詳細は、オブジェクト・ストレージ・ネームスペースの理解を参照してください。
3. オブジェクト・ストアに接続できない場合は、オブジェクト・ストアの接続性の構成に関するExadata Cloud Serviceでのバックアップの前提条件のトピックを参照してください。

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でホストされているデータベースでは、このファイルを変更しないことをお薦めします。

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

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

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バックアップは失敗します。オブジェクト・ストアへの接続を有効にするには、ウォレット・ファイルが必要です。

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

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

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が表示されます。

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

1. 次の例に示すように、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

2. 次の例に示すように、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管理者ガイド』を参照してください。

3. 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を使用して、キーを調査および管理することもできます。

4. ステップ1に示されているように、v$encryption_walletビューを問い合せて、ウォレットのステータスがOPEN_NO_MASTER_KEYからOPENに変更されたことを確認します。

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

# 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オペレーティング・システム・グループに含まれている必要があります。

# 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オペレーティング・システム・グループに含まれている必要があります。

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

• 有効化ステージのログ・ファイル(スタンバイ・データベースの作成操作のドキュメントなど)および対応するプライマリまたはスタンバイ・システムのログ。
• 有効化ジョブIDのログ・ファイル。例: 23。
• 有効化ステージおよびExadataシステム(プライマリまたはスタンバイ)別の有効化ログ・ファイルの場所。
• データベース名のログ・ファイル(ファイル・パスに応じてdb_name またはdb_unique_name)。

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)のログ・ファイルを収集します。

• データベース・アラート・ログ: /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を有効にするために入力したパスワードがSYSユーザーのプライマリ管理パスワードと一致しませんでした。このエラーは、有効化のプライマリの検証ステージ中に発生します。

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

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

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

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

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

1. クラスタがアクセス可能であることを確認します。クラスタのステータスをチェックするには、次のコマンドを実行します:

   crsctl check cluster -all

2. クラスタが停止している場合は、次のコマンドを実行して再起動します:

   crsctl start crs -wait

3. クラスタがアクセス可能なときにこのエラーが発生する場合は、TDEウォレットの作成(有効化ステージ)のログをチェックして、エラーの原因と解決策を確認します。

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

• スタンバイ・データベースを構成するためにプライマリ・サイトとスタンバイ・サイトが相互に通信できない可能性があります。これらのエラーは、有効化のスタンバイ・データベースの構成ステージ中に発生します。このステージでは、プライマリ・データベースのRMAN複製を含め、スタンバイ・データベースで構成が実行されます。この問題を解決するには:
  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

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

1. sysユーザーとしてデータベースに接続し、次でTDEステータスをチェックします

   V$ENCRYPTION_WALLET

   .
2. systemユーザーとしてデータベースに接続し、次でTDEステータスをチェックします

   V$ENCRYPTION_WALLET

   .
3. 該当するパスワードを更新して一致させます。opcとしてシステム・ホストにログオンし、次のコマンドを実行します:
   1. SYSパスワードを変更するには:

      sudo dbaascli database changepassword --dbname <database_name>

   2. TDEウォレット・パスワードを変更するには:

      sudo dbaascli tde changepassword --dbname <database_name>

TDEウォレットの問題の考えられる原因と解決策は、TDEウォレットおよびバックアップの失敗を参照してください。

スイッチオーバー、フェイルオーバーおよび回復コマンドを実行したときに、複数のエラー・メッセージが表示されることがあります。これらのエラー・メッセージについては、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 Applyが停止しています。
   • ORA-16853: 適用ラグが指定されたしきい値を超えました。
   • ORA-16664: メンバーから結果を受信できません(スタンバイ・データベース)。
   • ORA-12541: TNS: リスナーがありません(プライマリ・データベース)

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

DBAASCLIログ