バックアップの失敗のトラブルシューティング
データベース・バックアップは、様々な理由で失敗することがあります。 通常、データベース・ホストがオブジェクト・ストアにアクセスできないか、ホストまたはデータベース構成に問題があるため、バックアップは失敗します。
この記事には、失敗の原因の特定と問題の修正に役立つ情報が含まれています。 情報は、エラー条件に基づいて複数の項で編成されます。
すでに原因がわかっている場合は、推奨される解決策が記載されたトピックにスキップできます。 それ以外の場合は、「失敗の原因の特定」トピックを使用して開始します。
この記事では、次のトピックについて説明します:
- 失敗の原因の特定
- データベース・サービス・エージェントの問題
- オブジェクト・ストアの接続の問題
- ホストの問題
- Oracle Clusterware問題
- データベースの問題
- TDE Walletの問題
- バックアップの失敗のその他の原因
- 追加ヘルプの表示
ヒント:
シリアル・コンソール接続を作成して、シングル・ユーザー・モードでシステムのトラブルシューティングを行うこともできます。 OCIコンソールでのシリアル・コンソール接続の作成の詳細は、「DB Systemへのシリアル・コンソール接続の管理」を参照してください。失敗の原因の特定
OCIコンソールでは、失敗したデータベース・バックアップに「失敗」のステータスが表示されるか、「バックアップ進行中」または「作成中」状態でハングします。 エラー・メッセージにソリューションを指し示すのに十分な情報が含まれていない場合は、データベースCLIおよびログ・ファイルを使用して、より多くのデータを収集できます。 解決策については、このトピックの該当する項を参照してください。
内容は、次のとおりです。
バックアップ失敗の根本原因の特定
-
rootユーザーとしてホストにログオンし、
/opt/oracle/dcs/bin/に移動します。 -
データベースで実行される操作の順序を決定します。
dbcli list-jobs | grep -i <dbname>「成功」以外のステータスでリストされた最後のジョブIDに注意してください。
-
前のステップでノートしたジョブIDを使用して、次のコマンドを使用してそのジョブの詳細を確認します:
dbcli describe-job -i <job_ID> -j通常、このコマンドを実行すると、失敗の根本原因は十分に明らかになります。
-
詳細は、
/opt/oracle/dcs/log/dcs-agent.logファイルを確認してください。このファイルのジョブIDは、ステップ2のジョブ・レポートから返されたタイムスタンプを使用して検索できます。
-
問題の詳細にRMANの問題が示されている場合は、次のディレクトリのRMANログを確認します。
/opt/oracle/dcs/log/<hostname>/rman/bkup/<db_unique_name>/rman_backup/<yyyy-mm-dd>
ノート:
データベースの失敗が2ノードのRACデータベース上にある場合、両方のノード上でステップ3および4を実行します。データベース・サービス・エージェントの問題
OCIデータベースでは、エージェント・フレームワークを使用して、クラウド・プラットフォームを介してデータベースを管理できます。 バックアップの失敗を解決するためにステータスがstop/waitingの場合、dcsagentプログラムの再起動が必要になることがあります。
内容は、次のとおりです。
データベース・サービス・エージェントの再起動
ノート:
OL6を使用する場合は、systemctlのかわりにinitctlを使用します。
-
コマンド・プロンプトから、エージェントのステータスを確認します:
systemctl status initdcsagent -
エージェントがstop/waiting状態の場合は、エージェントの再起動を試行します:
systemctl start initdcsagent -
エージェントのステータスを再度確認して、ステータスがstart/runningであることを確認します:
systemctl status initdcsagent
Oracle Clusterware問題
Oracle Clusterwareを使用すると、サーバーは相互に通信できるため、集合ユニットとして機能します。 場合によっては、バックアップの失敗を解決するためにClusterwareプログラムの再起動が必要になることがあります。
データベース・ホストでの次の条件の1つ以上が原因で、バックアップが失敗することがあります:
Oracle Clusterwareを再起動
-
コマンド・プロンプトから、Oracle Clusterwareのステータスを確認します:
crsctl check crscrsctl stat res -t -
Oracle Clusterwareがオンラインでない場合は、プログラムを再起動してみてください:
crsctl start crs -
Oracle Clusterwareのステータスをチェックして、オンラインであることを確認します:
crsctl check crs
オブジェクト・ストアの接続の問題
データベースをOCI Object Storageにバックアップするには、ホストが該当する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」を参照してください。
- オブジェクト・ストレージ・ネームスペースの詳細は、「オブジェクト・ストレージのネームスペースについて」を参照してください。
- オブジェクト・ストアに接続できない場合は、オブジェクト・ストアの接続を構成する方法について「コンソールを使用したデータベースのバックアップ」を参照してください。
ホストの問題
内容は、次のとおりです。
データベース・ホストでの次の条件の1つ以上が原因で、バックアップが失敗することがあります:
Oracleプロファイルの対話型コマンド
oraenvなどの対話型コマンド、またはエラーまたは警告メッセージを返す可能性のあるコマンドが、グリッドまたはoracleユーザーの.bash_profileファイルに追加された場合、自動バックアップなどのデータベース・サービス操作は中断され、完了に失敗する可能性があります。 .bash_profileファイルでこれらのコマンドを確認し、削除します。
ファイル・システムの空き容量がない
バックアップ操作には、ホスト・ファイル・システムの/u01ディレクトリに領域が必要です。 ホストでdf -hコマンドを使用して、バックアップに使用可能な領域を確認します。 ファイル・システムの領域が不十分な場合、古いログまたはトレース・ファイルを削除して領域を解放できます。
Oracle Database Cloudバックアップ・モジュールのバージョンが正しくありません
システムに必要なバージョンのバックアップ・モジュール(opc_installer.jar)がない可能性があります。 この既知の問題については、「DBシステムで管理対象バックアップを使用できません」を参照してください。 問題を修正するには、その項の手順に従うか、DBシステムおよびデータベースを最新のバンドル更新で単に更新します。
サイト・プロファイル・ファイルの変更(glogin.sql)
サイト・プロファイル・ファイル($ORACLE_HOME/sqlplus/admin/glogin.sql)をカスタマイズすると、OCIで管理対象バックアップが失敗する可能性があります。 「SQL*Plus構成」を参照してください。 特に、対話型コマンドはバックアップの失敗の原因となることがあります。 Oracleでは、OCIでホストされているデータベースに対してこのファイルを変更しないことをお薦めします。
データベースの問題
データベースの状態または構成が正しくない場合、バックアップが失敗することがあります。
内容は、次のとおりです。
バックアップ中にデータベースが実行されていない
バックアップの進行中は、データベースが(理想的にはすべてのノードで)アクティブで実行中である必要があります。
データベースがアクティブで実行中であることの確認
次のコマンドを使用して、データベースの状態を確認し、データベースを不適切な状態にした可能性のある問題が解決されていることを確認します:
srvctl status database -d <db_unique_name> -verboseデータベース・インスタンスのステータスを含むメッセージが返されます。 バックアップを成功させるには、インスタンス・ステータスが「オープン」である必要があります。 データベースが稼働していない場合は、次のコマンドを使用して起動します:
srvctl start database -d <db_unique_name> -o openデータベースがマウントされているが、オープンステータスがない場合は、次のコマンドを使用してSQL*Plusコマンド・プロンプトにアクセスし、ステータスをオープンに設定します:
sqlplus / as sysdbaalter database open;アーカイブ・モードをNOARCHIVELOGに設定
新しいデータベースをプロビジョニングする場合、アーカイブ・モードはデフォルトでARCHIVELOGに設定されます。 これは、バックアップ操作に必要なアーカイブ・モードです。 データベースのアーカイブ・モード設定を確認し、該当する場合はARCHIVELOGに変更します。
アーカイブ・モードの確認および設定
SQL*Plusコマンド・プロンプトを開き、次のコマンドを入力します:
select log_mode from v$database;アーカイブ・モードをARCHIVELOGに設定する必要がある場合は、(「オープン」ステータスではなく)「マウント」ステータスでデータベースを起動し、SQL*Plusコマンド・プロンプトで次のコマンドを使用します:
alter database archivelog;db_recovery_file_destパラメータが+RECOを指し、log_archive_dest_1パラメータがUSE_DB_RECOVERY_FILE_DESTに設定されていることを確認します。
RACデータベースの場合、アーカイブ・ログ・モードを有効にするときに、1つのインスタンスのステータスが「マウント」である必要があります。 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コマンドを使用してデータベースを再起動し、クラスタウェア内のデータベースのステータスを更新- 最新のパッチセット・レベルにデータベースをアップグレード
一時表領域エラー
固定表統計がデータベースで最新でない場合、dcs-agent.logファイルにある一時表領域を参照するエラーでバックアップが失敗する可能性があります。 たとえば:
select status from v$rman_status where COMMAND_ID=<backup_id>出力:
ERROR at line 1:
ORA-01652: unable to extend temp segment by 128 in tablespace TEMPこの問題を解決するには、次のように固定表の統計情報を収集します。
conn / as sysdbaexec dbms_stats.gather_fixed_objects_stats();RMAN構成およびバックアップの失敗
特定のRMAN構成パラメータを編集すると、OCIでバックアップが失敗することがあります。 RMAN構成を確認するには、RMANコマンドライン・プロンプトでshow allコマンドを使用します。
OCIのデータベースに対して変更すべきでないRMAN構成設定の詳細は、次のパラメータのリストを参照してください。
変更する必要のない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' MAXPIECESIZE 2 G FORMAT '%d_%I_%U_%T_%t' PARMS
'SBT_LIBRARY=/opt/oracle/dcs/commonstore/pkgrepos/oss/odbcs/libopc.so
ENV=(OPC_PFILE=/opt/oracle/dcs/commonstore/objectstore/opc_pfile/1578318329/opc_tiger_iad3c8.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保存ポリシーおよびバックアップの失敗
RMAN保持ポリシー構成がバックアップの失敗の原因である可能性があります。 RECOVERY WINDOWポリシーではなくREDUNDANCY保存ポリシー構成を使用すると、バックアップが失敗することがあります。 30日分の回復ウィンドウ構成を使用してください。
RMAN保存ポリシー設定の構成
-
次のコマンドを使用して、データベースIDを検索します:
dbcli list-databases -
次のコマンドを使用して、データベースの
BackupConfigId値を検索します:dbcli describe-database -i <database_id> -
保持ポリシー構成を
RECOVERY WINDOW OF 30 DAYSに更新します:dbcli update-backupconfig -i <backup_config_id> --recoverywindow 30
オブジェクト・ストアWalletファイルの損失とバックアップの失敗
オブジェクト・ストア・ウォレット・ファイルが失われると、RMANバックアップは失敗します。 このオブジェクト・ストアへの接続を有効にするには、ウォレット・ファイルが必要です。
オブジェクト・ストアのWalletファイルが存在し、適切な権限があることを確認
-
次のコマンドを使用して、データベースIDを検索します:
dbcli list-databases -
次のコマンドを使用して、データベースの
BackupConfigId値を検索します:dbcli describe-database -i <database_id> -
次のコマンドを使用して、データベースの
BackupLocation値を検索します:dbcli describe-backupconfig <backup_config_id> -
次のコマンドを使用して、バックアップ構成パラメータ・ファイル(
opc_<backup_location_value>_BC.ora)のファイル・パスを検索します:locate opc_<backup_location_value>_BC.oraたとえば:
locate opc_b9naijWMAXzi9example_BC.ora出力:
/opt/oracle/dcs/commonstore/objectstore/opc_pfile/13aef284-9d6b-4eb6-8751-2988a9example/opc_b9naijWMAXzi9example_BC.ora -
OPC_WALLETパラメータに格納されている値を調べ、バックアップ構成パラメータ・ファイル内のウォレット・ファイルへのファイル・パスを見つけます。 これを行うには、バックアップ構成パラメータ・ファイルを含むディレクトリに移動し、次のcatコマンドを使用します:cat <backup_config_parameter_file>たとえば:
cat opc_b9naijWMAXzi9example_BC.ora出力:
OPC_HOST=https://swiftobjectstorage.us-ashburn-1.oraclecloud.com/v1/dbbackupiad OPC_WALLET='LOCATION=file:/opt/oracle/dcs/commonstore/objectstore/wallets/13aef284-9d6b-4eb6-8751-2988aexample CREDENTIAL_ALIAS=alias_opc' OPC_CONTAINER=b9naijWMAXzi9example -
cwallet.ssoファイルがOPC_WALLETパラメータで指定されたディレクトリに存在することを確認し、ファイルに正しい権限があることを確認します。 ファイル・アクセス権には、"600" (-rw-------)の8進数値が必要です。 次のコマンドを使用します。ls -ltr /opt/oracle/dcs/commonstore/objectstore/wallets/<backup_config_id>たとえば:
ls -ltr /opt/oracle/dcs/commonstore/objectstore/wallets/13aef284-9d6b-4eb6-8751-2988aexample出力:
total 4 -rw------- 1 oracle oinstall 0 Apr 20 06:45 cwallet.sso.lck -rw------- 1 oracle oinstall 1941 Apr 20 06:45 cwallet.sso
TDE Walletの問題
内容は、次のとおりです。
TDE Walletのロケーションの指定が正しくありません
バックアップ操作が機能するには、$ORACLE_HOME/network/admin/sqlnet.oraファイルに、次のように書式設定されたENCRYPTION_WALLET_LOCATIONパラメータが含まれている必要があります:
ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/opt/oracle/dcs/commonstore/wallets/tde/$ORACLE_UNQNAME)))ノート:
このウォレットのロケーションのエントリでは、$ORACLE_UNQNAMEは環境変数であり、実際の値に置き換えることはできません。
TDE Walletのロケーションの指定の確認
catコマンドを使用して、TDEウォレットのロケーションの指定を確認します。 たとえば:
cat $ORACLE_HOME/network/admin/sqlnet.ora出力:
ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/opt/oracle/dcs/commonstore/wallets/tde/$ORACLE_UNQNAME)))SQL*Plusを使用してデータベースを起動したときにORACLE_UNQNAME環境変数が設定されなかった
データベースがSQL*Plusを使用して起動され、ORACLE_UNQNAME環境変数が設定されていない場合、ウォレットは正しく開かれません。
問題を解決するには、srvctlユーティリティを使用してデータベースを起動します:
srvctl start database -d <db_unique_name>正しく構成されていないマスター暗号化キーでプラガブル・データベースが追加されました
PDBレベルのキーストアをサポートするOracle Databaseバージョンのマルチテナント環境では、各PDBに独自のマスター暗号化キーがあります。 この暗号化キーは、すべてのコンテナで使用される単一のキーストアに格納されます。 新しいPDBを作成した後、または新しいPDBに接続した後に、そのPDBのマスター暗号化キーを作成してアクティブ化する必要があります。 そうしない場合、v$encryption_walletビューのSTATUS列に値OPEN_NO_MASTER_KEYが表示されます。
マスター暗号化キーのステータスを確認してマスター・キーを作成するには、次の手順を実行します:
-
次の例に示すように、
v$encryption_walletビューのSTATUS列を確認します:alter session set container=pdb2;select WRL_TYPE,WRL_PARAMETER,STATUS,WALLET_TYPE from v$encryption_wallet;出力:
WRL_TYPE WRL_PARAMETER STATUS WALLET_TYPE --------- ------------------------------------------------------- ------------------ ----------- FILE /opt/oracle/dcs/commonstore/wallets/tde/example_iadxyz/ OPEN_NO_MASTER_KEY AUTOLOGIN -
次の例に示すように、PDBが読取り/書込みオープン・モードであり、制限されていないことを確認します:
show pdbs出力:
CON_ID CON_NAME OPEN MODE RESTRICTED ------ ---------- ----------- ----------- 2 PDB$SEED READ ONLY NO 3 PDB1 READ WRITE NO 4 PDB2 READ WRITE NOPDBを制限モードでオープンすることはできません(
RESTRICTED列にNOが表示されている必要があります)。 PDBが現在制限モードになっている場合は、PDB_PLUG_IN_VIOLATIONSビューの情報を確認し、問題を解決してから続行してください。 PDB_PLUG_IN_VIOLATIONSビューおよび制限付きステータスの詳細は、Oracle Databaseバージョンのプラガブル・データベースに関するドキュメントを参照してください。 -
次の
DBCLIコマンドを実行して、ステータスをOPENに変更します:sudo su –dbcli list-databasedbcli update-tdekey -i <database_ID> -n <PDB_name> -p表示された
update-tdekeyコマンドによって、管理パスワードの入力が求められます。 -
ステップ1に示すように
v$encryption_walletビューを問い合せて、ウォレットのステータスがOPEN_NO_MASTER_KEYからOPENに変更されたことを確認します。
TDE Walletに関連する構成の確認
TDEウォレットに関連するいくつかの構成パラメータにより、バックアップが失敗する可能性があります。
-
次のコマンドを使用して、環境データベースの一意の名前パラメータ(ORACLE_UNQNAME)が正しく設定されていることを確認します:
srvctl getenv database -d <db_unique_name>たとえば:
srvctl getenv database -d orclbkp_iadxyz出力:
orclbkp_iadxyz: ORACLE_UNQNAME=orclbkp_iadxyz TZ=UTC -
sqlnet.ora設定を確認して、ファイルに正しいDIRECTORY値を持つENCRYPTION_WALLET_LOCATIONパラメータがあることを確認します。 次のコマンドを使用します。cat $ORACLE_HOME/network/admin/sqlnet.oraたとえば:
cat $ORACLE_HOME/network/admin/sqlnet.ora出力:
ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/opt/oracle/dcs/commonstore/wallets/tde/$ORACLE_UNQNAME))) -
v$encryption_walletビューをチェックして、ウォレット・ステータスがopenで、ウォレット・タイプが「自動ログイン」であることを確認します。 たとえば:select status, wrl_parameter,wallet_type from v$encryption_wallet;出力:
STATUS WRL_PARAMETER WALLET_TYPE ------- -------------------------------------------------------- ------------ OPEN /opt/oracle/dcs/commonstore/wallets/tde/example_iadxyz/ AUTOLOGINプラガブル・データベース(PDB)の場合は、
v$encryption_walletビューを問い合せる前に、適切なコンテナに切り替えてください。 たとえば:sqlplus / as sysdbaalter session set container=pdb1;select WRL_TYPE,WRL_PARAMETER,STATUS,WALLET_TYPE from v$encryption_wallet;出力:
WRL_TYPE WRL_PARAMETER STATUS WALLET_TYPE --------- ------------------------------------------------------ ------- ------------ FILE /opt/oracle/dcs/commonstore/wallets/tde/tiger_iad3c8/ OPEN AUTOLOGIN
TDE Walletファイルがありません
TDEウォレット・ファイル(ewallet.p12)がない場合、またはファイル・システムの権限または所有権に互換性がない場合、バックアップが失敗することがあります。 次の例に示すように、ファイルを確認します:
ls -ltr /opt/oracle/dcs/commonstore/wallets/tde/$ORACLE_UNQNAME/ewallet.p12出力:
-rwx------ 1 oracle oinstall 5680 Apr 18 13:09 /opt/oracle/dcs/commonstore/wallets/tde/orclbkp_iadxzy/ewallet.p12TDEウォレット・ファイルには8進数値"700" (-rwx------)のファイル権限が必要であり、このファイルの所有者はoinstallオペレーティング・システム・グループに含まれている必要があります。
自動ログインWalletファイルがありません
自動ログイン・ウォレット・ファイル(cwallet.sso)がない場合、またはファイル・システムの権限または所有権に互換性がない場合、バックアップが失敗する可能性があります。 次の例に示すように、ファイルを確認します:
ls -ltr /opt/oracle/dcs/commonstore/wallets/tde/$ORACLE_UNQNAME/cwallet.sso出力:
-rwx------ 1 oracle oinstall 5725 Apr 18 13:09 /opt/oracle/dcs/commonstore/wallets/tde/orclbkp_iadxyz/cwallet.sso自動ログイン・ウォレット・ファイルには8進数値"700" (-rwx------)のファイル権限が必要であり、このファイルの所有者はoinstallオペレーティング・システム・グループに含まれている必要があります。
バックアップの失敗のその他の原因
内容は、次のとおりです。
アンマウントされたCommonstoreマウント・ポイント
マウント・ポイント/opt/oracle/dcs/commonstoreをマウントする必要があります。マウントしないと、バックアップは失敗します。
Commonstoreマウント・ポイントの確認
次の例に示すように、マウント・ポイント/opt/oracle/dcs/commonstoreがマウントされていることを確認します:
srvctl config filesystem -volume commonstore -diskgroup data出力:
Volume device: /dev/asm/commonstore-5
Diskgroup name: data
Volume name: commonstore
Canonical volume device: /dev/asm/commonstore-5
Accelerator volume devices:
Mountpoint path: /opt/oracle/dcs/commonstore
Mount point owner: oracle
Mount users:
Type: ACFSora.data.commonstore.acfsがオンラインであることを確認
-
ora.data.commonstore.acfsの状態はオンラインである必要があります。そうでない場合、バックアップは失敗します。 次の例に示すように確認します:crsctl stat resource ora.data.commonstore.acfs -v出力:
NAME=ora.data.commonstore.acfs TYPE=ora.acfs.type LAST_SERVER=orcl STATE=OFFLINE TARGET=OFFLINE ... STATE_DETAILS=admin unmounted /opt/oracle/dcs/commonstore ... -
commonstoreディレクトリの内容をリストして、マウントされていることを確認ls -ltr /opt/oracle/dcs/commonstore -
STATE_DETAILS値が
unmountedの場合は、次の例に示すようにファイル・システムをマウントします:srvctl start filesystem -volume commonstore -diskgroup data -
次の例に示すように、変更が成功したことを確認します:
crsctl stat resource ora.data.commonstore.acfs -v出力:
NAME=ora.data.commonstore.acfs TYPE=ora.acfs.type LAST_SERVER=orcl STATE=ONLINE on orcl TARGET=ONLINE CARDINALITY_ID=ONLINE ... STATE_DETAILS=mounted on /opt/oracle/dcs/commonstore -
次の例に示すように、
commonstoreディレクトリの内容をリストして、マウントされていることを確認します:ls -ltr /opt/oracle/dcs/commonstore出力:
total 220 drwx------ 2 root root 65536 Apr 18 10:50 lost+found drwx------ 3 oracle oinstall 20480 Apr 18 11:02 wallets drwxr-xr-x 3 root root 20480 Apr 20 06:41 pkgrepos drwxr-xr-x 4 oracle oinstall 20480 Apr 20 06:41 objectstore
データベースが適切に登録されていない
データベースがdcs-agentに登録されていない場合、データベースのバックアップは失敗します。 このシナリオは、データベースをOCIに手動で移行し、dbcli register-databaseコマンドを実行しない場合に発生する可能性があります。
データベースが正しく登録されているかどうかを確認するには、srvctl config databaseコマンドおよびdbcli list-databasesコマンドを実行して、返される情報を確認します。 いずれのコマンドもデータベースのレコードを返さない場合は、Oracle Support Servicesに連絡してください。
データベースの登録方法については、次のトピックを参照してください:
- 「OCI Classicオブジェクト・ストアからのデータベースのリカバリ」のDB Systemでのデータベースの登録
- 「Oracle Database CLIリファレンス」のデータベース・コマンド
追加ヘルプの表示
このトピックの情報を使用して問題を解決できなかった場合は、次の手順に従って関連するデータベースおよび診断情報を収集します。 この情報を収集したら、Oracle Supportに連絡してください。
内容は、次のとおりです。
問題レポートで使用するデータベース情報の収集
データベースの詳細を収集するには、次のコマンドを使用します。 各コマンドの出力を参照用に記録します:
dbcli list-databasesdbcli describe-database -i <database_id>dbcli describe-component失敗したジョブに関する診断情報の収集
-
rootユーザーとしてホストにログオンし、
/opt/oracle/dcs/bin/ディレクトリに移動します。 -
次の2つのコマンドを実行して、失敗したジョブに関する情報を生成します:
dbcli list-jobsdbcli describe-job -i <job_ID> -j2番目のコマンドの<job_ID>は、最初のコマンドでレポートされた最新の失敗したジョブのIDである必要があります。
-
診断コレクタ・スクリプトを実行して、Oracle Support Servicesの診断情報を含むzipファイルを作成します。
diagcollector.pyこのコマンドは、
/tmpディレクトリにdiagLogs -<timestamp>.zipという名前のファイルを作成します。
DCSエージェント・ログ・ファイルの収集
DCSエージェント・ログ・ファイルを収集するには、次の手順を実行します:
- opcユーザーとしてログインします。
-
次のコマンドを実行します。
sudo /opt/oracle/dcs/bin/diagcollector.py指定されたディレクトリのzipファイルでエージェント・ログが使用可能であることを示すメッセージが返されます。 たとえば:
Logs are being collected to: /tmp/dcsdiag/diagLogs-1234567890.zip
TDE構成詳細の収集
srvctl getenv database -d <db_unique_name>コマンドを実行し、参照用に出力を記録します。-
ビュー
v$encryption_walletの出力を記録します。 たとえば:select status, wrl_parameter,wallet_type from v$encryption_wallet;出力:
STATUS WRL_PARAMETER WALLET_TYPE -------- ------------------------------------------------------- --------- OPEN /opt/oracle/dcs/commonstore/wallets/tde/example_iadxyz/ AUTOLOGIN -
ls -ltr <wrl_parameter>コマンドの出力を記録します。たとえば:ls -ltr /opt/oracle/dcs/commonstore/wallets/tde/example_iadxyz/出力:
total 28 -rw----- 1 oracle asmadmin 2400 May 2 09:42 ewallet_2018050209420381_defaultTag.p12 -rw----- 1 oracle asmadmin 5680 May 2 09:42 ewallet.p12 -rw----- 1 oracle asmadmin 5723 May 2 09:42 cwallet.sso
RMANバックアップ・レポート・ファイルの収集
次のコマンドを使用してRMANバックアップ・レポート・ファイルを生成します:
dbcli create-rmanbackupreport -i <db_id> -w detailed -rn <report_name>たとえば:
dbcli create-rmanbackupreport -i 57fvwxyz-9dc4-45d3-876b-5f850example -w detailed -rn bkpreport1dbcli describe-rmanbackupreport -in <report_name>コマンドを使用して、レポート・ファイルを検索します。 レポートのロケーションが出力に表示されます。 たとえば:
dbcli describe-rmanbackupreport -in bkpreport1出力:
Backup Report details
----------------------------------------------------------------
ID: b55vwxyz-c49f-4af3-a956-acccdexample
Report Type: detailed
Location: Node patchtst: /opt/oracle/dcs/log/patchtst/rman/bkup/example_iadxyz/rman_list_backup_detail
/2018-05-02/rman_list_backup_detail_2018-05-02_11-46-51.0359.log
Database ID: 57fvwxyz-9dc4-45d3-876b-5f850example
CreatedTime: May 2, 2018 11:46:38 AM UTC