Troubleshoot Backup Failures
Database backups can fail for various reasons. Typically, a backup fails because either the database host cannot access the object store, or there are problems on the host or with the database configuration.
This article includes information to help you determine the cause of the failure and fix the problem. The information is organized into several sections, based on the error condition.
If you already know the cause, you can skip to the topic with the suggested solution. Otherwise, use the Identify the Cause of Failure topic to get started.
The following topics are covered in this article:
- Identify the Cause of Failure
- Database Service Agent Issues
- Object Store Connectivity Issues
- Host Issues
- Oracle Clusterware Issues
- Database Issues
- TDE Wallet Issues
- Other Causes of Backup Failures
- Get Additional Help
Tip:
You can also create serial console connections to troubleshoot your system in single-user mode. For information on creating a serial console connection in the OCI Console, see Manage Serial Console Connection to the DB System.Identify the Cause of Failure
In the OCI Console, a failed database backup either displays a status of Failed or hangs in the Backup in Progress or Creating state. If the error message does not contain enough information to point you to a solution, you can use the database CLI and log files to gather more data. Then, refer to the applicable section in this topic for a solution.
The following topics are covered:
Identify the Root Cause of the Backup Failure
-
Log on to the host as the root user and navigate to
/opt/oracle/dcs/bin/
. -
Determine the sequence of operations performed on the database.
dbcli list-jobs | grep -i <dbname>
Note the last job ID listed with a status other than Success.
-
With the job ID you noted from the previous step, use the following command to check the details of that job:
dbcli describe-job -i <job_ID> -j
Typically, running this command is enough to reveal the root cause of the failure.
-
If you require more information, review the
/opt/oracle/dcs/log/dcs-agent.log
file.You can find the job ID in this file by using the timestamp returned by the job report in step 2.
-
If the problem details suggest an RMAN issue, review the RMAN logs in the following directory.
/opt/oracle/dcs/log/<hostname>/rman/bkup/<db_unique_name>/rman_backup/<yyyy-mm-dd>
If the database failure is on a 2-node RAC database, perform steps 3 and 4 on both nodes.
Database Service Agent Issues
Your OCI database makes use of an agent framework to allow you to manage your database through the cloud platform. Occasionally you might need to restart the dcsagent program if it has the status of stop/waiting to resolve a backup failure.
The following topics are covered:
Restart the Database Service Agent
Use
initctl
instead of systemctl
when using OL6.
-
From a command prompt, check the status of the agent:
systemctl status initdcsagent
-
If the agent is in the stop/waiting state, try to restart the agent:
systemctl start initdcsagent
-
Check the status of the agent again to confirm that it has the start/running status:
systemctl status initdcsagent
Object Store Connectivity Issues
Backing up your database to OCI Object Storage requires that the host can connect to the applicable Swift endpoint. You can test this connectivity by using a Swift user.
The following topics are covered:
Ensure Your Database Host Can Connect to the Object Store
- Create a Swift user in your tenancy. For more information, see Working with Auth Tokens in Managing User Credentials.
-
With the user you created in the previous step, use the following command to verify the host can access the object store.
curl -v -X HEAD -u <user_ID>:'<auth_token>' https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace>
- For more information on the correct region to use, see Object Storage FAQ.
- For more information about your Object Storage namespace, see Understanding Object Storage Namespaces.
- If you cannot connect to the object store, see Back Up a Database Using the Console for how to configure object store connectivity.
Host Issues
The following topics are covered:
One or more of the following conditions on the database host can cause backups to fail:
Interactive Commands in the Oracle Profile
If an interactive command such as oraenv
, or any command that might return an error or warning message, was added to the .bash_profile
file for the grid or oracle user, database service operations like automatic backups can be interrupted and fail to complete. Check the .bash_profile
file for these commands, and remove them.
The File System Is Full
Backup operations require space in the /u01
directory on the host file system. Use the df -h
command on the host to check the space available for backups. If the file system has insufficient space, you can remove old log or trace files to free up space.
Incorrect Version of the Oracle Database Cloud Backup Module
Your system might not have the required version of the backup module (opc_installer.jar). See Unable to use Managed Backups in your DB system about this known issue. To fix the problem, you can follow the procedure in that section or simply update your DB system and database with the latest bundle update.
Changes to the Site Profile File (glogin.sql)
Customizing the site profile file ($ORACLE_HOME/sqlplus/admin/glogin.sql
) can cause managed backups to fail in OCI. See SQL*Plus Configuration. In particular, interactive commands can lead to backup failures. Oracle recommends that you not modify this file for databases hosted in OCI.
Oracle Clusterware Issues
Oracle Clusterware enables servers to communicate with each other so that they can function as a collective unit. Occasionally you might need to restart the Clusterware program to resolve a backup failure.
One or more of the following conditions on the database host can cause backups to fail:
Restart the Oracle Clusterware
-
From command prompt, check the status of Oracle Clusterware:
crsctl check crs
crsctl stat res -t
-
If Oracle Clusterware is not online, try to restart the program:
crsctl start crs
-
Check the status of Oracle Clusterware to confirm that it is online:
crsctl check crs
Database Issues
An improper database state or configuration can lead to failed backups.
The following topics are covered:
- Database Not Running During Backup
- Check That the Database Is Active and Running
- Archiving Mode Set to NOARCHIVELOG
- Check and Set the Archiving Mode
- Stuck Database Archiver Process and Backup Failures
- Temporary Tablespace Errors
- RMAN Configuration and Backup Failures
- RMAN Configuration Settings That Should Not Be Altered
- RMAN Retention Policy and Backup Failures
- Configure the RMAN Retention Policy Setting
- Loss of Object Store Wallet File and Backup Failures
- Confirm That the Object Store Wallet File Exists and Has the Correct Permissions
Database Not Running During Backup
The database must be active and running (ideally on all nodes) while the backup is in progress.
Check That the Database Is Active and Running
Use the following command to check the state of your database, and ensure that any problems that might have put the database in an improper state are resolved:
srvctl status database -d <db_unique_name> -verbose
The system returns a message including the database's instance status. The instance status must be Open for the backup to succeed. If the database is not running, use the following command to start it:
srvctl start database -d <db_unique_name> -o open
If the database is mounted but does not have the Open status, use the following commands to access the SQL*Plus command prompt and set the status to Open:
sqlplus / as sysdba
alter database open;
Archiving Mode Set to NOARCHIVELOG
When you provision a new database, the archiving mode is set to ARCHIVELOG
by default. This is the required archiving mode for backup operations. Check the archiving mode setting for the database and change it to ARCHIVELOG
, if applicable.
Check and Set the Archiving Mode
Open an SQL*Plus command prompt and enter the following command:
select log_mode from v$database;
If you need to set the archiving mode to ARCHIVELOG
, start the database in Mount status (and not Open status), and use the following command at the SQL*Plus command prompt:
alter database archivelog;
Confirm that the db_recovery_file_dest
parameter points to +RECO
, and that the log_archive_dest_1
parameter is set to USE_DB_RECOVERY_FILE_DEST
.
For RAC databases, one instance must have the Mount status when enabling archivelog mode. To enable archivelog mode for a RAC database, perform the following steps:
-
Shut down all database instances.
srvctl stop database -d
-
Start one of the database instances in mount state.
srvctl start instance -d <db_unique_name> -i <instance_name> -o mount
-
Access the SQL*Plus command prompt.
sqlplus / as sysdba
-
Enable archive log mode and exit.
alter database archivelog;
exit;
-
Stop the database.
srvctl stop instance -d <db_unique_name> -i <instance_name>
-
Restart all database instances.
srvctl start database -d <db_unqiue_name>
-
At the SQL*Plus command prompt, confirm the archiving mode is set to
ARCHIVELOG
.select log_mode from v$database;
Stuck Database Archiver Process and Backup Failures
Backups can fail when the database instance has a stuck archiver process. For example, this can happen when the flash recovery area (FRA) is full. You can check for this condition using the following command.
srvctl status database -db <db_unique_name> -v
If the command returns the following output, you must resolve the stuck archiver process issue before backups can succeed:
Instance <instance_identifier> is running on node *<node_identifier>. Instance status: Stuck Archiver
Refer to ORA-00257:Archiver Error (Doc ID 2014425.1) for information on resolving a stuck archiver process.
After resolving the stuck process, the command should return the following output :
Instance <instance_identifier> is running on node *<node_identifier>. Instance status: Open
If the instance status does not change after you resolve the underlying issue with the device or resource being full or unavailable, try one of the following workarounds:
- Restart the database using the
srvctl
command to update the status of the database in the clusterware - Upgrade the database to the latest patchset levels
Temporary Tablespace Errors
If fixed table statistics are not up to date on the database, backups can fail with errors referencing temporary tablespace present in the dcs-agent.log
file. For example:
select status from v$rman_status where COMMAND_ID=<backup_id>
Output:
ERROR at line 1:
ORA-01652: unable to extend temp segment by 128 in tablespace TEMP
Gather your fixed table statics as follows to resolve this issue.
conn / as sysdba
exec dbms_stats.gather_fixed_objects_stats();
RMAN Configuration and Backup Failures
Editing certain RMAN configuration parameters can lead to backup failures in OCI. To check your RMAN configuration, use the show all
command at the RMAN command line prompt.
See the following list of parameters for details about RMAN the configuration settings that should not be altered for databases in OCI.
RMAN Configuration Settings That Should Not Be Altered
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 Retention Policy and Backup Failures
The RMAN retention policy configuration can be the source of backup failures. Using the REDUNDANCY retention policy configuration instead of the RECOVERY WINDOW policy can lead to backup failures. Be sure to use the RECOVERY WINDOW OF 30 DAYS configuration.
Configure the RMAN Retention Policy Setting
-
Find the database ID using the following command:
dbcli list-databases
-
Find the
BackupConfigId
value for the database using the following command:dbcli describe-database -i <database_id>
-
Update the retention policy configuration to
RECOVERY WINDOW OF 30 DAYS
:dbcli update-backupconfig -i <backup_config_id> --recoverywindow 30
Loss of Object Store Wallet File and Backup Failures
RMAN backups fail when an object store wallet file is lost. The wallet file is necessary to enable connectivity to the object store.
Confirm That the Object Store Wallet File Exists and Has the Correct Permissions
-
Find the database ID using the following command:
dbcli list-databases
-
Find the
BackupConfigId
value for the database using the following command:dbcli describe-database -i <database_id>
-
Find the
BackupLocation
value for the database using the following command:dbcli describe-backupconfig <backup_config_id>
-
Find the file path of the backup config parameter file (
opc_<backup_location_value>_BC.ora
) using the following command:locate opc_<backup_location_value>_BC.ora
For example:
locate opc_b9naijWMAXzi9example_BC.ora
Output:
/opt/oracle/dcs/commonstore/objectstore/opc_pfile/13aef284-9d6b-4eb6-8751-2988a9example/opc_b9naijWMAXzi9example_BC.ora
-
Find the file path to the wallet file in the backup config parameter file by inspecting the value stored in the
OPC_WALLET
parameter. To do this, navigate to the directory containing the backup config parameter file and use the followingcat
command:cat <backup_config_parameter_file>
For example:
cat opc_b9naijWMAXzi9example_BC.ora
Output:
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
-
Confirm that the
cwallet.sso
file exists in the directory specified in theOPC_WALLET
parameter, and confirm that the file has the correct permissions. The file permissions should have the octal value of "600" (-rw-------
). Use the following command:ls -ltr /opt/oracle/dcs/commonstore/objectstore/wallets/<backup_config_id>
For example:
ls -ltr /opt/oracle/dcs/commonstore/objectstore/wallets/13aef284-9d6b-4eb6-8751-2988aexample
Output:
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 Issues
The following topics are covered:
- Incorrect TDE Wallet Location Specification
- Check the TDE Wallet Location Specification
- The ORACLE_UNQNAME Environment Variable Was Not Set When the Database Was Started Using SQL*Plus
- Pluggable Database Was Added With an Incorrectly Configured Master Encryption Key
- Check Configuration Related to the TDE Wallet
- Missing TDE Wallet File
- Missing Auto Login Wallet File
Incorrect TDE Wallet Location Specification
For backup operations to work, the $ORACLE_HOME/network/admin/sqlnet.ora
file must contain the ENCRYPTION_WALLET_LOCATION parameter formatted exactly as follows:
ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/opt/oracle/dcs/commonstore/wallets/tde/$ORACLE_UNQNAME)))
In this wallet location entry,
$ORACLE_UNQNAME
is an environment variable and should not be replaced with an actual value.
Check the TDE Wallet Location Specification
Use the cat
command to check the TDE wallet location specification. For example:
cat $ORACLE_HOME/network/admin/sqlnet.ora
Output:
ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/opt/oracle/dcs/commonstore/wallets/tde/$ORACLE_UNQNAME)))
The ORACLE_UNQNAME
Environment Variable Was Not Set When the Database Was Started Using SQL*Plus
If the database was started using SQL*Plus, and the ORACLE_UNQNAME
environment variable was not set, the wallet is not opened correctly.
To fix the problem, start the database using the srvctl
utility:
srvctl start database -d <db_unique_name>
Pluggable Database Was Added With an Incorrectly Configured Master Encryption Key
In a multitenant environment for Oracle Database versions that support PDB-level keystore, each PDB has its own master encryption key. This encryption key is stored in a single keystore used by all containers. After you create or plug in a new PDB, you must create and activate a master encryption key for it. If you do not do so, the STATUS
column in the v$encryption_wallet
view shows the value OPEN_NO_MASTER_KEY
.
To check the master encryption key status and create a master key, perform the following:
-
Review the the
STATUS
column in thev$encryption_wallet
view, as shown in the following example:alter session set container=pdb2;
select WRL_TYPE,WRL_PARAMETER,STATUS,WALLET_TYPE from v$encryption_wallet;
Output:
WRL_TYPE WRL_PARAMETER STATUS WALLET_TYPE --------- ------------------------------------------------------- ------------------ ----------- FILE /opt/oracle/dcs/commonstore/wallets/tde/example_iadxyz/ OPEN_NO_MASTER_KEY AUTOLOGIN
-
Confirm that the PDB is in READ WRITE open mode and is not restricted, as shown in the following example:
show pdbs
Output:
CON_ID CON_NAME OPEN MODE RESTRICTED ------ ---------- ----------- ----------- 2 PDB$SEED READ ONLY NO 3 PDB1 READ WRITE NO 4 PDB2 READ WRITE NO
The PDB cannot be open in restricted mode (the
RESTRICTED
column must showNO
). If the PDB is currently in restricted mode, review the information in the PDB_PLUG_IN_VIOLATIONS view and resolve the issue before continuing. For more information on the PDB_PLUG_IN_VIOLATIONS view and the restricted status, review the documentation on pluggable database for your Oracle Database version. -
Run the following
DBCLI
commands to change the status toOPEN
:sudo su –
dbcli list-database
dbcli update-tdekey -i <database_ID> -n <PDB_name> -p
The
update-tdekey
command shown will prompt you for the admin password. -
Confirm that the status of the wallet has changed from OPEN_NO_MASTER_KEY to OPEN by querying the
v$encryption_wallet
view as shown in step 1.
Check Configuration Related to the TDE Wallet
Several configuration parameters related to the TDE wallet can cause backups to fail.
-
Check that the environment's database unique name parameter (ORACLE_UNQNAME) is set correctly using the following command:
srvctl getenv database -d <db_unique_name>
For example:
srvctl getenv database -d orclbkp_iadxyz
Output:
orclbkp_iadxyz: ORACLE_UNQNAME=orclbkp_iadxyz TZ=UTC
-
Check your
sqlnet.ora
settings to confirm that the file has an ENCRYPTION_WALLET_LOCATION parameter with the correct DIRECTORY value. Use the following command:cat $ORACLE_HOME/network/admin/sqlnet.ora
For example:
cat $ORACLE_HOME/network/admin/sqlnet.ora
Output:
ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/opt/oracle/dcs/commonstore/wallets/tde/$ORACLE_UNQNAME)))
-
Confirm that the wallet status is open and the wallet type is auto login by checking the
v$encryption_wallet
view. For example:select status, wrl_parameter,wallet_type from v$encryption_wallet;
Output:
STATUS WRL_PARAMETER WALLET_TYPE ------- -------------------------------------------------------- ------------ OPEN /opt/oracle/dcs/commonstore/wallets/tde/example_iadxyz/ AUTOLOGIN
For pluggable databases (PDBs), be sure that you switch to the appropriate container before querying
v$encryption_wallet
view. For example:sqlplus / as sysdba
alter session set container=pdb1;
select WRL_TYPE,WRL_PARAMETER,STATUS,WALLET_TYPE from v$encryption_wallet;
Output:
WRL_TYPE WRL_PARAMETER STATUS WALLET_TYPE --------- ------------------------------------------------------ ------- ------------ FILE /opt/oracle/dcs/commonstore/wallets/tde/tiger_iad3c8/ OPEN AUTOLOGIN
Missing TDE Wallet File
The TDE wallet file (ewallet.p12
) can cause backups to fail if it is missing, or if it has incompatible file system permissions or ownership. Check the file as shown in the following example:
ls -ltr /opt/oracle/dcs/commonstore/wallets/tde/$ORACLE_UNQNAME/ewallet.p12
Output:
-rwx------ 1 oracle oinstall 5680 Apr 18 13:09 /opt/oracle/dcs/commonstore/wallets/tde/orclbkp_iadxzy/ewallet.p12
The TDE wallet file should have file permissions with the octal value "700" (-rwx------
), and the owner of this file should be a part of the oinstall
operating system group.
Missing Auto Login Wallet File
The auto login wallet file (cwallet.sso
) can cause backups to fail if it is missing, or if it has incompatible file system permissions or ownership. Check the file as shown in the following example:
ls -ltr /opt/oracle/dcs/commonstore/wallets/tde/$ORACLE_UNQNAME/cwallet.sso
Output:
-rwx------ 1 oracle oinstall 5725 Apr 18 13:09 /opt/oracle/dcs/commonstore/wallets/tde/orclbkp_iadxyz/cwallet.sso
The auto login wallet file should have file permissions with the octal value "700" (-rwx------
), and the owner of this file should be a part of the oinstall
operating system group.
Other Causes of Backup Failures
The following topics are covered:
Unmounted Commonstore Mount Point
The mount point /opt/oracle/dcs/commonstore
must be mounted, or backups will fail.
Check the Commonstore Mount Point
Confirm that the mount point /opt/oracle/dcs/commonstore
is mounted, as shown in the following example:
srvctl config filesystem -volume commonstore -diskgroup data
Output:
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
Confirm That ora.data.commonstore.acfs
Is Online
-
The state for
ora.data.commonstore.acfs
must be online, or backups will fail. Confirm as shown in the following example:crsctl stat resource ora.data.commonstore.acfs -v
Output:
NAME=ora.data.commonstore.acfs TYPE=ora.acfs.type LAST_SERVER=orcl STATE=OFFLINE TARGET=OFFLINE ... STATE_DETAILS=admin unmounted /opt/oracle/dcs/commonstore ...
-
List the contents of the
commonstore
directory to confirm that it is mountedls -ltr /opt/oracle/dcs/commonstore
-
If the STATE_DETAILS value is
unmounted
, mount the file system as shown in the following example:srvctl start filesystem -volume commonstore -diskgroup data
-
Confirm that the change was successful as shown in the following example:
crsctl stat resource ora.data.commonstore.acfs -v
Output:
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
-
List the contents of the
commonstore
directory to confirm that it is mounted, as shown in the following example:ls -ltr /opt/oracle/dcs/commonstore
Output:
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
The Database Is Not Properly Registered
Database backups fail if the database is not registered with the dcs-agent
. This scenario can occur if you manually migrate the database to OCI and do not run the dbcli register-database
command.
To check whether the database is properly registered, review the information returned by running the srvctl config database
command and the dbcli list-databases
command. If either command does not return a record of the database, contact Oracle Support Services.
For instructions on how to register the database, refer to the following topics:
- Register the Database on the DB System in Recover a Database from the OCI Classic Object Store
- Database Commands in Oracle Database CLI Reference
Get Additional Help
If you were unable to resolve the problem using the information in this topic, follow the procedures below to collect relevant database and diagnostic information. After you have collected this information, contact Oracle Support.
The following topics are covered:
Collect Database Information for Use in Problem Reports
Use the following commands to collect details about your database. Record the output of each command for reference:
dbcli list-databases
dbcli describe-database -i <database_id>
dbcli describe-component
Collect Diagnostic Information Regarding Failed Jobs
-
Log on to the host as the root user and navigate to the
/opt/oracle/dcs/bin/
directory. -
Run the following two commands to generate information about the failed job:
dbcli list-jobs
dbcli describe-job -i <job_ID> -j
The <job_ID> in the second command should be the ID of the latest failed job reported from the first command.
-
Run the diagnostics collector script to create a zip file with the diagnostic information for Oracle Support Services.
diagcollector.py
This command creates a file named
diagLogs -<timestamp>.zip
in the/tmp
directory.
Collect DCS Agent Log Files
To collect DCS agent log files, perform the following:
- Log in as opc user.
-
Run the following command:
sudo /opt/oracle/dcs/bin/diagcollector.py
The system returns a message indicating that agent logs are available in a zip file at a specified directory. For example:
Logs are being collected to: /tmp/dcsdiag/diagLogs-1234567890.zip
Collect TDE Configuration Details
- Run the
srvctl getenv database -d <db_unique_name>
command and record the output for reference. -
Record the output of the view
v$encryption_wallet
. For example:select status, wrl_parameter,wallet_type from v$encryption_wallet;
Output:
STATUS WRL_PARAMETER WALLET_TYPE -------- ------------------------------------------------------- --------- OPEN /opt/oracle/dcs/commonstore/wallets/tde/example_iadxyz/ AUTOLOGIN
-
Record the output of the output of the
ls -ltr <wrl_parameter>
command.For example:ls -ltr /opt/oracle/dcs/commonstore/wallets/tde/example_iadxyz/
Output:
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
Collect the RMAN Backup Report File
Generate RMAN Backup Report File using the following command:
dbcli create-rmanbackupreport -i <db_id> -w detailed -rn <report_name>
For example:
dbcli create-rmanbackupreport -i 57fvwxyz-9dc4-45d3-876b-5f850example -w detailed -rn bkpreport1
Locate the report file using the dbcli describe-rmanbackupreport -in <report_name>
command. The location of the report is given in output. For example:
dbcli describe-rmanbackupreport -in bkpreport1
Output:
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