In this Document

Applies to:

Purpose

This article will illustrate how to duplicate ASM/OMF-based databases using RMAN.

Scope

The procedures for 10.1.0.4 and earlier, as well as 10.1.0.5 slightly vary, thus both are shown.

Details

For details on the 10.1.0.4 RMAN duplicate command see the Refer to Backup and Recovery Reference manual.

Procedure for 10.1.0.4.0 and earlier databases
================================

1) Copy primary database init.ora to auxiliary instance init.ora

2) Modify auxiliary instance init.ora accordingly:

a) If not using OMF for control files, set the CONTROL_FILES parameter to the appropriate location.
    Otherwise, do not set this parameter.
b) Do not set the DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT in the auxiliary init.ora
c) Set the DB_CREATE_FILE_DEST initialization parameter to the desired OMF storage location, e.g.
     *.DB_CREATE_FILE_DEST = '+DATA'
d) For a duplicate database that is not a standby database, change the value of the DB_NAME initialization
     parameter.
e) For a standby database, keep DB_NAME the same, but change the DB_UNIQUE_NAME initialization
    parameter. Additionally, set
    STANDBY_FILE_MANAGEMENT=AUTO

3) Start auxiliary instance in nomount mode. The auxiliary instance
    should have access to the backups and archivelogs created by target
    database in order for duplicate to succeed.

4) Duplicate the database using the following RMAN command set:

At this point all the datafiles/logfiles will be in the specified ASM diskgroups, using OMF names, and the controlfile(s) will
reflect the new path names. In the case of the "duplicate for standby", the standby controlfile will also reflect the standby
database path names (and not the production).



Procedure for 10.2 or 10.1.0.5.0 databases

There are two options.
Option 1-

Follow steps outlined for the 10.1.0.4 procedure. This is the simplest option, if all the auxiliary files are in identical
subdirectories as the primary, and do not need to be re-distributed across disk groups.

Option 2-
Set the traditional DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT parameters. This option allows
more flexibility in assigning where datafiles and log files should reside at the auxiliary database.

1) Copy primary database init.ora to auxiliary instance init.ora

2) Modify auxiliary instance init.ora accordingly:

a) If not using OMF for control files, set the CONTROL_FILES parameter to the appropriate location.  
    Otherwise, do not set this parameter.
b) Set db_file_name_convert and log_file_name_convert to convert the diskgroup, e.g.
    DB_FILE_NAME_CONVERT = ('+DATA', '+STDBY_DATA')
    LOG_FILE_NAME_CONVERT = ('+DATA', '+STDBY_DATA')
c) For a duplicate database that is not a standby database, change the value of the DB_NAME initialization
    parameter.
d) For a standby database, keep DB_NAME the same, but change the DB_UNIQUE_NAME initialization
    parameter. Additionally, set STANDBY_FILE_MANAGEMENT=AUTO

3) Start auxiliary instance in nomount mode. The auxiliary instance
    should have access to the backups and archivelogs created by target
     database in order to duplicate to succeed.

4) Duplicate the database using RMAN command

Keep in mind that, if the source filenames are in ASM OMF format, e.g., +DATA//datafile/xxxx.xx,
then RMAN, during restore, will generate new OMF names.

This is because ASM OMF filenames are unique and cannot be specified by the user or using DB_FILE_NAME_CONVERT;
i.e., it is generated by ASM code itself. Therefore, restored filenames will be different from the source filename, and only the
diskgroup name is honored in the filename conversion.

For example, suppose original filename is +DATA/proddb/datafile/users01.289.558716263 and
DB_FILE_NAME_CONVERT=('+DATA', '+STDBY_DATA')

After restore, the filename would not be
+STDBY_DATA/proddb/datafile/users01.289.558716263, but will be a newly created and OMF