12
Duplicating a Database with Recovery Manager

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

• Creating a Duplicate Database: Overview
• Generating Files for the Duplicate Database
• Preparing the Auxiliary Instance for Duplication: Basic Steps
• Creating a Duplicate Database on a Local or Remote Host
• Database Duplication Examples

  See Also: Oracle9i Data Guard Concepts and Administration to learn how to create a standby database using the DUPLICATE command

Creating a Duplicate Database: Overview

You can use the RMAN DUPLICATE command to create a duplicate database from target database backups while still retaining the original target database. The duplicate database can be either identical to the original database or contain only a subset of the original tablespaces. A duplicate database is a copy of the target database that you can run independently for a variety of purposes. For example, you can use it to:

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

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

A duplicate database is distinct from a standby database, although both types 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 by using 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 database, on the other hand, cannot be used in this way: it is not intended for failover scenarios and does not support the various standby recovery and failover options.

How Recovery Manager Duplicates a Database

To prepare for database duplication, you must first create an auxiliary instance 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 auxiliary instance started in NOMOUNT mode.

You must have at least one auxiliary channel 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 create the duplicate database, and initiates recovery.

So long as RMAN is able to connect to the primary and duplicate instances, the RMAN client can run on any machine. However, all backups, copies of datafiles, and archived logs used for creating and recovering the duplicate database must be accessible by the server session on the duplicate host. If the duplicate host is different from the primary host, then you must make backups and copies on the primary host disks available to the remote node with the same full path name as in the primary database. You can accomplish this goal in two ways:

• Using an operating system utility to move the backup pieces, image copies, and archived logs from the primary host to the remote host to an identical path
• Using NFS or shared disks and making sure that the same path is accessible in the remote host

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

As part of the duplicating operation, RMAN manages the following:

• 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 database (refer to "Task 4: Start the Auxiliary Instance" for issues relating to client-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 DUPLICATE ... 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 database 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 database. 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

When duplicating a database, you can do the following:

• Run the DUPLICATE command with or without a recovery catalog
• Skip read-only tablespaces with the SKIP READONLY clause. Read-only tablespaces are included by default. If you omit them, then you can add them later.
• Exclude tablespaces from the duplicate database with the SKIP TABLESPACE clause. You cannot skip the SYSTEM tablespace or tablespaces containing rollback or undo segments.
• Create the duplicate database in a new host. If the directory structure is the same on the new host, then you can specify the NOFILENAMECHECK option and reuse the target datafile filenames for the duplicate datafiles.
• Use the SET UNTIL command or DUPLICATE command with the UNTIL clause when creating the duplicate database to recover it to a noncurrent time. By default, the DUPLICATE command creates the database by using the most recent backups of the target database and then performs recovery to the most recent consistent point contained in the incremental backups and archived logs.
• Register the duplicate database in the same recovery catalog as the target database. This option is possible because RMAN gives the duplicate database a new DBID during duplication.

  Note: If you copy the target database by means of operating system utilities, then the DBID of the copied database remains the same as the original database. To register the copy database in the same recovery catalog with the original, you must change the DBID with the DBNEWID utility (refer to Oracle9i Database Utilities).

• Set the duplicate database DB_NAME differently from the target database DB_NAME in some cases. If the duplicate database exists in the same Oracle home as the target, then the DB_NAME initialization parameter must be different. If the duplicate database resides in a different Oracle home (on the same machine or on another machine), then its DB_NAME setting just has to be different from other database names in the same Oracle home on the duplicate host.

Obeying Duplication Prerequisites and Restrictions

RMAN duplication involves a number of prerequisites, restrictions, and caveats. Review the restrictions section of the DUPLICATE syntax entry before attempting duplication (see Oracle9i Recovery Manager Reference for DUPLICATE syntax).

Generating Files for the Duplicate Database

When duplicating a database, RMAN creates the required database files. This section describes these stages of file creation:

• Creating the Duplicate Control Files
• Creating the Duplicate Online Redo Logs
• Naming the Duplicate Datafiles

Creating the Duplicate Control Files

The DUPLICATE command creates the control files by using the names listed in the initialization parameter file of the auxiliary instance. When choosing names for the duplicate database control files, make sure that you set the initialization parameter settings correctly so that you do not overwrite the production files at the target database.

Creating the Duplicate Online Redo Logs

Table 12-1 lists the options for creating the names of the duplicate online redo logs. The options appear in the order of precedence.

Table 12-1 Order of Precedence for Redo Log Filename Creation

Order	Method	Result
1	Specify the LOGFILE clause of DUPLICATE command.	Creates redo logs as specified.
2	Set LOG_FILE_NAME_CONVERT initialization parameter.	Transforms target filenames, for example, from log_* to duplog_*. Note that you can specify multiple conversion pairs. This parameter allows the redo log to exist as long as the size matches, because it uses the REUSE parameter when creating the logs.
3	Do none of the preceding steps.	Makes the duplicate filenames the same as the target filenames. You must specify the NOFILENAMECHECK option when using this method and the duplicate database should be in a different host.

The order of precedence determines how RMAN renames the online redo logs. For example, if you specify both the LOGFILE clause and the LOG_FILE_NAME_CONVERT parameter, then RMAN uses the LOGFILE clause. If you specify neither of the first two options, then RMAN uses the original target redo log filenames for the duplicate database files.

Naming the Duplicate Datafiles

To have different filenames for the duplicate datafiles, you must use parameters or commands to specify them. Table 12-2 lists the options for renaming datafiles. The options appear in the order of precedence.

Table 12-2 Order of Precedence for Datafile Filename Creation

Order	Method	Result
1	Issue SET NEWNAME command.	Creates new datafile filenames. You must reissue this command each time you rename files.
2	Issue CONFIGURE AUXNAME command.	Creates new datafile filenames. This setting stays in effect until disabled with a CONFIGURE AUXNAME ... CLEAR command.
3	Set DB_FILE_NAME_CONVERT initialization parameter.	Transforms target filenames, for example, from /oracle/ to /dup/oracle/. Note that you can specify multiple conversion pairs. You can use this parameter for those files not renamed with either SET NEWNAME and CONFIGURE AUXNAME.
4	Do none of the preceding steps.	Reuses the target filenames. You must specify the NOFILENAMECHECK option when using this method and the duplicate database should be in a different host.

The order of precedence determines how RMAN names the files. For example, if you specify all the commands and the initialization parameter, then RMAN uses SET NEWNAME. If you run CONFIGURE AUXNAME and DB_FILE_NAME_CONVERT, then RMAN uses CONFIGURE AUXNAME. If you do not specify any of the first three options, then RMAN uses the original target filenames for the duplicate file.

Skipping Read-Only Tablespaces

When you specify SKIP READONLY, RMAN does not duplicate the datafiles of read-only tablespaces. After duplication is complete, you can query the views in the duplicate database described in Table 12-3 and Table 12-4 to determine whether datafiles are read-only. The STATUS and ENABLED columns are the key to determining the current status of the duplicate datafile.

Table 12-3 Read-Only Tablespaces in V$DATAFILE View on Duplicate Database

In the column ...	The value is ...
STATUS	OFFLINE
ENABLED	READ ONLY
NAME	MISSINGxxx

Table 12-4 Read-Only Tablespaces in Data Dictionary Views on Duplicate Database

View	In the column ...	The value is ...
DBA_DATA_FILES	STATUS	AVAILABLE
DBA_TABLESPACES	STATUS	READ ONLY

Skipping OFFLINE NORMAL Tablespaces

When tablespaces are taken offline with the OFFLINE NORMAL option, RMAN does not duplicate the datafiles of these tablespaces. After duplication, you can manually add or drop these tablespaces. Query the views in the duplicate database described in Table 12-5 and Table 12-6 to determine whether datafiles are offline. The STATUS and ENABLED columns are the key to determining the current status of the datafile.

Table 12-5 Offline Tablespaces in V$ Views on Duplicate Database

In the column ...	The value is ...
STATUS	OFFLINE
ENABLED	DISABLED
NAME	MISSINGxxx

Table 12-6 Offline Tablespaces in Data Dictionary Views on Duplicate Database

View	In the column ...	The value is ...
DBA_DATA_FILES	STATUS	AVAILABLE
DBA_TABLESPACES	STATUS	OFFLINE

When you take a tablespace offline with the IMMEDIATE option, RMAN duplicates rather than skips the tablespace because this tablespace requires recovery. As with online tablespaces, RMAN requires a valid backup for duplication.

Preventing Filename Checking

It is possible for a CONFIGURE AUXNAME, SET NEWNAME, or DB_FILE_NAME_CONVERT to generate a name that is already in use in the target database. In this case, specify NOFILENAMECHECK to avoid an error message. For example, assume that the host A database has two files: datafile 1 is named /oracle/data/file1.f and datafile 2 is named /oracle/data/file2.f. When duplicating to host B, you use a configured channel to duplicate as follows:

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

Even though you issued SET NEWNAME commands for all the datafiles, the DUPLICATE command fails because the duplicate filenames are still in use in the target database. Although datafile 1 in the target is not using /oracle/data/file2.f, and datafile 2 in the target is not using /oracle/data/file1.f, the target filename is used by one of the duplicate datafiles and so you must specify NOFILENAMECHECK to avoid an error.

Preparing the Auxiliary Instance for Duplication: Basic Steps

Perform these tasks before performing RMAN duplication:

• Task 1: Create an Oracle Password File for the Auxiliary Instance
• Task 2: Ensure Oracle Net Connectivity to the Auxiliary Instance
• Task 3: Create 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: Create an Oracle Password File for the Auxiliary Instance

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

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 Auxiliary Instance

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

Parameter	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 Oracle home from the target, then its DB_NAME just has to differ from other database names in that same Oracle home.
CONTROL_FILES	Refer to "Creating the Duplicate Control Files".

Optionally, set the parameters described in the following table.

Parameter	You must specify:
DB_FILE_NAME_CONVERT	Refer to "Naming the Duplicate Datafiles".
LOG_FILE_NAME_CONVERT	Refer to "Creating the Duplicate Online Redo Logs".

Set other parameters, including the parameters that allow you to connect as SYSDBA through Oracle Net, as needed. When duplicating to the same host or to a new host with a different file system, pay special attention to all parameters 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)
DB_FILE_NAME_CONVERT=(/oracle/oradata/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 file, you can run the CREATE SPFILE command from SQL*Plus to create a server-side initialization parameter file. You can run this command before or after instance startup. For example, you can create a server-side parameter file in the default 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 parameter 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 NOMOUNT 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 process. Hence, it is a good idea to create a server-side initialization parameter file for the auxiliary instance in the default location.

If you do not have a server-side initialization parameter file for the auxiliary instance in the default location, then 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 executable used to perform the duplication.

Task 5: Mount or Open the Target Database

Before beginning RMAN duplication, connect SQL*Plus to the target database and mount or open tit--specifying a client-side parameter file if necessary--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

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

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

Make sure that you meet either of the following conditions:

• You have backups of all the archived redo logs necessary to recover to the desired time, SCN, or log sequence number. These backups must be accessible by the node where the duplicate database is going to be created. For example, if you back up through a media manager, then ensure that the duplicate host can restore objects backed up on the target host.
• The archived redo logs are accessible on the node where the duplicate database is going to be created. Note that you can copy logs to the duplicate host manually or use NFS to mount log directories on the target host.

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

Start RMAN with a connection to the target database, the duplicate database, and (if you use one) the recovery catalog database. You can start the RMAN executable on any host so long as it can connect to all the instances. Note that if the duplicate instance requires a client-side initialization parameter file, then this file must exist on the same host that runs the RMAN executable.

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

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

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

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

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

Creating a Duplicate Database on a Local or Remote Host

When you create a duplicate database, the procedure differs depending on your configuration. This section contains these topics:

• Duplicating a Database on a Remote Host with the Same Directory Structure
• Duplicating a Database on a Remote Host with a Different Directory Structure
• Creating a Duplicate Database on the Local Host

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 case, you do not need to change the initialization parameter file or set new filenames for the duplicate datafiles.

1. Follow the steps in "Preparing the 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 executable used to perform the duplication.

   The following example assumes that the RMAN executable 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 executable) for
     # auxiliary instance if necessary
     PFILE = /dup/oracle/dbs/initDUPDB.ora
     NOFILENAMECHECK;
   
   

RMAN automatically allocates the configured channels, then uses all incremental backups, 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 file system, then you need to change several initialization parameters and generate new filenames for the duplicate database datafiles.

Use LOG_FILE_NAME_CONVERT or the LOGFILE clause to convert the online redo log filenames. Use DB_FILE_NAME_CONVERT, the SET NEWNAME command, or the CONFIGURE AUXNAME command for the datafile filenames.

This section contains these topics:

• Duplicating By Using Initialization Parameters
• Duplicating By Using Initialization Parameters and the LOGFILE Clause
• Duplicating By Using SET NEWNAME
• Duplicating By Using CONFIGURE AUXNAME

  See Also: Table 12-2 for a table of the various datafile filename conversion options

Duplicating By Using Initialization Parameters

This procedure assumes that you set initialization parameters to rename the duplicate datafiles and log files.

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. Make sure to set:
   • All initialization parameters that end in _DEST or _PATH and specify a path name.
   • DB_FILE_NAME_CONVERT so that it captures all the target datafiles and converts them appropriately, for example, from /oracle/oradata/ to /dup/oracle/oradata/.
   • 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 example, you can specify that DB_FILE_NAME_CONVERT changes /fs1 to /dsk1 and /fs2 to /dsk2.

2. Perform the following operations when running the duplication:
   • If automatic channels are not configured, then allocate at least one auxiliary channel.
   • If desired, specify the same number of redo log members and groups that are used in the target database.
   • If using a client-side parameter file to start the auxiliary instance, specify the PFILE parameter.

   The following example assumes that the duplicate host can access the same media manager as the primary database host. The example duplicates the database with an automatic 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;
   # Note that DUPLICATE DEVICE TYPE sbt works only if the sbt device is configured
   # with CONFIGURE CHANNEL, CONFIGURE DEVICE TYPE, or CONFIGURE DEFAULT DEVICE.
   
   

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

Duplicating By Using Initialization Parameters and the LOGFILE Clause

This procedure assumes that you set initialization parameters to rename the duplicate datafiles and the LOGFILE clause to specify names and sizes for the online redo logs.

1. Follow the procedure described in "Duplicating By Using Initialization Parameters", but do not set the LOG_FILE_NAME_CONVERT parameter.
2. Perform the following operations when running the duplication:
   • If automatic auxiliary channels are not configured, then allocate at least one auxiliary channel.
   • Specify the names and sizes for the duplicate database redo logs in the LOGFILE clause.
   • Specify new filenames for the duplicate database datafiles.
   • If using 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 parameter file as well as the LOGFILE clause:

DUPLICATE TARGET DATABASE TO dupdb
  # specify client-side parameter file for auxiliary instance if necessary
  PFILE = /dup/oracle/dbs/initDUPDB.ora
  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;

Duplicating By Using 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", 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. Set all initialization parameters that end in _DEST or _PATH and specify a path name.
2. Perform the following operations when running the duplication:
   • If automatic auxiliary channels are not configured, then allocate at least one auxiliary channel.
   • If desired, specify the same number 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 duplication, and uses the LOGFILE clause to specify names and sizes for the online redo logs:

   RUN
   {
     # set new filenames for the datafiles
     SET NEWNAME 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.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/redo02b.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. RMAN shuts down, starts up, and then opens the database with the RESETLOGS option to create the online logs.

Duplicating By Using 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 specify a path name.
2. Perform the following operations during duplication:
   • If automatic auxiliary channels are not allocated, then allocate at least one auxiliary channel.
   • If desired, specify the same number of redo log members and groups that are used in the target database.
   • If you start the auxiliary instance with a client-side parameter file, then specify the PFILE parameter. The client-side parameter file must reside on the same host as the RMAN executable used to perform the duplication.

   The following example 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:

   # run the DUPLICATE command
   DUPLICATE TARGET DATABASE TO dupdb
   # specify client-side parameter file for auxiliary instance if necessary
   PFILE = /dup/oracle/dbs/initDUPDB.ora
   .
   .
   .
   # create at least two online redo log groups
    LOGFILE
       GROUP1
       (
         '/dup/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/redo02b.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 option to create the online redo logs.

3. Clear the auxiliary names for the datafiles so that they are not overwritten by mistake. For example, enter the following:

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

Creating a Duplicate Database on the Local Host

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".

Note that you can duplicate the database to the same Oracle home as the target database, but you must convert the filenames by means of the same methods used for conversion on a separate host.

Database Duplication Examples

This section contains these topics:

• Setting New Filenames Manually: Example
• Resynchronizing the Duplicate Database with the Target Database: Example
• Creating a Non-Current Duplicate Database: Example
• Duplication with a Client-Side Parameter File: Example

Setting New Filenames Manually: Example

This example assumes the following:

• You are using recovery catalog database catdb.
• The target database trgt is on host1 and contains eight datafiles.
• You want to duplicate the target to database dupdb on remote host host2.
• host1 and host2 use different file systems.
• You want to store the datafiles in host2 in the ?/oradata/dup/ subdirectory.
• You want to exclude tablespace tools from the duplicate 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 have disk copies or backup sets stored on disk for all the datafiles and archived redo logs in the target database, and you have manually moved them to host2 by means of an operating system utility.
• You want two online redo logs groups, each with two members of size 200 KB.
• You have configured the default device to sbt. The media management 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@catdb;
  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
    SET NEWNAME FOR DATAFILE 1 TO '?/oradata/dup/system01.dbf'; 
    SET NEWNAME FOR DATAFILE 2 TO '?/oradata/dup/undotbs01.dbf'; 
    SET NEWNAME FOR DATAFILE 3 TO '?/oradata/dup/cwmlite01.dbf'; 
    SET NEWNAME FOR DATAFILE 4 TO '?/oradata/dup/drsys01'; 
    SET NEWNAME FOR DATAFILE 5 TO '?/oradata/dup/example01.dbf'; 
    SET NEWNAME FOR DATAFILE 6 TO '?/oradata/dup/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 '?/oradata/dup/users01.dbf'; 
    DUPLICATE TARGET DATABASE TO dupdb
      SKIP TABLESPACE tools
      LOGFILE
        GROUP 1 ('?/oradata/dup/redo01a.log', 
                 '?/oradata/dup/redo01b.log') SIZE 200K REUSE, 
        GROUP 2 ('?/oradata/dup/redo02a.log', 
                 '?/oradata/dup/redo02b.log') SIZE 200K REUSE;
  }
  

Resynchronizing the Duplicate Database with the Target Database: Example

This example makes the same assumptions as in "Setting New Filenames Manually: Example". Additionally, it assumes that you want to update the duplicate database daily so that it stays current with the target database.

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

# configure auxiliary names for the datafiles only once     
CONFIGURE AUXNAME FOR DATAFILE 1 TO '?/oradata/dup/system01.dbf'; 
CONFIGURE AUXNAME FOR DATAFILE 2 TO '?/oradata/dup/undotbs01.dbf'; 
CONFIGURE AUXNAME FOR DATAFILE 3 TO '?/oradata/dup/cwmlite01.dbf'; 
CONFIGURE AUXNAME FOR DATAFILE 4 TO '?/oradata/dup/drsys01'; 
CONFIGURE AUXNAME FOR DATAFILE 5 TO '?/oradata/dup/example01.dbf'; 
CONFIGURE AUXNAME FOR DATAFILE 6 TO '?/oradata/dup/indx01.dbf'; 
# do not configure an auxiliary name 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 '?/oradata/dup/users01.dbf'; 

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

Creating a Non-Current Duplicate Database: Example

This duplication example assumes the following:

• The target database trgt and duplicate 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 do not have automatic channels configured.
• You want to recover 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
  RUN
  { 
    SET UNTIL TIME 'SYSDATE-7';
    ALLOCATE AUXILIARY CHANNEL dupdb1 DEVICE TYPE sbt; 
    DUPLICATE TARGET DATABASE TO dupdb 
    NOFILENAMECHECK;
  }
  

Duplication with a Client-Side Parameter File: Example

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

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

In this scenario, you can run the RMAN executable (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
  DEVICE TYPE sbt
  PFILE='?/dbs/initTEST.ora';

Because the initialization parameter file used by the auxiliary instance resides on the same node as the RMAN executable, you can reference 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, the client-side initialization parameter file needed by the DUPLICATE command is not located on the same node as the RMAN executable. You must do one of the following:

• Transfer the parameter file from host_dup to host_tar.
• Use NFS to mount the host_dup directory containing the parameter file on the host_tar file system.

Copying the Parameter File from host_dup to host_tar

In this scenario, you manually copy the file from one host to another as follows:

% cp /net/host_dup/oracle/dbs/initTEST.ora /net/host_tar/tmp

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

#!/usr/bin/sh
rman TARGET SYS/oracle@trgt AUXILIARY SYS/oracle@dupdb <<EOF
DUPLICATE 
  TARGET DATABASE TO dupdb
  DEVICE TYPE sbt
  PFILE='/tmp/initTEST.ora';
EOF

Mounting the host_dup File System on host_tar

In this scenario, you mount the host_dup file system on the host_tar file system by using /tmp as the mount point. The /tmp/initTEST.ora filename on host_tar points to the ?/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='/tmp/initTEST.ora';