Introduction :
RMAN has the ability to duplicate, or clone, a database from a backup or from an active database.
It is possible to create a duplicate database on a remote server with the same file structure,
or on a remote server with a different file structure or on the local server with a different file structure.
For some old and non patched Oracle versions such as that earlier than 11.2.0.4 , the duplicate (from active or backup) can be a real
challenge even for those DBAs with years of experience, due to different bugs encountered.
The scenario specified below will focus on control file issues revealed by duplication from active database an Oracle 11.2.0.2 version EE.
<INFO>Make sure to use nohup command line-utility which allows to run command/process or shell script.
Demonstration :
Step1: Prepare your script:
vi script_duplicate.ksh #!/bin/ksh export ORACLE_HOME=$ORACLE_HOME export PATH=$PATH1:$ORACLE_HOME/bin rman target sys/pwd@TNS_NAME_TARGET auxiliary sys/pwd@TNS_NAME_AUXILIARY log=duplicate.log cmdfile=/home/oracle/rman_bkup.cmd vi rman_bkup.cmd run { allocate channel ch1 device type disk; allocate channel ch2 device type disk; allocate channel ch3 device type disk; allocate auxiliary channel dh1 device type disk; allocate auxiliary channel dh2 device type disk; allocate auxiliary channel dh3 device type disk; duplicate target database to <AUXILIARY_NAME> from active database nofilenamecheck; release channel ch3; release channel ch2; release channel ch1; } and launch like that : nohup ./script_duplicate.ksh &
Step2: Check instance parameters.
Depending on the PSU level of your instance, even before starting the duplicate, can fail with this error.
RMAN-00571: =================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS RMAN-00571: =================================================== RMAN-03002: failure of Duplicate Db command at 11/02/2011 06:05:48 RMAN-04014: startup failed: ORA-00600: internal error code, arguments: [kck_rls_check must use (11,0,0,0,0) or lower], [kdt.c], [9576], [11.2.0.2.0], [], [], [], [], [], [], [], [] RMAN-04017: startup error description: ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance RMAN-03015: error occurred in stored script Memory Script RMAN-04014: startup failed: ORA-00600: internal error code, arguments: [kck_rls_check must use (11,0,0,0,0) or lower], [kdt.c], [9576], [11.2.0.2.0], [], [], [], [], [], [], [], [] RMAN-04017: startup error description: ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance
According with Oracle Support note : 1064264.1
1. Edit the pfile, add parameter: _compression_compatibility= "11.2.0" 2. Restart the instance using the pfile SQL> startup pfile='<fullpath name of pfile>' 3. Create the SPFILE again SQL> create spfile from pfile; 4. Restart the instance with the SPFILE SQLl> shutdown immediate; SQL> startup and relaunch the previous command (Step 1).
Step3 : Control file issue, trying to open the database.
After transferring the datafiles , your duplicate will crash with these errors , trying to open the database.
RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of Duplicate Db command at 15/07/2018 17:39:30 RMAN-05501: aborting duplication of target database RMAN-03015: error occurred in stored script Memory Script SQL> alter database open resetlogs; alter database open resetlogs * ERROR at line 1: ORA-19838: Cannot use this control file to open database
Basically is because of a known bug (Bug 11063122 in 11gr2).
Controlfile created during the duplicate in 11gr2 will store redolog file locations as of primary.
We need to recreate control file changing the locations of redo logfiles and datafiles and open database with resetlogs.
In the controlfile recreation script the database name is the source <db_name> and the directory names for redo logs are still pointing to the source database .
The workaround is :
1. Backup as trace your control file (cloned DB) sql> alter database backup controlfile to trace ; 2. Open the file , and extract the section RESETLOGS, to modify like that : CREATE CONTROLFILE REUSE DATABASE "<src_db_name>" RESETLOGS ARCHIVELOG MAXLOGFILES 16 MAXLOGMEMBERS 3 MAXDATAFILES 100 MAXINSTANCES 8 MAXLOGHISTORY 11680 LOGFILE GROUP 9 '<path_of_the_cloned_DB>redo09.log' SIZE 150M BLOCKSIZE 512, GROUP 10 '<path_of_the_cloned_DB>/redo10.log' SIZE 150M BLOCKSIZE 512, GROUP 11 '<path_of_the_cloned_DB>/redo11.log' SIZE 150M BLOCKSIZE 512, DATAFILE '<path_of_the_cloned_DB>/system01.dbf', '<path_of_the_cloned_DB>/undotbs01.dbf', '<path_of_the_cloned_DB>/sysaux01.dbf', '<path_of_the_cloned_DB>/users01.dbf', -------------more datafiles CHARACTER SET EE8ISO8859P2; Save as trace_control.ctl 3. SQL> alter system set db_name=<new db_name> scope=spfile; 4. SQL> startup nomount 5. SQL>@trace_control.ctl --control file created and multiplexed in all the destinations mentioned on your spfile 6. SQL> alter database open resetlogs
<INFO>If your source db had activity during the duplicate process you should apply manually some required archivelogs.
RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of alter db command at 15/07/2018 19:21:30 ORA-01152: file 1 was not restored from a sufficiently old backup ORA-01110: data file 1: '/u01/oradata/DBName/system01.dbf'
Search on source database , for those archivelogs with sequence# greater or equal to 399747 and apply them manually on the target DB.
If somehow those are not available you need to take an incremental backup to roll forward your cloned database.
7. SQL> recover database using backup controlfile; ORA-00279: change 47260162325 generated at 15/07/2018 19:27:40 needed for thread 1 ORA-00289: suggestion : <path>o1_mf_1_399747_%u_.arc ORA-00280: change 47260162325 for thread 1 is in sequence #399747 Once the required archivelogs files have been applied , try again to open your database: RMAN> alter database open resetlogs; database opened RMAN> exit
Conclusion :
If you’re the kind of Oracle administrator who has the power to approve or deny, you must know how dangerous it is to run your applications with non patched Oracle databases.
Your data within your organization is better protected if your are taking advantage of patches issued by Oracle and running your production data against supported Oracle versions only.