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
Environment
Source System: On Premise Primary | Target System: Cloud Hosted Standby |
|
|
- Created an RMAN backup of the Primary Database DAD on prem host kiwi701
- Activated the Standby DAD database on cloud host kiwicld702
- On on-prem host kiwi701 shutdown abort, removed all datafiles, log files from primary.
- On host kiwi701 ; Restore database controlfile from backup taken in Step 1. Then restored Database from backup taken in step one.
- On host kiwi701, from the NEWLY restored database. Created a standby Controlfile to reflect current datafile structure
- Shutdown database on prem host kiwi701.
- Renamed new standby controlfile to reflect locations in the spfile for database.
- Started database in mount mode and confirmed that on-prem host kiwi701 it was now a standby database.
- On cloud host kiwicld702 checked the last applied log in alert log before the activation to a primary database.
- On cloud host kiwicld702 switched logfiles to generate new logfiles as a new primary database.
- MANUALLY copied the logfiles created from step 10. to the on-prem host kiwi701
- Using RMAN on prem host kiwi701, checked current incarnation of standby database.
- Using RMAN catalogued the new transferred files from step 11.
- Using RMAN checked the new incarnation of standby database
- Recovered standby database with RMAN.
- Recovered Standby database with sqlplus.
- Using Dbvisit Standby send/apply logs from Cloud host to on-prem standby.
- Confirmed log gap was 0
- Performed Graceful switchover between Cloud host primary and on-prem standby.
- 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;
PRIMARY
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;
STANDBY
9.Check on the new Primary/Old Standby that last log applied before it was activated
ALTER DATABASE RECOVER LOGFILE
'/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
Comments