Thank you very much for your interest.
In this post I will show you how does rman clone work and some important consideration before you choose this option.
Problem statement:Assume you are requested to clone using rman backupset and due to some security restriction you can not connect source database using sys schema.Your backupsets have been mounted in a NFS filesystem.One more challenge is source database backup is not done using catalog connection.
Yes, this is the ideal use case for this feature.
This feature has been present since 11gR2 and you can find below MOS note
RMAN 11GR2 : DUPLICATE Without Target And Recovery Catalog Connection (Doc ID 874352.1)
Lets understand steps involved in this rman clone.
- start an auxiliary instance in nomount mode.
- execute duplicate command like below
{
allocate auxiliary channel aux1 device type disk;
allocate auxiliary channel aux2 device type disk;
allocate auxiliary channel aux3 device type disk;
allocate auxiliary channel aux4 device type disk;
duplicate database 'sourcedb' dbid 933269695 to targetdb
spfile
set control_files='+DATA/targetdb/control01.ctl'
set db_file_name_convert='DBNAME','targetdb'
set log_file_name_convert='DBNAME','targetdb'
set diagnostic_dest='/u01/app/oracle'
set log_archive_dest_1='LOCATION=+RECO/targetdb/'
backup location '/Absolute NFS path';
}
Note:you can add until until time "to_date('2025-06-07 06:35:00','YYYY-MM-DD HH24:MI:SS')"
just before spfile.In that case rman will try to macth controlfile/spfile backup slightly greater than your choosen timestamp
Lets explore this command...
- First rman will search for DBID in the backup location we have mentioned.To do that it will search for the deafult unique file name for controlfile backupset which starts with c-DBID-YYYYMMDD.
So if that backup location contains backup of other database then your rman clone will fail to decide which dbid to consider and fail.
RMAN-03002: failure of Duplicate Db command at 06/06/2025 12:02:44
RMAN-05501: aborting duplication of target database
RMAN-05657: There are multiple database IDs present.
- Now rman will restore SPFILE from the controlfile autobackupset which includes spfilebackup also.
- After SPFILE restoration it will bring up instance with SPFILE and execute our set statements mentioned in the script like alter system set control_files='+DATA/targetdb/control01.ctl'
- In this step 2 important changes are happening. It will try to restore control file and before controlfile restoration it will change parameter db_name as sourcedb and db_unique_name as targetdb
- At this stage database is mounted using restored control file
- Now,this is an interesting step where it finds scn number from the control file and try to recover until that scn.So rman internally creates script like below set until scn XXXXXXXX --> This scn is same as checkpoint_change# column in v$database.Convert this scn to timestamp in source database and capture the timestamp
SCN_TO_TIMESTAMP(39262372810498)
---------------------------------------------------------------------------
06-JUN-25 05.31.01.000000000 PM
Similary capture checkpoint scn of last controlfile backup using rman command list backup of controlfile
Control File Included: Ckp SCN: 39262372814562 Ckp time: 2025-06-06 19:48:56
So we see there is a difference.Basically during recovery it will find last archivelog backup which is close to controlfile checkpoint scn 39262372814562 and roll forward upro that scn.
We shall also see below command
set newname for datafile 1 to "+DATA";
Basically in this step controlfile is updated with new path where datafile needs to be restored
- In the next step Datafiles will be restored from Level 0 backupsets
- After successful restoration we can see below command where RMAN will recover the database in 2 phases.In first phase it will apply all incremental backups and then apply archivelog backups until last scn is close to last controlfile backup.
recover
clone database
delete archivelog
- After recovery db_name is updated using alter system set DB_NAME=<targetdb>
- Controlfile is recreated to change the database name using resetlogs option.
- All the datafiles are cataloged to resgister in control file
- Database is now opened cleaned.
Important points to be considered:-
- If you dont mention log_archive_dest_1 parameter correctly you will end up restoring archivelog in $ORACLE_HOME/dbs and filling up the file system.It will also delete archivelog files without even applying anything.You can see below kind of message in RMAN log
archived log file name=/u01/app/oracle/product/19.0.0.0/dbhome_3/dbs/arch1_62_1202746759.dbf thread=1 sequence=62
- If your source database SPFILE has obsolete parameter rman clone will fail to bring up the instance using that SPFILE.So either you remove that parameter in rman command using set statement or update source SPFILE parameter
- If you are doing timestamp based duplication then you have to be very careful in timestamp selection.Lets say your last controlfile autobackup completed with checkpoint time as 2025-06-07 07:05:20 and obviously you choose until timestamp less than that.Lets say you choose 2025-06-07 07:04:00. It may or may not be successful based on last archivelog backup.What I mean to say if your highest scn timestamp covered by the arcivelog is greater then your choosen timestmap.To find out what is the highest SCN captured you can use below rman command for example list backup of controlfile completed after "to_date('2025-06-07 07:00:00','YYYY-MM-DD HH24:MI:SS')";
Thrd Seq Low SCN Low Time Next SCN Next Time
---- ------- ---------- ------------------- ---------- ---------
1 85293 39262463706979 2025-06-07 06:05:04 39262464123178 2025-06-07 06:35:03
So you see that your next_time is lower than your choosen timestamp and Rman can not recover beyond this time.So highly likely it will fail.
Same has been explained in MOS note RMAN DUPLICATE FAILURE RMAN-05501 RMAN-06617 (Doc ID 1646262.1)
I hope you have learnt something useful..
