We're here to help!

Using an on Premise Primary Database Backup to Create a Standby after Activating your Standby in the Cloud


Read our docs Consider the following scenario : Your Primary Database in on-Prem and your Standby Database is hosted within the cloud. For DR testing purposes, your Business Continuity Plan calls for regular switchovers to the Standby.  However, activating the Standby is destructive and requires to be rebuilt after the Standby testing completes.  With large databases, this transfer of backups to the cloud to rebuild the standby can be expensive.  This article proposes a way of using the databases in their state after activation to re-create the environment without transferring backup between the 2 sites.

Problem Details

Problem Statement

Rebuilding a Cloud hosted Standby Database after Activation, without the need to transfer a new RMAN backup.

Tested Versions

11gR2 and 12cR2 


Source System: On Premise Primary   Target System: Cloud Hosted Standby
  • Oracle Linux 6.4 x86_64
  • Oracle RDBMS
    • Hostname – kiwi701
    • Dbvisit Standby 8.0.18
    • Database Name :  DAD
  • Oracle Linux 6.4 x86_64
  • Oracle RDBMS
    • Hostname – kiwicld702
    • Dbvisit Standby 8.0.18
    • Database Name :  DAD
Overview of Steps Performed
  1. Created an RMAN backup of the Primary Database DAD on prem host kiwi701
  2. Activated the Standby DAD database on cloud host kiwicld702
  3. On on-prem host kiwi701 shutdown abort, removed all datafiles, log files from primary.
  4. On host kiwi701 ; Restore database controlfile from backup taken in Step 1.  Then restored Database from backup taken in step one.
  5. On host kiwi701, from the NEWLY restored database.  Created a standby Controlfile to reflect current datafile structure
  6. Shutdown database on prem host kiwi701.
  7. Renamed new standby controlfile to reflect locations in the spfile for database.
  8. Started database in mount mode and confirmed that on-prem host kiwi701 it was now a standby database.
  9. On cloud host kiwicld702 checked the last applied log in alert log before the activation to a primary database.
  10. On cloud host kiwicld702 switched logfiles to generate new logfiles as a new primary database.
  11. MANUALLY copied the logfiles created from step 10. to the on-prem host kiwi701
  12. Using RMAN on prem host kiwi701, checked current incarnation of standby database.
  13. Using RMAN catalogued the new transferred files from step 11.
  14. Using RMAN checked the new incarnation of standby database
  15. Recovered standby database with RMAN.
  16. Recovered Standby database with sqlplus.
  17. Using Dbvisit Standby send/apply logs from Cloud host to on-prem standby.
  18. Confirmed log gap was 0
  19. Performed Graceful switchover between Cloud host primary and on-prem standby.
  20. Confirmed setup is now as it was in Step 1.  On prem Primary with Cloud hosted Standby.

Detail of Steps Performed

1. RMAN> backup database including archivelog;
2. [oracle@kiwicld702 /usr/dbvisit/standby]$ ./dbvctl -d DAD -o activate
3. SQL> shutdown abort, $ rm /u01/app/oracle/oradata/DAD/*
4. RMAN> startup nomount;
RMAN> restore controlfile from '/u01/app/oracle/fast_recovery_area/DAD/backup/c-1288681010-20180209-05'
    RMAN> alter database mount;
Statement processed

RMAN> restore database;
SQL> select database_role from v$database;
5.SQL> alter database create standby controlfile as '/u01/app/oracle/oradata/DAD/control01_stby.ctl';
6.SQL> shutdown immediate;
7.[oracle@kiwi701 /u01/app/oracle/oradata/DAD]$ cp control01_stby.ctl control01.ctl [oracle@kiwi701 /u01/app/oracle/oradata/DAD]$ cp control01_stby.ctl control02.ctl
8. SQL> startup mount;
SQL> select database_role from v$database;
9.Check on the new Primary/Old Standby that last log applied before it was activated
'/u01/app/oracle/dbvisit_arch/DAD/1_27_967648693.arc' 2018-02-09T17:15:45.960708+13:00 Media Recovery Log /u01/app/oracle/dbvisit_arch/DAD/1_27_967648693.arc ORA-279 signalled during: ALTER DATABASE RECOVER LOGFILE
'/u01/app/oracle/dbvisit_arch/DAD/1_27_967648693.arc' ... ALTER DATABASE RECOVER CANCEL 2018-02-09T17:15:46.036342+13:00 Media Recovery Canceled Completed: ALTER DATABASE RECOVER CANCEL 2018-02-09T17:17:37.801156+13:00 alter database activate standby database 2018-02-09T17:17:37.801251+13:00 ALTER DATABASE ACTIVATE [PHYSICAL] STANDBY DATABASE [Process Id: 7630] (DAD) ... ACTIVATE STANDBY: Complete - Database mounted as primary
10.SQL> alter system switch logfile;
SQL> alter system switch logfile;
11. $ scp arch1_* oracle@kiwi701:/tmp/arch/log
12. RMAN> list incarnation;
using target database control file instead of recovery catalog List of Database Incarnations DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ---------------- --- ---------- ---------- 1 1 DAD 1288681010 PARENT 1 26/01/2017:13:52:29 2 2 DAD 1288681010 CURRENT 1408558 09/02/2018:15:18:13
13. RMAN> catalog start with '/tmp/arch/log';
List of Files Unknown to the Database
===================================== File Name: /tmp/arch/log/arch1_1_967655858.dbf File Name: /tmp/arch/log/arch1_2_967655858.dbf
Do you really want to catalog the above files (enter YES or NO)? Yes
cataloging files...
cataloging done
14. List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ---------------- --- ---------- ---------- 1 1 DAD 1288681010 PARENT 1 26/01/2017:13:52:29 2 2 DAD 1288681010 PARENT 1408558 09/02/2018:15:18:13 3 3 DAD 1288681010 CURRENT 1527608 09/02/2018:17:17:38
15. RMAN> recover database;
Starting recover at 09/02/2018:18:26:58 allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=15 device type=DISK starting media recovery archived log file name=/tmp/arch/log/arch1_1_967655858.dbf thread=1 sequence=1 archived log file name=/tmp/arch/log/arch1_2_967655858.dbf thread=1 sequence=2 media recovery complete, elapsed time: 00:00:03 Finished recover at 09/02/2018:18:27:02
16. SQL> recover automatic standby database;
ORA-00283: recovery session canceled due to errors ORA-38868: warning: the control file may have incorrect data file structure
Even with this error, it is possible to send and apply logs with Dbvisit Standby
17. [oracle@kiwicld702 /usr/dbvisit/standby]$ ./dbvctl -d DAD [oracle@kiwi701 /usr/dbvisit/standby]$ ./dbvctl -d DAD
18. Using Dbvisit CLI or GUI checked log gap report is 0
19. Using Dbvisit CLI or GUI Perform graceful switchover.Using Dbvisit CLI or GUI 20. [oracle@kiwi701 /usr/dbvisit/standby]$ sqlplus / as sysdba
SQL> select database_role from v$database; DATABASE_ROLE ---------------- PRIMARY
oracle@kiwicld702 /usr/dbvisit/standby]$ sqlplus / as sysdba
SQL> select database_role from v$database; DATABASE_ROLE ---------------- PHYSICAL STANDBY
Have more questions? Submit a request