Quite interesting question was asked by one of our customers:
“Is it possible/supported to do RMAN DUPLICATE FOR STANDBY FROM ACTIVE DATABASE when TARGET is STANDBY ?”
It’s really seasonable question, especially when You already have standby database and wanna refresh a development environment using standby as a source/target to not stress primary database .
There are no such restriction in 11.2 “Prerequisites Specific to Active Database Duplication”, so why not ? 😉
But even Oracle wanted to provide mentioned functionality it’s not often used(tested), so let’s see what we get as a result
Here I’ll post only relevant steps with resulting error messages.
allocate channel prmy1 type disk;
allocate auxiliary channel stby type disk;
duplicate target database for standby from active database
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-03002: failure of Duplicate Db command at 03/23/2012 15:10:56
RMAN-05501: aborting duplication of target database
RMAN-03015: error occurred in stored script Memory Script
RMAN-03009: failure of backup command on prmy1 channel at 03/23/2012 15:10:56
ORA-01671: control file is a backup, cannot make a standby control file
So RMAN wants to do one more backup control file, but is unable to do it because we already have one because of connected to standby as a target…
So what says MOS ?
OK, there is a NOTE: 1343515.1 RMAN ACTIVE DUPLICATE WHEN CONNECTED TO STANDBY AS TARGET
“The DUPLICATE FROM ACTIVE DATABASE using a Standy database as TARGET is fixed by
BUG:11715084 actually describes another situation because of different error message:
RMAN-05531: a mounted database cannot be duplicated while datafiles are fuzzy
but You may read latest update for this post at the bottom where I confirm that fix for this BUG also fix my original error(ORA-01671)
So what we have?
- it’s intended behaviour in 11.2 to support such case of DUPLICATE – that’s good!
- someone has tested it with 220.127.116.11 and filled SR after failure (Someone has mentioned this issue with 18.104.22.168 here, but without any luck)
- MOS NOTE states that it’s fixed in 12.1 and 22.214.171.124. I haven’t seen 12.1 yet, but it definitely doesn’t work with 126.96.36.199 – like in my environment.
- BUG 11715084 is not among the Bugs fixed in the 188.8.131.52 Patch Set, so I suspect that NOTE have to state about 184.108.40.206 patchset
- current(as of 23-MAR-2012) status on BUG:11715084 is “80 – Development to Q/A“, so how can it be fixed in 220.127.116.11 released in September-2011 ?
- it’s really very interesting/useful feature when it will work as intended
- it’s not critical issue and different workarounds may be used
- according to changes in document Bug 11715084 – Active duplicate should work when connected to Standby as source DB, this BUG will be fixed in 18.104.22.168, but now there are already some backports over 22.214.171.124 and one over 126.96.36.199.2 for Linux x86-64 – check PATCH:11715084 –
I’ll check it and provide feedback here
- I have checked proposed fix and confirm that it works fine after applying PATCH:11715084, so mentioned issue has working fix now and may be used as the procedure of creating cascading standbys.