Skip Headers
Oracle® Database Backup and Recovery Advanced User's Guide
10g Release 2 (10.2)

Part Number B14191-01
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Feedback

Go to previous page
Previous
Go to next page
Next
View PDF

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

For instructions on how to create and maintain Oracle password files, refer to Oracle 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. The parameters listed in Table 13-6 must be set to the values specified.

Table 13-6 Database Name and Control File Name Initialization Parameters

Parameter Required Value
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 the same Oracle home.
CONTROL_FILES Refer to "How RMAN Creates the Duplicate Control Files".

The block size for the auxiliary database must match that of the target database. If the target database parameter file contains a value for the DB_BLOCK_SIZE initialization parameter, then you must specify the same value in the auxiliary instance parameter file. If no DB_BLOCK_SIZE is specified in the target database parameter file, then do not specify DB_BLOCK_SIZE in the auxiliary instance parameter file.

You can also set the initialization parameters described in Table 13-7.

Table 13-7 Filename Conversion Initialization Parameters

Initialization 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 "How RMAN Creates the Duplicate Online Redo Logs".

If you do not set the conversion parameters shown in Table 13-7, then you can set the DB_CREATE_FILE_DEST, DB_CREATE_ONLINE_LOG_DEST_n, or DB_RECOVERY_FILE_DEST initialization parameter. In this case, the DUPLICATE command creates the datafiles, online redo logs, and tempfiles as Oracle Managed Files. If the CONTROL_FILES initialization parameter is not set, then the DUPLICATE command also creates the control file as an Oracle Managed File.

Set other initialization 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 attention to all initialization parameters specifying path names. Verify that all paths are accessible on the host where the database is being duplicated.

Example 13-1 shows sample initialization parameter settings for the duplicate database.

Example 13-1 Sample Initialization Parameters for 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 parameters have equivalents
# on the DUPLICATE command itself
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. 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 client 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 it if it is not already mounted or open. For example, enter:

-- connect to target database
SQL> CONNECT SYS/oracle@trgt AS SYSDBA;
-- mount or open target database
STARTUP MOUNT;

Task 6: Make Sure You Have the Necessary Backups 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 backup 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 accessible at the same path by the node where the duplicate database is to be created. These can be available either as backups (for instance, on a media manager) or as image copies (or the actual archived redo logs). The backups or copies can be transferred to the local disk of the node that contains the duplicate database or possibly 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 instances. If the auxiliary instance requires a client-side initialization parameter file, then this file must exist on the same host that 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@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.

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 TARGET DATABASE TO dupdb;
}

Note:

If you configure automatic channels, then RMAN can use configured channels for duplication even if they do not specify the AUXILIARY option. Nevertheless, if the auxiliary channels need some special parameters (for example, to point to a different media management subsystem), then you can configure an automatic channel with the AUXILIARY option.