Oracle EE 11.2.0.2 RMAN Duplicate interesting issue - is it a bug?

Question

Hi,
Oracle EE 11.2.0.2 RHEL 5.7 x86 64-bit RACOne Node database (3 - nodes).
I was working on a process to refresh out test environment with prod database backup from tape and i have done it many times. Most of our environment is in 10gR2 and have few on 11.2.0.2 RACOne Node databases. The recovery basics in Oracle world is to use archive log sequence + 1 (provided we know before hand the backups metadata) and it works as expected until 10g but with 11.2.0.2 RMAN duplicate, i stumbled upon an issue where RMAN is trying to restore an older controlfile auto backup and then rolling forward from there. Its easy to explain with an example..
1) I have an archivelog backup, say sequence 20 to 30 on Feb 22nd @ 10pm and a controlfile autobackup at this time c-20120222
2) I have a FULL backup + archive log until sequence 50 on Feb 23nd@ 6pm and a controlfile autobackup at this time  c-20120223
3) I am using RMAN duplicate to refresh UAT with Feb 23rd backup and use "set until sequence 51 thread 1"I am using following RMAN commands to do the duplicate on UAT server (executed on UAT server)
rman target sys/***@PROD_DB  auxiliary /
RMAN> run
2> {
3> allocate auxiliary channel c1 device type disk;
4> allocate auxiliary channel c2 device type disk;
5> allocate auxiliary channel c3 device type disk;
6> set until sequence 51 thread 1;
7> duplicate target database to UAT_DB;
8> }RMAN duplicate automates all that we do manually but the recovery mechanism is same. In the above scenario, it connects to target database, gets the backup metadata and restores controlfile from c-20120223 , restores the datafiles and recovers till sequence 50 . This has been the scenario until 10g in every RMAN duplicate process i have tried and is expected from Oracle.
Issue:
In 11gR2 (11.2.0.2), for the same duplicate scenario above, it is restoring the controlfile from autobackup c-20120222 and restoring the datafiles from Feb 23rd backup, recovering till sequence 50 and doing the duplicate process. The thing to note here is that the controlfile autobackup c-20120222 does not have any record of the FULL backup that occured on Feb 23 rd and since RMAN duplicate is having a connection to target database, it knows the backup metadata and hence it is able to complete the recovery.
For clarification, Thread 1 & 2 of RAC One Node is not an issue here for sure. Did anyone experience this issue? Any insight into this would be greatly appreciated.
Thanks,
Shiva

Answer 1

AJ,
I have already tried that scenario, i renamed the c-20120222 and kicked off the same duplicate process but it failed and it kept on "fail-over to previous backup" which is expected. The thing is, RMAN look's for the control file autobackups from newest to oldest (unless you gave a point in time) and duplicate command is not doing it.
Tycho,
I agree there are new features but to support them a change in recovery mechanism is something i would disagree that Oracle would do. Active Duplication is not based on backups, so that is out of question here. For backup-based duplication, we can try with connections to target or targetless, catalog or catalogless or none. I have already given an example with the target (same with target + catalog) and i expect the same behavior with only catalog connection. Now, i have tested the example without connecting to target or catalog and below are my observations...
For the same backups i mentioned in the very first email, i got the following info....
rman target /
Recovery Manager: Release 11.2.0.2.0 - Production on Fri Feb 24 12:35:54 2012
Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.
connected to target database: RMANTEST (DBID=3789692530)
RMAN> list backup of archivelog sequence 95;
using target database control file instead of recovery catalog
List of Backup Sets
===================
BS Key  Size       Device Type Elapsed Time Completion Time
11      2.50K      DISK        00:00:00     23-FEB-12 18:05:40
        BP Key: 11   Status: AVAILABLE  Compressed: YES  Tag: TAG20120222T094240
        Piece Name: /u01/app/oracle/exp/rmantest_stl/full_backup/rmantest_stl_0bn3upkg_1_1.arch
  List of Archived Logs in backup set 11
  Thrd Seq     Low SCN    Low Time           Next SCN   Next Time
  1    95      346280     23-FEB-12 18:05:10 346302     23-FEB-12 18:05:30I got the scn_to_timestamp for the NEXT_SCN of sequence 95, which should correpond tothe "Next Time" that is the timestamp for the Archive log sequence 96.
SQL> select scn_to_timestamp(346302) as timestamp from dual;
TIMESTAMP
23-FEB-12 18.05.30.000000000 PMNow, i gave the following for targetless & catalogless duplication...
rman auxiliary /
RMAN> run
2> {
3> set until time "to_date('23-FEB-12 18:05:30','DD-MON-YY HH24:MI:SS')";
4> duplicate database to rman01s backup location '/u01/app/oracle/exp/rmantest_stl';
5> }RESULT: Same ISSUE but this time IT FAILED with the error i expected. It went ahead and restored the c-20120222 autobackup control file and tried to restore the datafiles but, as we
know, this control file autobackup does not have record of Feb 23rd + archive log backup, so it FAILS. This is exactly what i told in my first email.
Error Log File:
contents of Memory Script:
   sql clone "alter system set  control_files =
  ''+RMAN01D_DATA/rman01s_stl1/controlfile/current.270.776081841'', ''+RMAN01D_RECO/rman01s_stl1/controlfile/current.263.776081841'' comment=
''Set by RMAN'' scope=spfile";
   sql clone "alter system set  db_name =
''RMANTEST'' comment=
''Modified by RMAN duplicate'' scope=spfile";
   shutdown clone immediate;
   startup clone force nomount
   restore clone primary controlfile from  '/u01/app/oracle/exp/rmantest_stl/c-20120222';
   alter clone database mount;
Errors in memory script
RMAN-03015: error occurred in stored script Memory Script
RMAN-06136: ORACLE error from auxiliary database: ORA-01507: database not mounted
ORA-06512: at "SYS.X$DBMS_RCVMAN", line 13371
ORA-06512: at line 1
RMAN-03015: error occurred in stored script Memory Script
RMAN-06026: some targets not found - aborting restore
RMAN-06023: no backup or copy of datafile 5 found to restore
RMAN-06023: no backup or copy of datafile 4 found to restore
RMAN-06023: no backup or copy of datafile 3 found to restore
RMAN-06023: no backup or copy of datafile 2 found to restore
RMAN-06023: no backup or copy of datafile 1 found to restore
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 02/24/2012 10:18:04
RMAN-05501: aborting duplication of target databaseSo, my next test was not to give any Point In Time, that is just issue the duplicate without SET UNIL clause and this time, and this time it behaved, it restored the control file from c-20120223 and completed the duplicate process. So what does this tell us? We cannot do a POINT IN TIME duplicate using RMAN DUPLICATE????
rman auxiliary /
RMAN> run
2> {
3> duplicate database to rman01s backup location '/u01/app/oracle/exp/rmantest_stl';
4> }
contents of Memory Script:
   sql clone "alter system set  control_files =
  ''+RMAN01D_DATA/rman01s_stl1/controlfile/current.270.776089489'', ''+RMAN01D_RECO/rman01s_stl1/controlfile/current.263.776089489'' comment=
''Set by RMAN'' scope=spfile";
   sql clone "alter system set  db_name =
''RMANTEST'' comment=
''Modified by RMAN duplicate'' scope=spfile";
   shutdown clone immediate;
   startup clone force nomount
   restore clone primary controlfile from  '/u01/app/oracle/exp/rmantest_stl/c-20120223';
   alter clone database mount;
}Just checking if anyone stumbled upon these findings. An Oracle SR is already in place, so just waiting for an update from them.
Thanks,
Shiva