Wednesday 7 October 2015

RMAN RESTORE / DUPLICATE FAILS AT OPEN (CLONE) ORA-01139 / ORA-16433, IF WRONG UNDO TABLESPACE IS SPECIFIED FOR THE RESTORE DB / or AUXILIARY (Doc ID 1536368.1)

Symptoms

RMAN Duplicate fails to open CLONE with ORA-01139 / ORA-16433 when the wrong undo tablespace is specified in auxiliary pfile:

contents of Memory Script:
{
  Alter clone database open resetlogs;
}
executing Memory Script
}
executing Memory Script

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00601: fatal error in recovery manager
RMAN-03004: fatal error during execution of command
RMAN-10041: Could not re-create polling channel context following failure.
RMAN-10024: error setting up for rpc polling
RMAN-10005: error opening cursor
RMAN-10002: ORACLE error: ORA-03114: not connected to ORACLE
RMAN-03002: failure of Duplicate Db command at 10/10/2012 14:27:10
RMAN-05501: aborting duplication of target database
RMAN-03015: error occurred in stored script Memory Script
RMAN-06136: ORACLE error from auxiliary database: ORA-01092: ORACLE instance ter
minated. Disconnection forced
ORA-30012: undo tablespace 'UNDOTBS1X' does not exist or of wrong type
 All attempts to clear the issue with manual recovery fail:
Using SQLPlus
SQL> recover database using backup controlfile until cancel;
ORA-00283: recovery session canceled due to errors
ORA-16433: The database must be opened in read/write mode.

SQL> alter database backup controlfile to trace;
alter database backup controlfile to trace
*
ERROR at line 1:
ORA-16433: The database must be opened in read/write mode.
Using RMAN

RMAN> recover clone database;
RMAN-11003: failure during parse/execution of SQL statement: alter database
recover if needed
 start until cancel using backup controlfile
ORA-00283: recovery session canceled due to errors
ORA-16433: The database must be opened in read/write mode.
 



Cause

Auxiliary pfile specifies an invalid undo_tablespace name that is not present in the database that is being duplicated.
This causes the auxiliary to fail immediately after opening with  resetlogs.
<Bug 14744052>   AFTER FAILURE OF DUPICATE COMMAND DURING OPEN RESETLOGS, CLONE RAISES ORA-16433
Closed:  Not a Bug
A flag is set in the auxiliary pfile during resetlogs which is then unset by the dictionary check when resetlogs completes successfaully.  As resetlogs did not complete the flag is  still set causing the ORA-16433 to be raised whenever the controlfile is subsquently accessed.  There is no way to clear this flag.

Solution

Recreate the controlfile using an edited version of the create controlfile script generated from the target:  How to Recreate a Controlfile (Doc ID 735106.1)

The auxiliary alert log shows that a resetlogs was done and will identify the online log for sequence# 1:

Thread 1 opened at log sequence 1
Current log# 1 seq# 1 mem# 0: C:\APP\DUP\REDO01.LOG

To  complete the process :

- correct undo_tablespace parameter in auxiliary pfile
- remount auxiliary with the newly created controlfile
- recover and open with resetlogs

SQL> recover database using backup controlfile;
ORA-00279: change 2023230 generated at 10/10/2012 14:27:01 needed for thread 1
ORA-00289: suggestion :
C:\APP\FAST_RECOVERY_AREA\DUP\ARCHIVELOG\2012_10_10\O1_MF_1_1_%U_.ARC
ORA-00280: change 2023230 for thread 1 is in sequence #1

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
C:\APP\DUP\REDO01.LOG
Log applied.
Media recovery complete.
SQL> alter database open resetlogs;

Database altered.

Note: To avoid this error in the future, ensure that you specify the same UNDO_TABLESPACE parameter for the auxiliary as is currently set for the target database.  If duplicating a RAC target database, you can specify any of the target instance's undo_tablespace for the auxiliary.

Note:
-----
o The same error ORA-01139 / ORA-16433 is as well reported, if wrong UNDO tablespace is specified
  and then trying to open database resetlogs after an RMAN RESTORE and RECOVER.
 
Thanks
Srini

No comments:

Post a Comment


No one has ever become poor by giving