バックアップの失敗のトラブルシューティング
データベース・バックアップは、様々な理由で失敗することがあります。通常、バックアップは、データベース・ホストがオブジェクト・ストアにアクセスできないか、ホストまたはデータベース構成に問題があることが原因で失敗します。
この記事には、失敗の原因の特定と問題の修正に役立つ情報が含まれています。情報は、エラー状態に基づいて複数の項に編成されています。
すでに原因がわかっている場合は、推奨される解決策が記載されたトピックにスキップできます。それ以外の場合は、失敗の原因の特定のトピックを使用して開始します。
この記事では、次のトピックについて説明します:
- 失敗の原因の特定
- データベース・サービス・エージェントの問題
- オブジェクト・ストア接続の問題
- ホストの問題
- Oracle Clusterwareの問題
- データベースの問題
- TDEウォレットの問題
- バックアップの失敗のその他の原因
- その他の支援
ヒント:
シリアル・コンソール接続を作成して、シングルユーザー・モードでシステムのトラブルシューティングを行うこともできます。OCIコンソールでのシリアル・コンソール接続の作成の詳細は、DBシステムへのシリアル・コンソール接続の管理を参照してください。失敗の原因の特定
データベースのバックアップに失敗すると、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データベースでは、エージェント・フレームワークを使用して、クラウド・プラットフォームを通じてデータベースを管理できます。ステータスが停止/待機中の場合、状況によってはバックアップの失敗を解決するためにdcsagentプログラムを再起動する必要があります。
次のトピックについて説明します:
データベース・サービス・エージェントの再起動
OL6を使用する場合は、
systemctl
のかわりにinitctl
を使用してください。
-
コマンド・プロンプトで、エージェントのステータスを確認します:
systemctl status initdcsagent
-
エージェントの状態が停止/待機中の場合、エージェントの再起動を試みます:
systemctl start initdcsagent
-
エージェントのステータスを再度確認して、エージェントが開始/実行中ステータスであることを確認します:
systemctl status initdcsagent
オブジェクト・ストア接続の問題
データベースをOCIオブジェクト・ストレージにバックアップするには、ホストが適切なSwiftエンドポイントに接続できる必要があります。Swiftユーザーを使用して、この接続性をテストできます。
次のトピックについて説明します:
データベース・ホストがオブジェクト・ストアに接続できることの確認
- テナンシにSwiftユーザーを作成します。詳細は、ユーザー資格証明の管理の認証トークンの操作を参照してください。
-
前のステップで作成したユーザーを使用して、次のコマンドを実行し、ホストがオブジェクト・ストアにアクセスできることを確認します。
curl -v -X HEAD -u <user_ID>:'<auth_token>' https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace>
- 使用する適切なリージョンの詳細は、オブジェクト・ストレージのFAQを参照してください。
- オブジェクト・ストレージ・ネームスペースの詳細は、オブジェクト・ストレージ・ネームスペースの理解を参照してください。
- オブジェクト・ストアに接続できない場合、オブジェクト・ストアの接続性の構成方法について、コンソールを使用したデータベースのバックアップを参照してください。
ホストの問題
次のトピックについて説明します:
データベース・ホストにおける次の1つ以上の状況が原因で、バックアップに失敗することがあります:
Oracleプロファイルの対話型コマンド
oraenv
などのインタラクティブ・コマンド、またはエラー・メッセージや警告メッセージを返すコマンドが、グリッドまたはoracleユーザーの.bash_profile
ファイルに追加された場合、自動バックアップなどのデータベース・サービス操作は中断され、完了できません。これらのコマンドの.bash_profile
ファイルを確認して削除してください。
ファイル・システムの空き容量がない
バックアップ操作には、ホスト・ファイル・システム上の/u01
ディレクトリの領域が必要です。バックアップに使用可能な領域を確認するには、ホストでdf -h
コマンドを使用します。ファイル・システムの領域が不十分な場合、古いログまたはトレース・ファイルを削除して領域を解放できます。
Oracle Database Cloud Backup Moduleのバージョンが正しくない
システムに、必要なバージョンのバックアップ・モジュール(opc_installer.jar)がない可能性があります。この既知の問題については、DBシステムで管理対象バックアップを使用できませんを参照してください。問題を解決するには、この項の手順を実行するか、DBシステムおよびデータベースを最新のバンドル更新で更新します。
サイト・プロファイル・ファイル(glogin.sql)の変更
サイト・プロファイル・ファイル($ORACLE_HOME/sqlplus/admin/glogin.sql
)をカスタマイズすると、OCIで管理対象バックアップが失敗する可能性があります。SQL*Plusの構成を参照してください。特に、対話型コマンドはバックアップの失敗の原因となることがあります。OCIでホストされているデータベースに対してこのファイルを変更しないことをお薦めします。
Oracle Clusterwareの問題
Oracle Clusterwareを使用すると、複数のサーバーが相互に通信することにより、1つの集合単位として機能することができます。Clusterwareプログラムを再起動してバックアップの失敗を解決する必要がある場合があります。
データベース・ホストにおける次の1つ以上の状況が原因で、バックアップに失敗することがあります:
Oracle Clusterwareの再起動
-
コマンド・プロンプトからOracle Clusterwareのステータスを確認します:
crsctl check crs
crsctl stat res -t
-
Oracle Clusterwareがオンラインでない場合は、プログラムの再起動を試行します:
crsctl start crs
-
Oracle Clusterwareのステータスをチェックして、オンラインであることを確認します:
crsctl check crs
データベースの問題
不適切なデータベースの状態または構成によって、バックアップが失敗する可能性があります。
次のトピックについて説明します:
バックアップ中データベースが実行されていない
バックアップの進行中は、データベースが(理想的にはすべてのノードで)アクティブで実行中である必要があります。
データベースがアクティブで実行中であることの確認
次のコマンドを使用してデータベースの状態をチェックし、データベースが不適切な状態になる可能性のある問題が解決されていることを確認します:
srvctl status database -d <db_unique_name> -verbose
データベースのインスタンス・ステータスを含むメッセージが返されます。バックアップが成功するためには、インスタンス・ステータスがオープンである必要があります。データベースが実行されていない場合は、次のコマンドを使用して起動します:
srvctl start database -d <db_unique_name> -o open
データベースはマウントされているが、ステータスがオープンでない場合は、次のコマンドを使用してSQL*Plusコマンド・プロンプトにアクセスし、ステータスをオープンに設定します:
sqlplus / as sysdba
alter 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: アーカイバ・エラー(ドキュメント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 sysdba
exec 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
オブジェクト・ストア・ウォレット・ファイルの消失とバックアップの失敗
オブジェクト・ストアのウォレット・ファイルが失われると、RMANバックアップは失敗します。オブジェクト・ストアへの接続を有効にするには、ウォレット・ファイルが必要です。
オブジェクト・ストア・ウォレット・ファイルが存在し、適切な権限があることの確認
-
次のコマンドを使用して、データベース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
パラメータで指定されたディレクトリに存在することを確認し、ファイルに適切な権限があることを確認します。ファイル権限には、8進数値の"600" (-rw-------
)が必要です。次のコマンドを使用します: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ウォレットの問題
次のトピックについて説明します:
TDEウォレットの場所の指定が正しくない
バックアップ操作が機能するには、$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ウォレットの場所の指定の確認
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に独自のマスター暗号化キーがあります。この暗号化キーは、すべてのコンテナで使用される1つのキーストアに格納されます。新しい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がREAD WRITEオープン・モードであり、制限されていないことを確認します:
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バージョンのプラガブル・データベースのドキュメントを参照してください。 -
ステータスを
OPEN
に変更するには、次のDBCLI
コマンドを実行します:sudo su –
dbcli list-database
dbcli update-tdekey -i <database_ID> -n <PDB_name> -p
示されている
update-tdekey
コマンドでは、管理パスワードの入力を求められます。 -
ステップ1に示されているように、
v$encryption_wallet
ビューを問い合せて、ウォレットのステータスがOPEN_NO_MASTER_KEYからOPENに変更されたことを確認します。
TDEウォレットに関連する構成の確認
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
ビューをチェックして、ウォレット・ステータスがオープンで、ウォレット・タイプが自動ログインであることを確認します。例: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 sysdba
alter 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ウォレット・ファイルがない
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.p12
TDEウォレット・ファイルに8進数値"700" (-rwx------
)のファイル権限があり、このファイルの所有者がoinstall
オペレーティング・システム・グループに含まれている必要があります。
自動ログイン・ウォレット・ファイルがない
自動ログイン・ウォレット・ファイル(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: ACFS
ora.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サポート・サービスに連絡してください。
データベースの登録方法の手順は、次のトピックを参照してください:
- OCI Classic Object StoreからのデータベースのリカバリのDBシステムでのデータベースの登録
- Oracle Database CLIリファレンスのデータベース・コマンド
その他の支援
このトピックの情報を使用して問題を解決できなかった場合は、次の手順に従って、関連するデータベースおよび診断情報を収集します。この情報を収集したら、Oracleサポートに連絡してください。
次のトピックについて説明します:
問題のレポートで使用するデータベース情報の収集
データベースの詳細を収集するには、次のコマンドを使用します。各コマンドの出力を参照用に記録します:
dbcli list-databases
dbcli describe-database -i <database_id>
dbcli describe-component
失敗したジョブに関する診断情報の収集
-
ホストにrootユーザーとしてログインし、
/opt/oracle/dcs/bin/
に移動します。 -
次の2つのコマンドを実行して、失敗したジョブに関する情報を生成します:
dbcli list-jobs
dbcli describe-job -i <job_ID> -j
2番目のコマンドの<job_ID>は、最初のコマンドでレポートされた最新の失敗ジョブのIDである必要があります。
-
診断コレクタ・スクリプトを実行して、Oracleサポート・サービスに向けた診断情報を含む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 bkpreport1
dbcli 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