The Problem
1. RMAN DUPLICATE fails as below:
input datafile copy recid=22 stamp=717598749 filename=/temp_datavol/clone_files/DUPTEST1/datafile/largetbl.298.684694005
datafile 24 switched to datafile copy
input datafile copy recid=23 stamp=717598749 filename=/temp_datavol/clone_files/DUPTEST1/datafile/audittbl.449.690377511
datafile 25 switched to datafile copy
input datafile copy recid=24 stamp=717598750 filename=/temp_datavol/clone_files/DUPTEST1/datafile/largetbl.988.713432115
contents of Memory Script:
{
Alter clone database open resetlogs;
}
executing Memory Script
Segmentation fault
The alert log for the auxiliary instance looks like this at the time of the failure:
.... Thu Apr 29 12:59:16 2010 Errors in file /u01/app/oracle/product/10.2/ora_10g/rdbms/log/duptest1_ora_10277.trc: ORA-00704: bootstrap process failure ORA-39700: database must be opened with UPGRADE option Thu Apr 29 12:59:16 2010 Error 704 happened during db open, shutting down database USER: terminating instance due to error 704 Termination issued to instance processes. Waiting for the processes to exit Thu Apr 29 12:59:26 2010 Instance termination failed to kill one or more processes Instance terminated by USER, pid = 10277 ORA-1092 signalled during: alter database open resetlogs...
OR
2. After restore/recover, ALTER DATABASE OPEN RESETLOGS fails with the following errors (as seen in the alert.log):
ORA-00704: bootstrap process failure ORA-39700: database must be opened with UPGRADE option
The Cause
1. Attempting to duplicate when there is installed different patchset level target and auxiliary. Example: Oracle version 10.2.0.2.0 and the auxiliary instance is using Oracle version 10.2.0.1.0 ( or the opposite ). DUPLICATE is not meant to be successful in the above situation, i.e., version mismatch.
OR
2. Similarly, if trying to restore and recover database using a higher version of the Oracle patchset. eg. database was backed up in Oracle 10.1 and need to be restored into a 10.2 $ORACLE_HOME.
Please review the upgrade compatibility matrix for the supported upgrade paths.
It is recommended that you restore and recover using the same patchset version of the software that was used to backup. For example, if you backed up using Oracle 10.1.0.1 then you should restore using Oracle 10.1.0.1. Sometimes this is not possible. Follow the steps below to restore using a higher patchset.
Please review the pre-upgrade documentation before proceeding with the steps below.
The Solution
1. Perform a complete restore and recovery of the database. For e.g.:
SQL> recover database
ORA-00279: change 537351029 generated at 02/27/2008 23:07:00 needed for thread 1
ORA-00289: suggestion : /u001/PROD/arch/PROD_1_528360.arc
ORA-00280: change 537351029 for thread 1 is in sequence #528360
Specify log: {=suggested | filename | AUTO | CANCEL}
AUTO
2. Once recover is completed, you should get a message similar to the following:
Log applied Media recovery complete
3. Open the database for migrate in SQL*Plus:
SQL> alter database open [resetlogs] upgrade;
RMAN> alter database open resetlogs upgrade; RMAN-00558: error encountered while parsing input commands RMAN-01009: syntax error: found "upgrade": expecting one of: ";" RMAN-01007: at line 1 column 31 file: standard input
4. Now follow the patchset upgrade steps.
Special Note for 11gR2
Starting with 11gR2, running pre-upgrade utility is mandatory and it will create or update registry$database. Failure to run the pre-upgrade tool (utlu112i.sql) will result in the following error while running the catupgrd.sql script :
SQL> SELECT TO_NUMBER('MUST_BE_SAME_TIMEZONE_FILE_VERSION')
2 FROM registry$database
3 WHERE tz_version != (SELECT version from v$timezone_file);
SELECT TO_NUMBER('MUST_BE_SAME_TIMEZONE_FILE_VERSION')
*
ERROR at line 1:
ORA-01722: invalid number
After opening the database for upgrade, you need to check whether registry$database table exists or not.
SQL> describe registry$database
If registry$database exists, it should have TZ_VERSION column and an appropriate timezone value should be updated in the table. (The value should be from V$TIMEZONE_FILE). If table does not exist, has to be created as:
CREATE TABLE registry$database (
platform_id NUMBER,
platform_name VARCHAR2(101),
edition VARCHAR2(30),
tz_version NUMBER )
The table then needs to be inserted with values –
INSERT into registry$database
(platform_id, platform_name, edition, tz_version)
VALUES ((select platform_id from v$database),
(select platform_name from v$database),
NULL,
(select version from v$timezone_file));