Академический Документы
Профессиональный Документы
Культура Документы
In this Document
Purpose
Scope
Details
1. Manual Completion of Phase 1:Restore
2. Manual Completion of Phase 2:Controlfile Creation
3. Manual Completion of Phase 3:Recovery
4. Manual Completion of Phase 4: Controlfile Recovery
5. Manual Completion of Phase 5: Open Resetlogs
6. Final Actions
References
APPLIES TO:
Oracle Database - Enterprise Edition - Version 8.1.7.4 to 11.1.0.7 [Release 8.1.7 to 11.1]
Information in this document applies to any platform.
PURPOSE
Another document handling a look-a-like issue, for a FROM ACTIVE DATABASE duplication, is :
Note 1602916.1 Manual Completion of a Failed RMAN Duplicate FROM ACTIVE DATABASE
SCOPE
This article is meant for database administrators and backup and recovery
specialists tasked with the ongoing creation and administration of clone
databases.
All manual completion steps from failure in phase 1 have been tested at 10g R2 but they should still be applicable to 9i
and 8i .
DETAILS
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=1clr2mn0w6_212&id=360962.1 1/6
6/9/2014 Document 360962.1
If you are not going to back up your clone database using RMAN, then
incomplete duplication should not be a problem and the clone database can be used
after fixing the cause of failure and completing recovery and opening with resetlogs.
a. If you connect to the clone as the target, then connect to the recovery catalog,
you will get the error:
A ‘reset database’ command from within RMAN will allow you to backup the clone
database, but it is doing so under the impression that you are backing up a NEW
incarnation of your production database.
b. If you subsequently connect your production database to the recovery catalog, you will get the same error:
If you reset the incarnation to the previous incarnation (reset database to incarnation <primary_key>) you can continue
to make production database backups.
However you now have TWO databases sharing the same id but RMAN cannot differentiate between them: you may
have to unregister the database from the catalog and then register it again (see Note 1058332.6 How to Unregister
Oracle Release 8 and 9 Target Databases when Using RMAN).
If you are unable (or unwilling) to rerun the duplicate there is another option. You can regenerate the dbid of the clone
database after which you can register the cloned database in the recovery catalog as a NEW database.
09.02.00 or later
Change the dbid of the clone database using the Nid utility available from 9.2.
Refer to Note 224266.1 How to Change the DBID and the DBNAME by using NID.
08.01.0X.XX only
If a 9i installation is available, connect to the 8i target from the 9i ORACLE_HOME environment using the 9i NID
executable to change the dbid; refer to the note above for details on how to use NID. This is the only fully supported
method of changing the dbid of an 8i database without doing a DUPLICATE.
If there is no access at all to a 9i installation, raise a call with Oracle Support Services for advice on how this can be
done.
If a duplicate fails you may wish to manually complete the process, particularly if the failure occurred after or towards
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=1clr2mn0w6_212&id=360962.1 2/6
6/9/2014 Document 360962.1
the end of a lengthy restore; you need first to examine the duplicate log and determine the phase at which the failure
occurred.
Duplicate Phases
Restore the remaining datafiles into the auxiliary instance using a 'normal' rman restore and connecting to the auxiliary
instance as the target. Start RMAN in the same host / environment as the AUXILIARY instance :
$ export ORACLE_SID=<auxiliary>
$ rman target /
RMAN> run {
set until scn 1412841;
restore controlfile from '/u01/control_12355545_c_.bak';
alter database mount;
set newname for datafile n to '<newfilename_n>';
set newname for datafile n2 to '<newfilename_n2>';
….etc
restore datafile n,n2…etc;
}
Notes
take the 'UNTIL SCN' from the printed script in the failed RMAN duplicate log
you must use 'SET NEWNAME' for each datafile to be restored as DB_FILE_NAME_CONVERT will not work with a
normal restore
be aware of Bug 3202107: Restore Optimization is not active after failed and retried duplicate command
Note : From 10g onwards, if duplicate failed during step 1, which is the restore of datafiles, it is probably best to
restart the duplicate process. Any files that have already been restored will be skipped and the duplicate process can
continue without manual intervention. For ASM and OMF files this will be different as each restore using a SET
NEWNAME will generate a new name so RMAN cannot find the already restored file - in this case comment out
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=1clr2mn0w6_212&id=360962.1 3/6
6/9/2014 Document 360962.1
db_create_file_dest in the auxiliary pfile before rerunning duplicate : see also Note 882555.1 :RMAN is Not Restoring
OMF Datafiles in Their Original Location
Failure during controlfile creation or switch of datafile names – determine and fix the cause of failure if you can then
create the controlfile manually in the auxiliary instance:
Make sure you specify ALL the restored datafiles in the DATAFILE section.
You can generate a controlfile script from the target and amend it accordingly - be sure to rename EACH datafile if the
auxiliary instance uses a different file structure:
RMAN> run {
set newname for datafile n to 'X'; ** see Notes below re incrementals
set until scn 1412841;
recover clone database;
alter clone database open resetlogs;
}
Notes :
When a RMAN fails it sometimes does not create the tempfile. So we need to ensure that tempfile exists before
running NID otherwise we'll get the problem described in this note:
After completing recovery, change the dbid using the NID utility:
$ nid target=sys/oracle
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=1clr2mn0w6_212&id=360962.1 4/6
6/9/2014 Document 360962.1
DBNEWID: Release 10.2.0.1.0 - Production on Fri Mar 10 22:54:42 2006
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to database TEST (DBID=124048422)
Connected to server version 10.2.0
Control Files in database:
D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\CONTROL01.CTL
D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\CONTROL02.CTL
D:\ORACLE\PRODUCT\10.2.0\ORADATA\TEST\CONTROL03.CTL
Change database ID of database TEST? (Y/[N]) => Y
Determine and fix the cause of the failure to create the clone controlfile before recreating the controlfile manually:
Make sure you specify ALL the restored datafiles in the DATAFILE section.
If the resetlogs was done – just determine and fix the cause of failure and restart the auxiliary instance.
If resetlogs was not accomplished, determine and fix the cause of failure and then
open the clone database with resetlogs via RMAN (you cannot do this via SQLPlus and you must be connected to the
target database also):
If the duplicate originally failed only in Phase 5 no further action is necessary - the dbid will have already been
changed. Otherwise, use NID to change the dbid as in step 3 above.
6. Final Actions
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=1clr2mn0w6_212&id=360962.1 5/6
6/9/2014 Document 360962.1
b. Any files that were manually restored to the auxiliary instance will be cataloged as datafilecopies in the target
database. Connect to original target and run:
REFERENCES
NOTE:224266.1 - How to Change the DBID and the DBNAME by using NID
NOTE:1058332.6 - How to Unregister Oracle Release 8 and 9 Target Databases when Using RMAN
BUG:3202107 - RESTORE OPTIMIZATION IS NOT ACTIVE AFTER FAILED AND RETRIED DUPLICATE COMMAND
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=1clr2mn0w6_212&id=360962.1 6/6