Recover a Database from Object Storage Using RMAN Backup

This article explains how to recover a Recovery Manager (RMAN) backup stored in Object Storage.

Prerequisites

You'll need the following:

Assumptions

The procedures below assume the following:

  • A new DB system has been created to host the restored database and no other database exists on the new DB system. It is possible to restore to a DB system that has existing databases, but that is beyond the scope of this topic.

  • The original database is lost and all that remains is the latest RMAN backup. The procedure assumes the DB system (inclusive of the database) no longer exists.

    Note:

    Any data not included in the most recent backup will be lost.
  • The Oracle Wallet and/or encryption keys used by the original database at the time of the last backup is available.
  • The RMAN backup contains a copy of the control file and spfile as of the most recent backup as well as all of the datafile and archivelog backups needed to perform a complete database recovery.
  • An RMAN catalog will not be used during the restore.

Related Topics

Set Up Storage on the DB system

  1. SSH to the DB System. 
    ssh -i <private_key_path> opc@<db_system_ip_address>
  2. Log in as opc and then sudo to the root user. Use sudo su - with a hyphen to invoke the root user's profile, which will set the PATH to the dbcli directory (/opt/oracle/dcs/bin). 
    login as: opc
sudo su -
  3. You can use an existing empty database home or create a new one for the restore. Use the applicable commands to help you complete this step.

    If you will be using an existing database home:

    • Use the Dbhome Commands to list the database homes. 

      dbcli list-dbhomes
      Output:
      ID                                       Name                 DB Version Home Location
---------------------------------------- -------------------- ---------- ---------------------------------------------
2e743050-b41d-4283-988f-f33d7b082bda     OraDB12102_home1     12.1.0.2   /u01/app/oracle/product/12.1.0.2/dbhome_1

    • Use the Database Commands to ensure the database home is not associated with any database.

    If necessary, use the Dbhome Commands to create a database home for the restore.

  4. Use the Dbstorage Commands to set up directories for DATA, RECO, and REDO storage. The following example creates 10GB of ACFS storage for the rectest database.
    dbcli create-dbstorage --dbname rectest --dataSize 10 --dbstorage ACFS

    Note:

    When restoring a version 11.2 database, ACFS storage must be specified.

Perform the Database Restore and Recovery

  1. SSH to the DB system, log in as opc, and then become the oracle user.
    sudo su - oracle
  2. Create an entry in /etc/oratab for the database. Use the same SID as the original database.
    db1:/u01/app/oracle/product/12.1.0.2/dbhome_1:N
  3. Set the ORACLE_HOME and ORACLE_SID environment variables using the oraenv utility.
    . oraenv
  4. Obtain the DBID of the original database. This can be obtained from the file name of the controlfile autobackup on the backup media. The file name will include a string that contains the DBID. The typical format of the string is c-DDDDDDDDDDDD-YYYYMMDD-NN where DDDDDDDDDDDD is the DBID, YYYYMMDD is the date the backup was created, and NN is a sequence number to make the file name unique. The DBID in the following examples is 1508405000. Your DBID will be different.

    Use the following curl syntax to perform a general query of Object Storage. The parameters in red are the same parameters you specified when installing the backup module as described in Installing the Backup Module on the DB System in Back Up a Database to Object Storage Using RMAN. 

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

    To look up the region name, see Regions and Availability Domains.

    For example:

    curl -u 'djones@mycompany.com:1cnk!d0++ptETd&C;tHR' -v https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/myobjectstoragenamespace

    To get the DBID from the control file name, use the following syntax:

    curl -u '<user_id>.com:<auth_token>' -v https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/<object_storage_namespace>/<bucket_name>?prefix=sbt_catalog/c-

    For example:

    curl -u 'djones@mycompany.com:1cnk!d0++ptETd&C;tHR' -v https://swiftobjectstorage.<region_name>.oraclecloud.com/v1/myobjectstoragenamespace/dbbackups/?prefix=sbt_catalog/c-

    In the sample output below, 1508405000 is the DBID.

    {
    "bytes": 1732,
    "content_type": "binary/octet-stream",
    "hash": "f1b61f08892734ed7af4f1ddaabae317",
    "last_modified": "2016-08-11T20:28:34.438000",
    "name": "sbt_catalog/c-1508405000-20160811-00/metadata.xml"
}
  5. Run RMAN and connect to the target database. There is no need to create a pfile or spfile or use a backup controlfile. These will be restored in the following steps. Note that the target database is (not started). This is normal and expected at this point.
    rman target /
    Output:
    Recovery Manager: Release 12.1.0.2.0 - Production on Wed Jun 22 18:36:40 2016
Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.
connected to target database (not started)
  6. Set the DBID using the value obtained above.
    set dbid 1508405000;
  7. Run the following command. If the server parameter file is not available, RMAN attempts to start the instance with a dummy server parameter file. The ORA-01078 and LRM-00109 errors are normal and can be ignored.
    STARTUP NOMOUNT
    startup failed: ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/u01/app/oracle/product/12.1.0.2/dbhome_1/dbs/initdb1.ora'
 
starting Oracle instance without parameter file for retrieval of spfile
Oracle instance started
 
Total System Global Area    2147483648 bytes
 
Fixed Size                     2944952 bytes
Variable Size                847249480 bytes
Database Buffers            1254096896 bytes
Redo Buffers                  43192320 bytes
  8. Restore the server parameter file from autobackup.

    The SBT_LIBRARY is the same library specified with the -libDir parameter when the Backup Module was installed, for example /home/oracle/lib/.

    The OPC_PFILE is the same file specified with the -configfile parameter when the Backup Module was installed, for example /home/oracle/config. 

    set controlfile autobackup format for device type sbt to '%F';
run {
  allocate channel c1 device type sbt PARMS  'SBT_LIBRARY=/home/oracle/lib/libopc.so, SBT_PARMS=(OPC_PFILE=/home/oracle/config)';
  restore spfile from autobackup;
}
  9. Create the directory for audit_file_dest. The default is /u01/app/oracle/admin/$ORACLE_SID/adump. You can see the setting used by the original database by searching the spfile for the string, audit_file_dest.
    strings ${ORACLE_HOME}/dbs/spfile${ORACLE_SID}.ora | grep audit_file_dest
*.audit_file_dest='/u01/app/oracle/admin/db1/adump'
 
mkdir -p /u01/app/oracle/admin/db1/adump
  10. If block change tracking was enabled on the original database, create the directory for the block change tracking file. This will be a directory under db_create_file_dest. Search the spfile for the name of the directory.
    strings ${ORACLE_HOME}/dbs/spfile${ORACLE_SID}.ora | grep db_create_file_dest
*.db_create_file_dest='/u02/app/oracle/oradata/db1'
 
mkdir -p /u02/app/oracle/oradata/db1/<$ORA_UNQNAME if available or database name>/changetracking
  11. Restart the instance with the restored server parameter file.
    STARTUP FORCE NOMOUNT;
  12. Restore the controlfile from the RMAN autobackup and mount the database. 
    set controlfile autobackup format for device type sbt to '%F';
run {
  allocate channel c1 device type sbt PARMS 'SBT_LIBRARY=/home/oracle/lib/libopc.so, SBT_PARMS=(OPC_PFILE=/home/oracle/config)';
  restore controlfile from autobackup;
  alter database mount;
}
  13. Restore and recover the database.
    RESTORE DATABASE;
RECOVER DATABASE;
  14. RMAN will recover using archived redo logs until it can't find any more. It is normal for an error similar to the one below to occur when RMAN has applied the last archived redo log in the backup and can't find any more logs.
    unable to find archived log
archived log thread=1 sequence=29
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 06/28/2016 00:57:35
RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 29 and starting SCN of 2349563
  15. Open the database with resetlogs.
    ALTER DATABASE OPEN RESETLOGS;

The recovery is complete. The database will have all of the committed transactions as of the last backed up archived redo log.