If you duplicate a database to a higher version, you would restore a RMAN backup and upgrade that. Using duplicate would fail (ORA-39700) since it shall open the auxiliary with resetlogs.
In RMAN 12c, the “NOOPEN” option is available, requesting RMAN to complete the duplicate activity but NOT open the auxiliary database (this would allow for the ‘open upgrade’ option to be manually executed when going between versions).
Source: https://support.oracle.com/epmos/faces/DocumentDisplay?id=2022820.1
Remember https://oracle.powerbytes.nl/ever-ran-into-an-ora-19755-with-rman/ ?
RMAN duplicate fails to create BCT file despite fix of bug 11744544 !!
Bug 18371441 : RMAN DUPLICATE FAILS TO CREATE BCT FILE
Created 09-03-2014, fixed in version 12.2
ORA-00283: recovery session canceled due to errors
ORA-19755: could not open change tracking file
ORA-19750: change tracking file: '+DATA/rac2prd/changetracking/ctf.2646.835861329'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
---
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 01/23/2016 21:44:21
RMAN-05501: aborting duplication of target database
RMAN-03015: error occurred in stored script Memory Script
ORA-00283: recovery session canceled due to errors
RMAN-11003: failure during parse/execution of SQL statement: alter database reco
ver logfile '+DATA2/oracle/AUX/archivelog/2016_01_23/o1_mf_1_98404_urqs4ef3_.
arc'
ORA-00283: recovery session canceled due to errors
ORA-19755: could not open change tracking file
ORA-19750: change tracking file: '+DATA/rac2prd/changetracking/ctf.2646.835861329'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Solve with Patch 18371441
A workaround would be to disable change tracking before duplicating.
Ever ran into an ORA-19755 with RMAN duplicate from target? When your source database uses block change tracking?
Try patch 11744544; it fixes the bug which could might cause block change tracking recreation fail in combination with OMF newnames.
A workaround would be to disable change tracking before duplicating.
RMAN> run {
allocate channel d1 type disk format='/tmp/%U';
backup tablespace sysaux;
}
The fake tape library will call the MML APIs, essentially similar to an MML backup, but will place the file on disk (RMAN disksbt library emulates a SBT library). It cannot be used for production backups but can be used for verification purposes such as these:
RMAN> run {
allocate channel t1 type 'SBT' PARMS 'SBT_LIBRARY=oracle.disksbt,ENV=(BACKUP_DIR=/tmp)';
backup tablespace sysaux;
}
The fake tape backup comes in handy when one wants to backup the recovery area; the ‘backup recovery area’ command only works with SBT channels. FRA backup to disk does not work.
… can cause a nasty ORA-19571. Reason? You are using a control file as RMAN catalog and obviously more space is needed than available..
Try:
sql> alter system set control_file_record_keep_time=14 scope=both;
More info: Oracle’s Metalink Doc ID: 563219.1
and
http://download.oracle.com/docs/cd/B12037_01/server.101/b10755/initparams027.htm