11
Duplicating a Da tabase with Recovery Manager

This chapter describes how to us e the DUPLICATE command to create a duplicate database for testing purposes. This chapter contains these topics:

• Creating a Duplicate Database: Overvie w
• Generating Files for the Duplicate Databa se
• Preparing the Auxiliary Instance for Dup lication: Basic Steps
• Creating a Duplicate Database on a Local or Remote Host
• Database Duplication Examples

  See Also: Oracle Data Guard Concepts and Administration to learn how to create a standby databas e with the DUPLICATE command

Creating a Duplicate Dat abase: Overview

You can use the RMAN DUPLICATE comm and to create a duplicate database from target database backups while still retaining the origi nal target database. The duplicate database can be identical to the original database or contain only a subset of the original tables paces.

A duplicate database is a copy of a target database that you can run independently f or a variety of purposes. For example, you can use it to:

• Test backup and recovery procedures
• Export data such as a table that was inadverte ntly dropped from the production database, and then import it back into the production database

For example, you can duplicate the production database on host1 to host2, and then use the dupli cate database on host2 to practice restore and recovery scenarios while the production database on host1 co ntinues as usual.

A duplicate database is distinct from a standby database, although both t ypes of databases are created with the DUPLICATE command. A standby database is a copy of the primary database that you can update continually or periodically with archived logs from the primary database. If the primary database is damaged or destroyed, then you can perform failover to the standby database and effectively transform it into the new primary database. A duplicate databa se, on the other hand, cannot be used in this way: it is not intended for failover scenarios and does not sup port the various standby recovery and failover options.

How Recovery Manager Duplicates a Database

To prepare for database duplication, you must first create an auxiliary ins tance as described in "Preparing the Auxiliary Instance for Duplication: Basic Steps". For the duplication to work, you must connect RMAN to both the target (primary) database and an auxi liary instance started in NOMOUNT mode.

You must have at least one auxiliary c hannel allocated on the auxiliary instance. The principal work of the duplication is performed by the auxiliary channel, which starts a server session on the duplicate host. This channel then restores the necessary backups of the primary database, uses them to creat e the duplicate database, and initiates recovery.

So long as RMAN is able to connect to the primary and auxiliary instances, the RMAN client can run on any machine. However, all backups and archived logs used for creating an d recovering the duplicate database must be accessible by the server session on the duplicate host. If the duplicate host is not the same as the primary host, then you must make backups on disk on the primary host available to the duplicate host with the same full p ath name as in the primary database. When using disk backups, you can accomplish this goal in any of the following ways:

• Manually transfer the backups from the primary host to the remote host to an identical path.
• Manually transfer the backups from the primary host to the remote host to a new path, and then run the CATALOG command to add these copies to the RMAN repository.
• Use NFS or shared disks and make sure that the same path is accessible in the remote host.

When using tape backups, you must make the tapes containing the backups accessible to th e remote node, either by physically moving the tape to the remote host or by means of a network tape server.

• Creates a control file for the duplicate database
• Restores the target datafiles to the duplicate database and performs incomplete recovery by using all available incremental backups and archived logs
• Shuts down and starts the auxiliary instance (refer to "Task 4: Start the Auxiliary Instance" for issues relating to clien t-side versus server-side initialization parameter files)
• Opens the duplicate database with the RESETLOGS option after incomplete recovery to create the online redo logs (except when running D UPLICATE ... FOR STANDBY, in which case RMAN does not open the database)
• Generates a new, unique DBID for the duplicate database (except when you create a standby da tabase with DUPLICATE ... FOR STANDBY, in which case RMAN does not create a unique DBID)

During duplication, RMAN must perform incomplete recovery because the online redo logs in the target are not backed up and cannot be applied to the duplicate data base. The farthest that RMAN can go in recovery of the duplicate database is the most recent redo log archived by the target database .

Database Duplication Options

RUN
{

 SET NEWNAME FOR DATAFILE 1 TO /oracle/data/file2.f; # rename df 1 as file2.f
  SET NEWNAME FOR DATAFILE 2 TO /
oracle/data/file1.f; # rename df 2 as file1.f
  DUPLICATE TARGET DATABASE TO newdb;
} 

Task 1: Create an Oracle Password File for the Auxilia ry Instance
• Task 2: Ensure Oracle Net Conne ctivity to the Auxiliary Instance
• Task 3: C reate an Initialization Parameter File for the Auxiliary Instance
• Task 4: Start the Auxiliary Instance
• Task 5: Mount or Open the Target Database
• Task 6: Make Sure You Have the Necessary Backups and Archived Redo Logs
• Task 7: Allocate Auxiliary Channels if Automatic Channels Are Not Configured

Task 1: Cr eate an Oracle Password File for the Auxiliary Instance

For instruct ions on how to create and maintain Oracle password files, refer to Oracle Database Administrator's Guide.

< font face="Arial, Helvetica, sans-serif" color="#330099">Task 2: Ensure Oracle Net Connectivity to the Auxiliary Instance

The auxiliary instance must be accessible through Oracle Net. Before proceeding , start SQL*Plus to ensure that you can establish a connection to the auxiliary instance. Note that you must connect to the auxiliary instance with SYSDBA privileges, so a password file must exist.

Task 3: Create an Initialization Parameter File for the Auxiliar y Instance

Create a client-side initialization parameter file for th e auxiliary instance, and set at least the parameters described in the following table.

Par ameter	You must specify:
DB_NAME	The same name used in the DUPLICATE command. You must set the DB_NAME parameter in the duplicate parameter file to the same database name specified in the DUPLICATE command. You cannot use the same database name for the target and duplicate when the duplicate is in the same Oracle home as the target. If the duplicate is in a different Ora cle home from the target, then its DB_NAME just has to differ from other database names in the same Oracle home.
CONTROL_FILES	Refer to "Creating the Dup licate Control Files".

You can also set the initialization parameters described in the following table.

Initializatio n Parameter	You must specify:
DB_FILE_NAME_CONVERT	Refer to "Renaming Datafiles When Duplicating a Database". You can also specify this parameter on the DUPLICATE command itself.
LOG_FILE_NAME_CONVERT	Refer to "Creating the Dupli cate Online Redo Logs".

Se t other initialization parameters, including the parameters that allow you to connect as SYSDBA through Oracle Net, as n eeded. When duplicating to the same host or to a new host with a different file system, pay attention to all initialization parameter s specifying path names. Verify that all paths are accessible on the host where the database is being duplicated.

Following are examples of the initialization parameter settings for the duplicate database:

DB_NAME=newdb
CONTROL_FILES=(/dup/oracle/oradata/trgt/control01.ctl,

               /dup/oracle/oradata/trgt/control02.ctl)
# note that the following two initialization paramet
ers have equivalents
# on the DUPLICATE command itself
DB_FILE_NAME_CONVERT=(/oracle/orad
ata/trgt/,/dup/oracle/oradata/trgt/)
LOG_FILE_NAME_CONVERT=(/oracle/oradata/trgt/redo,/dup/oracle/oradata/trgt/
redo)

After you create the client-side initialization parameter f ile, you can run the CREATE SPFILE command from SQL*Plus to create a server-side initialization parameter f ile. You can run this command before or after instance startup. For example, you can create a server-side parameter file in the defau lt location as follows, specifying the filename of the client-side initialization parameter file in the FROM clause:

CREATE SPFILE FROM PFILE='/tmp/initDUPDB.ora';

A server-side parameter file in the default location is an advantage when duplicating a database because you do not need to specify the PFILE parameter on the DUPLICATE command. Because RMAN shuts down and restarts the auxiliary instance as part of the duplication process, you must tell RMAN which client-side file to use if you use a client-side para meter file. It is highly recommended that you create a server-side parameter file for use in database duplication.

Task 4: Start the Auxiliary Instance

Before beginning RMAN duplication, use SQL*Plus to connect to the auxiliary instance and start it in NOMOUNT mode (specifying a client-side parameter file if necessary). In this example, oracle is the password for the user with SYSDBA authority and aux is the net service name for the auxiliary instance:

CONNECT SYS/oracle@aux AS SYSDBA
--
start instance with the server parameter file
STARTUP FORCE NOMOUNT

Because the auxiliary instance does not yet have a control file, you can only start the instance in NO MOUNT mode. Do not create a control file or try to mount or open the auxiliary instance.

RMAN shuts down and restarts the auxiliary instance as part of the duplication. Hence, it is a good idea to create a server-side initialization parameter file for the auxiliary instance in the default location.

If you d o not have a server-side initialization parameter file for the auxiliary instance in the default location, th en you must specify the client-side initialization parameter file with the PFILE parameter on the DUPLICATE command. The client-side parameter file for the auxiliary instance must reside on the same host as the RMAN client used to perform t he duplication.

Task 5: Mount or Open the Target Database

Before beginning RM AN duplication, connect SQL*Plus to the target database and mount or open it if it is not already mounted or open. For example, enter :

-- connect to target database
CONNECT SYS/oracle@trgt
-- mount or open target database
STARTUP

If necessary, you can use a client-side initialization file to start up the target instance.

Task 6: Make Sure You Have the Necessary B ackups and Archived Redo Logs

Make sure backups all target datafiles are accessible on the duplicate host. If you do not have backups of everything, then the duplicate operation fails. The database bac kup does not have to be a whole database backup: you can use a mix of full and incremental backups of individual datafiles.

Archived redo logs required to recover the duplicate database to the desired point in time must be a ccessible by the node where the duplicate database is to be created, either as backups (for instance, on a media manager) or as image copies (or the actual archived redo logs), either copied to the local disk of the node that contains the duplicate database, or poss ibly mounted across a network by some means such as NFS.

Task 7: Allocate Auxiliary Channels if Automatic Channels Are Not Configured

Start RMAN with a connection to the target database, the auxiliary instance, and, if applicable, the recovery catalog database. You can start the RMAN client on any host so long as it can connect to all the in stances. If the auxiliary instance requires a client-side initialization parameter file, then this file must exist on the same host t hat runs the RMAN client.

In this example, a connection is established to three instances, all through the use of net service names:

% rman TARGET SYS/oracle@trgt CATALOG rman/cat@ca
tdb AUXILIARY SYS/oracle@aux

If you do not have automatic channel s configured, then before issuing the DUPLICATE command, manually allocate at least one auxiliary channel within the sam e RUN command. The channel type (DISK or sbt) must match the media where the backups of the ta rget database are located. If the backups reside on disk, then the more channels you allocate, the faster the duplication will be. Fo r tape backups, limit the number of channels to the number of devices available.

RUN 
{
  # to manually allocate a channel of type sbt issue:
  ALLOCATE AUXIL
IARY CHANNEL ch1 DEVICE TYPE sbt;

  # to manually allocate three auxiliary channels for
disk issue (specifying 
  # whatever channel id that you want):
  ALLOCATE AUXILIARY CHAN
NEL aux1 DEVICE TYPE DISK;
  ALLOCATE AUXILIARY CHANNEL aux2 DEVICE TYPE DISK;
  ALLOCATE
 AUXILIARY CHANNEL aux3 DEVICE TYPE DISK;
  .
  .
  .
  DUPLICATE ...
}

Note: If you configure automatic channels, then RMAN can use configur ed channels for duplication even if they do not specify the AUXILIARY option. Nevertheless, if the auxiliary channels ne ed some special parameters (for example, to point to a different media management subsystem), then you can configure an automatic cha nnel with the AUXILIARY option.

Creating a Duplicate Database on a Local or Remot e Host

The proceture to create a duplicate database depends on y our configuration.

Duplicating a Database on a Remote Host with the Same Directory Structure

The simplest case is to duplicate the database to a different host and to use the same directory structure. In this c ase, you do not need to change the initialization parameter file or set new filenames for the duplicate datafiles.

1. Follow the steps in "Preparing th e Auxiliary Instance for Duplication: Basic Steps".
2. Run the DUPLICATE command, making sure to do the following:
   • If automatic channels are not configured, then allocate at least one auxiliary channel.
   • Specify the NOFILENAMECHECK parameter on the DUPLICATE command.
   • Specify the PFILE parameter if starting the auxiliary instance with a client-side parameter file. The client-side parameter file must exist on the same host as the RMAN client used to perform the duplica tion.

   The following example assumes that the RMAN client is running on the duplicate host. It duplicates the database with an automatic channel, specifies a client-side initialization parameter file, and specifies the NOFILENAMECHECK option:

   DUPLICATE TARGET DATABASE TO dupdb
     # specify client-side parameter file (on same host as RMAN client) for
     # auxiliary instance if necessa
   ry
     PFILE = /dup/oracle/dbs/initDUPDB.ora
     NOFILENAMECHECK;
   
   
   

RMAN automatically allocates the configured channels, then uses all incremental ba ckups, archived redo log backups, and archived redo logs to perform incomplete recovery. Finally, RMAN opens the database with the RESETLOGS option to create the online redo logs.

Duplicating a Database on a Remote Host with a Different Directory Structure

If you create the duplicate database on a host with a different directory structure, then you must change several initialization parameters, in order to generate new filenames for the duplicate database dat afiles on the new directory structure. The different methods available for doing so are described in " Renaming Datafiles When Duplicating a Database".

Converting Filenames with Only Initialization Paramete rs

This procedure assumes that you use only initialization parameter s to rename the duplicate datafiles and log files.

1. Follow the steps in "Preparing the Auxiliary Instance for Duplication: Basic Steps". You can either create a client-side parameter file, or copy the parameter file from its location in the ta rget host directory structure to the same location in the duplicate host directory structure using operating system utilities. Verify that you have done all of the following:
   • Set all initialization parameters that end in _DEST or _PATH and specify a path name.
   • Set DB_FILE_NAME_CONVERT so that it captures all the target datafiles and converts th em appropriately, for example, from /oracle/oradata/ to /dup/oracle/oradata/.
   • Set LOG_FILE_NAME_CONVERT so that it captures all the online redo logs and converts them appropriately, for example, /oracle/oradata/redo to /dup/oracle/oradata/redo.

     Note: You can set multiple conversion pairs in DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT. For exa mple, you can specify that DB_FILE_NAME_CONVERT changes /disk1/dbs to /dup1/dbs and /dis k2/dbs to /dub2/dbs. Also, while this example focuses on using DB_FILE_NAME_CONVERT, remember that y ou can use the CONFIGURE AUXNAME or SET NEWNAME commands to rename individual datafiles if you cannot easil y generate all of your desired filenames using DB_FILE_NAME_CONVERT commands.

2. Perform the following operations when running the duplication:
   • If automatic channels are not configured, then allocate at least one aux iliary channel.
   • If using a client-side parameter file to start the auxiliary i nstance, specify the PFILE parameter.

   The following example assumes tha t the duplicate host can access the same media manager as the primary database host. The example duplicates the database with an auto matic sbt channel and uses a server-side parameter file located on the duplicate host to restart the auxiliary instance:

   DUPLICATE
     TARGET DATABASE TO dupdb
     DEVICE
    TYPE sbt # restores from tape backups;
   # DUPLICATE DEVICE TYPE sbt works only if the sbt device is configured
   # by CONFIGURE CHANNEL, CONFIGURE DEVICE TYPE, or CONFIGURE DEFAULT DEVICE.
   
   

   RMAN uses all incremental backups, archived redo log backups, and archived redo logs to perform inc omplete recovery. RMAN then shuts down, starts, and opens the database with the RESETLOGS option to create the online re do logs.

Converting Filenames with Only DUPLICATE Parameters

This p rocedure assumes that you use the DB_FILE_NAME_CONVERT parameter of the DUPLICATE command to rename the dup licate datafiles, and the LOGFILE clause to specify names and sizes for the online redo logs.

Perform the following operations when running the duplication:

If automatic auxiliary channels are not configured, then allocate at least one auxili ary channel.
• Specify the names and sizes for the duplicate database redo logs in the LOGFILE clause.
• Specify new filenames for the duplicate da tabase datafiles with the DB_FILE_NAME_CONVERT parameter.
• If usin g a client-side parameter file to start the auxiliary instance, specify the PFILE parameter.

The following example duplicates the database with an automatic channel and specifies an initialization pa rameter file:

DUPLICATE TARGET DATABASE TO dupdb
  # specify client-s
ide parameter file for auxiliary instance if necessary
  PFILE = /dup/oracle/dbs/initDUPDB.ora
  DB_FILE_NAME_CONVERT=(/oracle/oradata/trgt/,/dup/oracle/oradata/trgt/)
  LOGFILE

    '/dup/oracle/oradata/trgt/redo01.log' SIZE 200K,
    '/dup/oracle/oradata/trgt/redo02.log' SIZE 200K,
    '/dup/oracle/oradata/trgt/redo03.log' SIZE 200K;

Converting Filenames with SET NEWNAME

This procedure assumes that you use the SET NEWNAME command to rename the duplicate datafiles.

1. Follow the steps in "Preparing the Auxiliary Instance for Duplication: Basic Steps", ma king sure to use an operating system utility to copy the parameter file from its location in the target host directory structure to t he same location in the duplicate host. Set all initialization parameters that end in _DEST or _PATH and sp ecify a path name.
2. Perform the following operations when running the du plication:
   • If automatic auxiliary channels are not configured, th en allocate at least one auxiliary channel.
   • If desired, specify the same numbe r of redo log members and groups that are used in the target database.
   • Specify new filenames for the duplicate database datafiles.
   • If you use a client-side parameter file to start the auxiliary instance, then specify the PFILE parameter.

   The following example uses automatic channels and a default server-side initialization parameter file for the database dup lication, and uses the LOGFILE clause to specify names and sizes for the online redo logs:

   RUN
   {
     # set new filenames for the datafiles
     SET N
   EWNAME FOR DATAFILE 1 TO '/dup/oracle/oradata/trgt/system01.dbf'; 
     SET NEWNAME FOR DATAFILE 2 TO '/dup/oracle
   /oradata/trgt/undotbs01.dbf'; 
     . . .
     # issue the duplicate command
   
     DUPLICATE TARGET DATABASE TO dupdb
     # create at least two online redo log groups
   
    LOGFILE
       GROUP1
       (
         '/dup/oracle/oradata/trgt/redo01a.l
   og',
         '/dup/oracle/oradata/trgt/redo01b.log',
         '/dup/oracle/oradata/trgt/redo01
   c.log';
       ) SIZE 200K,
       GROUP2
       (
   
      '/dup/oracle/oradata/trgt/redo02a.log',
         '/dup/oracle/oradata/trgt/redo02b.log',
   
         '/dup/oracle/oradata/trgt/redo02c.log';
       ) SIZE 200K,
       GROUP3
       (
         '/dup/oracle/oradata/trgt/redo03a.log',
         '/dup/oracle/oradata/trg
   t/redo03b.log',
         '/dup/oracle/oradata/trgt/redo03c.log';
       ) SIZE 200K;
   
   

RMAN uses all incremental backups, archived redo log backups, and archived redo logs to perform incomplete recovery. RMAN shuts down, starts up, and then opens the database with the RESETLOGS< /code> option to create the online logs.

Converting Filenames with CONFIGURE AUXNAME

This procedure assumes that you use the CONFIGURE AUXNAME command to rename the duplicate datafiles .

1. Follow the steps in "Preparing the Auxiliary Instance for Duplication: Basic Steps", making sure to use an operating system utility to copy the parameter file from its location in the target host directory structure to the same location in the duplicate host directory structure. Set all initialization parameters that end in _DEST or _PATH and sp ecify a path name.
2. Add the following features when creating the RMAN co mmands to perform the duplication:
   • Prepare CONFIGURE AUXNAM E commands for all datafiles, to be executed before database duplication.
   • < /a>If automatic auxiliary channels are not allocated, then allocate at least one auxiliary channel.
   • Use a LOGFILE clause to specify redo log groups and members for the duplicate database. (You do no t have to use the same number of redo log groups or redo log group members in the duplicate database as you did in the target databas e.)
   • If you start the auxiliary instance with a client-side parameter file, the n specify the PFILE parameter. The client-side parameter file must reside on the same host as the RMAN client used to pe rform the duplication.

The following example uses CONFIGURE AUXNAME to set new datafile names, uses automatic channels and a client-side initialization parameter file for the database duplication , and uses the LOGFILE clause to specify names and sizes for the online redo logs.

# configure the new desired filenames
 CONFIGURE AUXNAME FOR DATAFILE 1 
        TO
'/dup/oracle/oradata/trgt/system01.dbf'; 
 CONFIGURE AUXNAME FOR DATAFILE 2 
        TO '
/dup/oracle/oradata/trgt/undotbs01.dbf'; 
# ... add more CONFIGURE AUXNAME commands as needed 

# run the DUPLICATE command
DUPLICATE TARGET DATABASE TO dupdb
<
/a># specify client-side parameter file for auxiliary instance if necessary
PFILE = /dup/oracle/dbs/initDUPDB.o
ra
.
.
.
# create at least two online redo lo
g groups
 LOGFILE
    GROUP1
    (
      '/du
p/oracle/oradata/trgt/redo01a.log',
      '/dup/oracle/oradata/trgt/redo01b.log',
      '
/dup/oracle/oradata/trgt/redo01c.log';
    ) SIZE 200K,
    GROUP2

    (
      '/dup/oracle/oradata/trgt/redo02a.log',
      '/dup/oracle/oradata/trgt/redo0
2b.log',
      '/dup/oracle/oradata/trgt/redo02c.log';
    ) SIZE 200K,
    GROUP3
    (
      '/dup/oracle/oradata/trgt/redo03a.log',
      '/dup/oracle/oradata/trgt/redo03b.log',
      '/dup/oracle/oradata/trgt/redo03c.log';

    ) SIZE 200K;

RMAN uses all incremental backups, archived redo log backups, and archived redo logs to perform incomplete recovery and then opens the database with the RESETLOGS o ption to create the online redo logs.

After the duplication is complete, clear the configur ed auxiliary names for the datafiles in the duplicate database, so that they are not overwritten by mistake. For example, enter the f ollowing:

# un-specify auxiliary names for the datafiles
CONFIGURE AU
XNAME FOR DATAFILE 1 CLEAR; 
CONFIGURE AUXNAME FOR DATAFILE 2 CLEAR; 
.
.
.

and so on.

Creating a Duplicate Database on the Local Host< /h3>

When creating a duplicate database on the same host as the target database, follow the same procedure as for duplicating to a remote host with a different directory structure as described in "Duplicating a Database on a Remote Host with a Different Directory Structure".< /p>

You can duplicate the database to the same Oracle home as the target database, but you must use a different database name from the target database, and convert the filenames by means of the same methods used for conversion o n a separate host.

Caut ion: Do not use the NOFILENAMECHECK option when duplicating to the same Oracle home as the primary database. If you do, then the DUPLICATE command may overwrite the datafiles of the targ et database.

Duplicating a Database to an Automatic Storage Management Environment

The process for creating a duplicate database to an Automatic Storage Management or Oracle Managed Files location is similar to the procedure described in "Duplicating a Database on a Remote Host with a Different Directory Structure". However, you must edit the initialization parameter file in the auxiliary instance to set the DB_CREATE_FILE_DEST parameter to refer to an ASM disk group, and eliminate parameters such as DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT which are used to control the naming of any files i n the duplicate database which will be created in ASM during the duplication process.

For e xample, edit the file as follows to create the database files in the disk group named disk1:

*.DB_CREATE_FILE_DEST = '+disk1'

Database Duplication Examples

Here are some common variations on the process of duplicating a database.

Duplicating When the Datafiles Use Incons istent Paths: Example

This example assumes the following:

• You are using recovery catalog database catdb.
• The target database trgt is on host1 and contains eight datafile s, which are spread out over multiple directories.
• You want to duplicate the t arget to database dupdb on remote host host2.
• host1 and host2 use different file systems.
• You want to st ore the datafiles in host2 in the /oradata1, /oradata2 ... through /oradata7 subd irectories.
• You want to exclude tablespace tools from the duplica te database, but keep all of the other tablespaces.
• You have used an operating system utility to copy the initialization parameter file from host1 to an appropriate location in host2.
• You have reset all initialization parameters that end in _DEST or _PATH and specify a path name.
• You want two online redo logs grou ps, each with two members of size 200 KB, which on the duplicate system will be stored in the directory "/duplogs".
• You have disk copies or backup sets stored on disk for all the datafiles and archi ved redo logs in the target database, and you have manually moved them to host2 by means of an operating system utility.
• You have configured the default device to sbt. The media managem ent device is accessible by host2.
• The auxiliary instance uses a server-side initialization parameter file in the default location (so the PFILE parameter is not necessary on the DUPLICATE command).

  CONNECT TARGET /;
  CONNECT CATALOG rman/cat@ca
  tdb;
  CONNECT AUXILIARY SYS/oracle@dupdb;
  
  # note that a RUN command
   is necessary because you can only execute SET NEWNAME
  # within a RUN command
  RUN
  {
    # The DUPLICATE command uses an automatic sbt channel.
    # Because the
   target datafiles are spread across multiple directories, 
    # run SET NEWNAME rather than DB_FILE_NAME_CONVERT
  
    SET NEWNAME FOR DATAFILE 1 TO '/oradata1/system01.dbf'; 
    SET NEWNAME FOR DATAFILE 2
  TO '/oradata2/undotbs01.dbf'; 
    SET NEWNAME FOR DATAFILE 3 TO '/oradata3/cwmlite01.dbf'; 
    SET NEWNAME FOR DATAFILE 4 TO '/oradata4/drsys01'; 
    SET NEWNAME FOR DATAFILE 5 TO '/oradata5/example01.db
  f'; 
    SET NEWNAME FOR DATAFILE 6 TO '/oradata6/indx01.dbf';
    # Do not set a newname for
   datafile 7, because it is in the tools tablespace,
    # and you are excluding tools from the duplicate database
  .
    SET NEWNAME FOR DATAFILE 8 TO '/oradata7/users01.dbf'; 
    DUPLICATE TARGET DATABASE T
  O dupdb
      SKIP TABLESPACE tools
      LOGFILE
        GROUP 1 ('/dupl
  ogs/redo01a.log', 
                 '/duplogs/redo01b.log') SIZE 200K REUSE, 
        GROUP 2
   ('/duplogs/redo02a.log', 
                 '/duplogs/redo02b.log') SIZE 200K REUSE;
  }
  
  

Resynchronizing the Duplicate Database with the Target Database: Example

This example makes the same assumptions as in "Duplicating When the Datafiles Use Inconsistent Pa ths: Example".

In this case, the assumption is that you want to update the duplicate database daily so that it stays current with the target database. Therefore the CONFIGURE command is used to set persistent new names for the datafiles, to use in the daily duplication process.

This script performs the onetime setup of the names for the data files, and should be run once.

# start RMAN and then connect to the databases     
CONNECT TARGET /;
CONNECT CAT
ALOG rman/cat@catdb;
CONNECT AUXILIARY SYS/oracle@dupdb;

# configu
re auxiliary names for the datafiles only once     
CONFIGURE AUXNAME FOR DATAFILE 1 TO '/oradata1/system01.dbf
'; 
CONFIGURE AUXNAME FOR DATAFILE 2 TO '/oradata2/undotbs01.dbf'; 
CONFIGURE AUXNAME FOR
 DATAFILE 3 TO '/oradata3/cwmlite01.dbf'; 
CONFIGURE AUXNAME FOR DATAFILE 4 TO '/oradata4/drsys01'; 
CONFIGURE AUXNAME FOR DATAFILE 5 TO '/oradata5/example01.dbf'; 
CONFIGURE AUXNAME FOR DATAFILE 6 TO
 '/oradata6/indx01.dbf';
# Do not set a newname for datafile 7, because it is in the tools tablespace,
# and you are excluding tools from the duplicate database.
CONFIGURE AUXNAME FOR DATAFILE 8 TO '/
oradata7/users01.dbf'; 

This script is run daily to peform the du plication:

# start RMAN and then connect to the databases     
CONNEC
T TARGET /;
CONNECT CATALOG rman/cat@catdb;
CONNECT AUXILIARY SYS/oracle@dupdb;

# Create the duplicate database. Issue the same command daily
# to re-creat
e the database, thereby keeping the duplicate 
# in sync with the target.
DUPLICATE TARGE
T DATABASE TO dupdb
SKIP TABLESPACE tools
  LOGFILE
    GROUP 1 ('/
duplogs/redo01a.log', 
             '/duplogs/redo01b.log') SIZE 200K REUSE, 
    GROUP 2
 ('/duplogs/redo02a.log', 
             '/duplogs/redo02b.log') SIZE 200K REUSE;

Creating Duplicate of the Database a t a Past Point in Time: Example

This duplication example assumes the following:

• The target database trgt and duplicat e database dupdb are on different hosts but have exactly the same directory structure.
• You want to name the duplicate database files the same as the target files.
• You are not using a recovery catalog.
• You are using automa tic channels for disk and sbt, which are already configured.
• You want to recov er the duplicate database to one week ago in order to view the data in prod1 as it appeared at that time.

  CONNECT TARGET SYS/oracle@trgt
  CONNECT AUXILIARY SYS/oracle@dupdb
  
  DUPLICATE TARGET DATABASE TO dupdb 
      NOFILENAMECHECK UNTIL TIME 'SYSDATE-7';
  

Du plicating with a Client-Side Parameter File: Example

If you use a cl ient-side initialization parameter file to start the auxiliary instance, then it must reside on the same host as the RMAN client used to perform the duplication. Assume the following scenario:

• Th e target host is host_tar and the duplicate host is host_dup
• The client-side initialization parameter file on host_dup is named /orahome/dbs/initTEST.ora.
• The hosts host_dup and host_tar are linked by a network.

In this scenario, you can run the RMAN client (that is, run the DUPLICATE command in an RMAN session) either on host_tar or host_dup.

Running RMAN from host_dup

If you run the executable on host_dup, you can duplicate the database as follows:

DUPLICATE  
  TARGET DATABASE TO dupdb
  DEVIC
E TYPE sbt
  PFILE='/orahome/dbs/initTEST.ora';

Because the initialization parameter file used by the auxiliary instance resides on the same node as the RMAN client, you can re ference the local filename of the parameter file.

Running RMAN from host_tar

In this scenario, you run RMAN on the same host as the target database rather than on the host with the duplicate database. Hence, th e client-side initialization parameter file needed by the DUPLICATE command is not located on the same node as the RMAN client. You must transfer the parameter file from host_dup to host_tar, or remotely mount the directory con taining the parameter file by some means such as NFS, so that it can be accessed from the target host.

Copying the Parameter File from host_du p to host_tar

In this scenario, you manually copy the file from one host to another. In Unix systems you could use the cp command:

% cp /net/host_dup/orahome/d
bs/initTEST.ora /net/host_tar/tmp

Then, you can start RMAN on host_tar and perform the duplication with the following command:

% rman TARGET SY
S/oracle@trgt AUXILIARY SYS/oracle@dupdb
RMAN> DUPLICATE TARGET DATABASE TO dupdb

    DEVICE TYPE sbt PFILE='/net/host_tar/tmp/initTEST.ora';
RMAN> EXIT

Mounting the host_dup File System on host_t ar

In this scenario, you mount the host_dup file system on the host_tar file system by using /net/host_dup as the mount point. The /net/host_dup/initTEST.or a filename on host_tar points to the /orahome/dbs/initTEST.ora file residing on host_dup. Then, you can run the duplication as follows:

DUPLICATE  
  TARGET
 DATABASE TO dupdb
  DEVICE TYPE sbt
  PFILE='/net/host_dup/initTEST.ora';