D
Creating a Physical Standby Database with Recovery Manager

This appendix describes how to use Oracle Recovery Manager to create a physical standby database. This appendix contains the following topics:

• Preparing to Use RMAN to Create a Standby Database
• Creating a Standby Database with RMAN: Overview
• Setting Up the Standby Instance
• Creating a Standby Database with the Same Directory Structure
• Creating a Standby Database with a Different Directory Structure
• Creating a Standby Database on the Local Host
• Creating a Standby Database with Image Copies
• Usage Scenario

D.1 Preparing to Use RMAN to Create a Standby Database

There are several advantages to using RMAN to create a standby database:

• RMAN creates standby databases using backups of the primary database, restoring datafiles to the standby site from backups. Thus, the primary database is not affected during the creation of standby database.
• RMAN automates renaming of files, or directory structures.
• RMAN restores archived redo log files from backups and performs recovery to catch up the standby database to the primary database.

The procedure for preparing a standby database with RMAN is basically the same as for preparing a duplicate database. Nevertheless, you need to amend the duplication procedures described in Oracle Database Backup and Recovery Advanced User's Guide to account for the issues specific to a standby database.

Familiarize yourself with how to create a physical standby database in Chapter 3 before you attempt the RMAN creation procedures described in this chapter.

This section contains these topics:

• About Standby Database Preparation Using RMAN
• Creating the Standby Control File with RMAN
• Naming the Standby Database Datafiles When Using RMAN
• Naming the Standby Database Log Files When Using RMAN

D.1.1 About Standby Database Preparation Using RMAN

You can use either manual methods or the Recovery Manager DUPLICATE command to create a standby database from backups of your primary database. Before you perform the creation procedure, you must prepare the standby instance. You can use RMAN to do the preparation tasks described in Table D-1.

Table D-1  Standby Database Preparation Using RMAN

Task	Procedure
Make a backup of the primary database to use to create a standby database.	Use the normal backup procedure for your primary database as documented in Oracle Database Backup and Recovery Basics.
Create a backup of the primary control file that is usable as a standby control file (if you do not have one).	See Section D.1.2, "Creating the Standby Control File with RMAN".
Choose filenames for the standby datafiles.	See Section D.1.3, "Naming the Standby Database Datafiles When Using RMAN".
Choose filenames for the standby database archived redo log files and standby redo log files.	See Section D.1.4, "Naming the Standby Database Log Files When Using RMAN".

In addition to the RMAN tasks described in Table D-1, you must also perform the following additional tasks to set up your standby database:

• Set all necessary initialization parameters in the primary initialization parameter file.
• Create an initialization parameter file for the standby database and configure all necessary parameters.
• Set up and configure Oracle Net, as required, to connect to the standby instance.
• Start the standby instance without mounting the control file.

See Chapter 3 for a complete discussion of physical standby database preparation, including initialization parameter settings. You must perform all necessary preparation tasks described in these chapters before RMAN can successfully create the standby database files and mount the standby database.

D.1.2 Creating the Standby Control File with RMAN

You can create the standby control file using either the RMAN BACKUP or COPY commands by performing the following steps:

Step 1 Connect to the primary database.

Connect to the primary database and, if desired, the recovery catalog database. For example, enter:

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

Step 2 Create the standby control file.

Use either of the following commands to create the standby control file. The only difference between BACKUP and COPY commands is that the file format of the backup file is different.

• Using the BACKUP command

  Mount the primary database and create the standby control file with the BACKUP CURRENT CONTROLFILE FOR STANDBY command. The following example uses a configured channel to create the standby control file. Then open the database, archive all unarchived redo log files, and back up any log files that have not yet been backed up at least once:

  STARTUP MOUNT
  BACKUP CURRENT CONTROLFILE FOR STANDBY;
  SQL> ALTER DATABASE OPEN;
  SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT';  # so backup is consistent and 
  recoverable
  BACKUP ARCHIVELOG ALL NOT BACKED UP 1 TIMES;
  
  

• Using the COPY command

  Copy the current primary control file. Specify the FOR STANDBY option of the COPY CURRENT CONTROLFILE command to make a copy of the current control file that is usable as a standby control file. For example:

  COPY CURRENT CONTROLFILE FOR STANDBY TO '/tmp/sby_control01.ctl';
  

Step 3 List the backup sets or image copies.

If desired, issue a LIST command to see a listing of the backup sets and pieces, or issue a LIST COPY command to see a listing of the image copies.

D.1.3 Naming the Standby Database Datafiles When Using RMAN

A standby database can reside either on the same host as the primary database or on a different host. The following table illustrates the implications for renaming the standby database datafiles depending on if the directory structures on the hosts are the same or different.

Standby Database Host	Directory Structure	Renaming
Same host as primary	Different from primary host	Necessary.
Same host as primary	Same as primary host	Illegal. The standby database datafiles cannot exist in the same directories as the primary database datafiles on the same host.
Different host from primary	Same as primary host	Not necessary.
Different host from primary	Different from primary host	Necessary.

When the directory structures are different for the primary and standby hosts, you have these options for naming the standby datafiles:

• Configuring the standby database initialization parameter DB_FILE_NAME_CONVERT
• Use the DB_FILE_NAME_CONVERT option of the RMAN DUPLICATE command
• By using the RMAN CONFIGURE AUXNAME or SET NEWNAME command when creating the standby database

When the directory structures are the same for the primary and standby hosts, then you have these naming options:

• Leaving the standby filenames the same as the primary filenames (that is, not setting DB_FILE_NAME_CONVERT or issuing a CONFIGURE AUXNAME or SET NEWNAME command) and specifying the NOFILENAMECHECK option of the DUPLICATE command
• By using the DB_FILE_NAME_CONVERT parameter, or the CONFIGURE AUXNAME or SET NEWNAME commands to rename the standby datafiles

Note that when you use DB_FILE_NAME_CONVERT, the format is as follows:

DB_FILE_NAME_CONVERT = 'oldstring1', 'newstring1', 'oldstring2', 'newstring2', ...

For example, you can specify the DB_FILE_NAME_CONVERT initialization parameter as follows:

DB_FILE_NAME_CONVERT = '/dbs/t1/', '/dbs/t1/s_', '/dbs/t2/', '/dbs/t2/s_'

Because you can specify datafile filenames in the standby control file in multiple ways, a method for prioritizing settings is necessary. Table D-2 specifies the hierarchy for the naming of datafiles in the standby database.

Table D-2  Order of Precedence for Naming Datafiles in Standby Database

	Method of Standby Datafile Naming	Requirement
1	Issue SET NEWNAME command.	You must issue this command in the RUN block for the creation of the standby database.
2	Use the DB_FILE_NAME_CONVERT option of the RMAN DUPLICATE command.	None.
3	Issue CONFIGURE AUXNAME command.	You must be connected to a recovery catalog, and an AUXNAME that is not NULL must be stored in the catalog for the datafile.
4	Datafile filename as currently specified in the standby control file. The standby filename is identical to the primary filename or is named with the DB_FILE_NAME_CONVERT parameter.	If the filename is different, then the DB_FILE_NAME_CONVERT parameter must be set in the standby initialization parameter file. If the filename is the same, then you must specify the NOFILENAMECHECK clause of the DUPLICATE command.

See Oracle Database Reference for more information about how to use DB_FILE_NAME_CONVERT to name standby files.

D.1.4 Naming the Standby Database Log Files When Using RMAN

Redo log files are not created on the standby database by RMAN. However, as described in Chapter 3, log files can be created by other actions that you perform on the standby database. After the log files are created, they are maintained and archived according to the normal rules for log files.

The only option when naming the redo log files on the standby database is the filenames for the log files, as specified in the standby control file. If the log filenames on the standby must be different from the primary filenames, then one option is to specify filenames for the redo logs by setting LOG_FILE_NAME_CONVERT in the standby initialization parameter file.

Note these restrictions when specifying filenames for the redo log files on the standby database:

• You must use the LOG_FILE_NAME_CONVERT parameter to name the redo log files if the primary and standby databases use different naming conventions for the log files.
• You cannot use the SET NEWNAME or CONFIGURE AUXNAME commands to rename the redo log files.
• You cannot use the LOGFILE clause of the DUPLICATE command to specify filenames for the redo log files.
• If you want the redo log filenames on the standby database to be the same as the primary redo log filenames, then you must specify the NOFILENAMECHECK clause of the DUPLICATE command. Otherwise, RMAN signals an error even if the standby database is created in a different host.

D.2 Creating a Standby Database with RMAN: Overview

When you create a standby database, the procedure differs depending on whether the standby database is on the same host as the primary database or on a different host. The procedures in this chapter assume that you have already completed the standby setup and preparation as outlined in Chapter 3. Do not attempt these procedures until you have made all necessary initialization parameter settings and network configuration changes.

After you have performed the steps necessary for preparing the standby instance, run the Recovery Manager DUPLICATE ... FOR STANDBY command to create the standby database out of backups of the primary database. Note that a standby database, unlike a duplicate database created by DUPLICATE without the FOR STANDBY OPTION, does not get a new DBID. Hence, you should not register the standby database with your recovery catalog.

The steps for creating the standby database differ depending on whether or not you specify that RMAN should recover the standby database after creating it.

See Oracle Database Backup and Recovery Advanced User's Guide to learn how to use the DUPLICATE command to create a duplicate database that is not a standby database.

D.2.1 RMAN Standby Creation Without Recovery

By default, RMAN does not recover the standby database after creating it. If you do not specify the DORECOVER option of the DUPLICATE command, then RMAN automates these steps of the standby creation procedure during duplication:

1. RMAN establishes connections both to the primary and standby databases, and the recovery catalog (if used).
2. RMAN queries the repository, which is either the primary control file or the recovery catalog, to identify the backups of primary database datafiles and the standby control file.
3. If you use a media manager, then RMAN contacts the media manager on the standby host to request the backup data.
4. RMAN restores the standby control file to the standby host, thereby creating the standby control file.
5. RMAN restores the primary datafile backups and copies to the standby host, thereby creating the standby database datafiles.
6. RMAN leaves the standby database mounted, but does not place the standby database in manual or managed recovery mode. RMAN disconnects and does not perform media recovery of the standby database. Note that you should not register the standby database in the recovery catalog.

D.2.2 RMAN Standby Creation with Recovery

If you do specify the DORECOVER option of the DUPLICATE command, then RMAN performs the same Steps 1-5 in Section D.2.1. Instead of Step 6, it performs these steps:

1. After all data is restored, RMAN begins media recovery. If recovery requires archived redo log files, and if the log files are not already on disk, RMAN attempts to restore it from backups.
2. RMAN recovers the standby database to the specified time, system change number (SCN), or log file sequence number, or to the latest archived redo log file generated if none of the preceding are specified.
3. RMAN leaves the standby database mounted after media recovery is complete, but does not place the standby database in manual or managed recovery mode. Note that you should not register the standby database in the recovery catalog.

   Note: After RMAN creates the standby database, you must resolve any gap sequence before placing it in manual or managed recovery mode, or opening it in read-only mode. Section 5.8 discusses gap sequence resolution in detail.

If you want RMAN to recover the standby database after creating it, then the standby control file must be usable for the desired recovery. Thus, these conditions must be met:

• The end recovery time of the standby database must be greater than or equal to the checkpoint SCN of the standby control file.
• An archived redo log file containing the checkpoint SCN of the standby control file must be available at the standby site for recovery.

One way to ensure these conditions are met is to issue the ALTER SYSTEM ARCHIVE LOG CURRENT statement after creating the standby control file. This statement archives the online redo log files of the primary database. Then, either back up the most recent archived redo log file with RMAN or move the archived redo log file to the standby site.

See Oracle Database Recovery Manager Reference for the list of DUPLICATE restrictions for creating a standby database with RMAN.

D.3 Setting Up the Standby Instance

No matter which standby creation scenario you choose, you must first start the standby instance and then connect RMAN to this instance. The details of this procedure vary depending on whether or not the standby and primary sites have a different directory structure.

To start the standby instance:

1. Use an operating system utility to copy the SPFILE (or the initialization parameter file) from the target host to the standby host. Set all required parameters in the standby database initialization parameter file as described in Section 3.2.3. For example, if creating the standby database on a separate host with a different directory structure, edit:
   • Initialization parameters that end with _DEST and _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 tbs_* to sbytbs_*
   • LOG_FILE_NAME_CONVERT so that it captures all the redo log files and converts them appropriately, for example, log_* to sbylog_*

   For example, the following are sample parameter settings in the standby database initialization parameter file:

   STANDBY_ARCHIVE_DEST = /fs3/arc_dest/
   LOG_ARCHIVE_FORMAT = log%d_%t_%s_%r.arc
   DB_FILE_NAME_CONVERT = '/oracle', '/fs3/oracle', '/dbf', '/fs3/oracle'
   LOG_FILE_NAME_CONVERT = '/oracle', '/fs3/oracle'
   
   

2. Use SQL*Plus to start the standby instance without mounting it. For example, enter the following to connect to sbdb1 as SYS (who has SYSDBA privileges) and start the database:

   SQL> CONNECT SYS/sys_pwd@sbdb1 AS SYSDBA
   SQL> STARTUP NOMOUNT PFILE=initSBDB1.ora
   
   

3. Use SQL*Plus to mount or open the primary database if it is not already mounted or open. For example, enter the following to connect to prod1 as SYS and open the database:

   SQL> CONNECT SYS/sys_pwd@prod1 AS SYSDBA
   SQL> STARTUP PFILE=initPROD1.ora
   
   

   Ensure the recovery catalog database is open. For example, enter the following to connect to catdb as SYS and open the recovery catalog database:

   SQL> CONNECT SYS/oracle@catdb AS SYSDBA
   SQL> STARTUP PFILE=initCATDB.ora
   
   

4. The standby instance must be accessible through Oracle Net. Before proceeding, use SQL*Plus to ensure you can establish a connection to the standby instance. Note that you must connect to the standby instance with SYSDBA privileges, so a password file must exist.
5. Connect to the target database, the standby instance, and (if you use one) the recovery catalog database. Note that you specify the primary database with the TARGET keyword and the standby instance with the AUXILIARY keyword.

   In the following example, connection is established without a recovery catalog by using operating system authentication:

   % rman TARGET / AUXILIARY SYS/sys_pwd@sbdb1
   

D.4 Creating a Standby Database with the Same Directory Structure

The simplest case is to create the standby database on a different host and to use the same directory structure. In this case, you do not need to set the DB_FILE_NAME_CONVERT or LOG_FILE_NAME_CONVERT parameters in the standby initialization parameter file or set new filenames for the standby datafiles. The primary and standby datafiles and log files have the same filenames.

D.4.1 Creating the Standby Database Without Performing Recovery

To create the standby database without performing recovery, do not specify the DORECOVER option on the DUPLICATE command. By default, RMAN leaves the standby database mounted and does not recover it.

To create a standby database without performing recovery:

1. Follow the steps in Section D.3. Make sure to set all necessary parameters in the standby initialization parameter file.
2. Follow these steps during duplication to create but not recover the standby datafiles:
   1. If you do not have automatic channels configured, then manually allocate at least one auxiliary channel. This channel performs the work of duplication.
   2. Specify NOFILENAMECHECK in the DUPLICATE command. The NOFILENAMECHECK option is required when the standby and primary datafiles and log files have the same names. Otherwise, RMAN returns an error.

   For example, run the following command to create the standby database:

   DUPLICATE TARGET DATABASE FOR STANDBY 
     NOFILENAMECHECK;
   

D.4.2 Creating the Standby Database and Performing Recovery

To create the standby database and perform recovery, specify the DORECOVER option on the DUPLICATE command.

To create a standby database and perform recovery:

1. Follow the steps in Section D.3. Make sure to set all necessary parameters in the standby initialization parameter file.
2. Follow these steps to restore and recover the standby datafiles:
   1. Ensure the end recovery time is greater than or equal to the checkpoint SCN of the standby control file and that a log file containing the checkpoint SCN is available for recovery.
   2. If desired, issue a SET command to specify the end time, SCN, or log sequence number for incomplete recovery.
   3. If automatic channels are not configured, then manually allocate at least one auxiliary channel.
   4. Specify the NOFILENAMECHECK parameter in the DUPLICATE command, and use the DORECOVER option.

   For example, enter the following at the RMAN prompt to use a configured channel to create the standby database:

   # If desired, issue a LIST command to determine the SCN of the standby 
   control file.
   # The SCN to which you recover must be greater than or equal to the standby 
   control 
   # file SCN.
   LIST BACKUP OF CONTROLFILE;
   LIST COPY OF CONTROLFILE;
   
   RUN
   {
     # If desired, issue a SET command to terminate recovery at a specified 
   point. 
     # SET UNTIL SCN 143508;
     DUPLICATE TARGET DATABASE FOR STANDBY 
       NOFILENAMECHECK
       DORECOVER;
   }
   
   

   RMAN uses all incremental backups, archived redo log file backups, and archived redo log files to perform incomplete recovery. The standby database is left mounted.

D.5 Creating a Standby Database with a Different Directory Structure

If you create the standby database on a host with a different directory structure, you need to specify new filenames for the standby database datafiles and redo log files. You can do the following:

• Set the LOG_FILE_NAME_CONVERT parameter in the standby initialization parameter file to name the redo log files on the standby database. If you do not set LOG_FILE_NAME_CONVERT, then you must use the NOFILENAMECHECK option of the DUPLICATE command.
• Set the DB_FILE_NAME_CONVERT parameter in the standby initialization parameter file to name the standby datafiles.
• Issue the SET NEWNAME command or the CONFIGURE AUXNAME command when using the RMAN DUPLICATE command to name the datafiles.

When creating the standby database on a host with a different directory structure, follow one of the procedures in the following sections:

• Naming Standby Database Files with DB_FILE_NAME_CONVERT
• Naming Standby Database Files with SET NEWNAME
• Naming Standby Database Files with CONFIGURE AUXNAME

See Oracle Database Backup and Recovery Advanced User's Guide to learn about the difference between SET NEWNAME and CONFIGURE AUXNAME, and Chapter 3 for a complete discussion of physical standby database preparation and creation.

D.5.1 Naming Standby Database Files with DB_FILE_NAME_CONVERT

In this procedure, you use the DB_FILE_NAME_CONVERT parameter to name the standby datafiles and the LOG_FILE_NAME_CONVERT parameter to name the redo log files on the standby database. See Section 3.1.3 for examples of how to use the DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT parameters to name standby database files.

D.5.1.1 Creating the Standby Database Without Performing Recovery

To create the standby database without performing recovery, do not specify the DORECOVER option on the DUPLICATE command. By default, RMAN leaves the standby database mounted and does not recover it.

To use parameters to name standby files without performing recovery:

1. Follow the steps in Section D.3. Make sure to set all necessary parameters in the standby initialization parameter file.
2. Run the DUPLICATE command. For example, run the following:

   DUPLICATE TARGET DATABASE FOR STANDBY;
   
   

   After restoring the backups, RMAN leaves the standby database mounted.

D.5.1.2 Creating the Standby Database and Performing Recovery

After using the DB_FILE_NAME_CONVERT parameter to name the standby datafiles and the LOG_FILE_NAME_CONVERT parameter to name the log files on the standby database, specify the DORECOVER option on the DUPLICATE command to create the standby database and perform recovery. The steps in the procedure are the same as for Section D.4.2.

D.5.2 Naming Standby Database Files with SET NEWNAME

In this procedure, you use SET NEWNAME commands to name the standby datafiles.

D.5.2.1 Creating the Standby Database Without Performing Recovery

To create the standby database without performing recovery, do not specify the DORECOVER option on the DUPLICATE command. By default, RMAN leaves the standby database mounted and does not recover it.

To name standby database files with the SET NEWNAME command without performing recovery:

1. Follow the steps in Section D.3. Make sure to set all necessary parameters in the standby initialization parameter file.
2. Run the DUPLICATE command. Perform the following steps:
   1. If automatic channels are not configured, then manually allocate at least one auxiliary channel.
   2. Specify new filenames for the standby database datafiles with SET NEWNAME commands.
   3. Issue the DUPLICATE command.

   The following example uses a configured channel to create the standby database:

   RUN
   {
     # set new filenames for the datafiles
     SET NEWNAME FOR DATAFILE 1 TO '?/dbs/standby_data_01.f'; 
     SET NEWNAME FOR DATAFILE 2 TO '?/dbs/standby_data_02.f'; 
     .
     .
     .
     # run the DUPLICATE command
     DUPLICATE TARGET DATABASE FOR STANDBY;
   }
   

D.5.2.2 Creating the Standby Database and Performing Recovery

To create the standby database and perform recovery, specify the DORECOVER option on the DUPLICATE command.

To use the SET NEWNAME command to name standby database files and perform recovery:

1. Follow the steps in Section D.3. Make sure to set all necessary parameters in the standby initialization parameter file.
2. Run the DUPLICATE command. Follow these steps:
   1. Ensure the end recovery time is greater than or equal to the checkpoint SCN of the standby control file and that a log file containing the checkpoint SCN is available for recovery (as described in Section D.2.2).
   2. If desired, issue a SET command to specify the end time, SCN, or log sequence number for incomplete recovery.
   3. If automatic channels are not configured, then manually allocate at least one auxiliary channel.
   4. Specify new filenames for the standby database datafiles.
   5. Issue the DUPLICATE command with the DORECOVER option.

   For example, enter the following at the RMAN prompt to use a configured channel to create the standby database:

   # If desired, issue a LIST command to determine the SCN of the standby 
   control file.
   # The SCN to which you recover must be greater than or equal to the control 
   file SCN.
   
   LIST BACKUP OF CONTROLFILE;
   LIST COPY OF CONTROLFILE;
   RUN
   {
     # If desired, issue a SET command to terminate recovery at a specified 
   point.
     # SET UNTIL TIME 'SYSDATE-7';
   
     # Set new filenames for the datafiles
     SET NEWNAME FOR DATAFILE 1 TO '?/dbs/standby_data_01.f'; 
     SET NEWNAME FOR DATAFILE 2 TO '?/dbs/standby_data_02.f'; 
     .
     .
     .
     DUPLICATE TARGET DATABASE FOR STANDBY
       DORECOVER;
   }
   
   

   RMAN uses all incremental backups, archived redo log file backups, and archived redo log files to perform incomplete recovery. The standby database is left mounted.

D.5.3 Naming Standby Database Files with CONFIGURE AUXNAME

In this procedure, you use CONFIGURE AUXNAME commands to name the standby datafiles.

D.5.3.1 Creating the Standby Database Without Performing Recovery

To create the standby database without performing recovery, do not specify the DORECOVER option on the DUPLICATE command. By default, RMAN leaves the standby database mounted and does not recover it.

To use CONFIGURE AUXNAME to name standby database files without performing recovery:

1. Follow the steps in Section D.3. Make sure to set all necessary parameters in the standby initialization parameter file.
2. Configure the auxiliary names for the datafiles. For example, enter:

   # set auxiliary names for the datafiles     
   CONFIGURE AUXNAME FOR DATAFILE 1 TO '/oracle/auxfiles/aux_1.f'; 
   CONFIGURE AUXNAME FOR DATAFILE 2 TO '/oracle/auxfiles/aux_2.f'; 
   .
   .
   .
   CONFIGURE AUXNAME FOR DATAFILE n TO '/oracle/auxfiles/aux_n.f'; 
   
   

3. Run the DUPLICATE command. If automatic channels are not configured, manually allocate at least one auxiliary channel before issuing the DUPLICATE command, as in the following example:

   RUN
   {
     # allocate at least one auxiliary channel of type DISK or sbt 
     ALLOCATE AUXILIARY CHANNEL standby1 DEVICE TYPE sbt; 
     .
     .
     .
     # issue the DUPLICATE command
     DUPLICATE TARGET DATABASE FOR STANDBY;
   }
   
   

4. Unspecify the auxiliary names for the datafiles so that they are not overwritten by mistake. For example, enter the following at the RMAN prompt:

   # 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; 
   

D.5.3.2 Creating the Standby Database and Performing Recovery

To create the standby database and perform recovery, specify the DORECOVER option on the DUPLICATE command.

To use CONFIGURE AUXNAME to name standby files and perform recovery:

1. Follow the steps in Section D.3. Make sure to set all necessary parameters in the standby initialization parameter file.
2. Set the auxiliary names for the datafiles. For example, enter the following:

   # set auxiliary names for the datafiles     
   CONFIGURE AUXNAME FOR DATAFILE 1 TO '/oracle/auxfiles/aux_1.f'; 
   CONFIGURE AUXNAME FOR DATAFILE 2 TO '/oracle/auxfiles/aux_2.f'; 
   .
   .
   .
   CONFIGURE AUXNAME FOR DATAFILE n TO '/oracle/auxfiles/aux_n.f'; 
   
   

3. Run the DUPLICATE command. Follow these steps:
   • Ensure the end recovery time is greater than or equal to the checkpoint SCN of the standby control file and that a log file containing the checkpoint SCN is available for recovery (as described in Section D.2.2).
   • If desired, issue a SET command to specify the end time, SCN, or log sequence number for incomplete recovery.
   • If automatic channels are not configured, then manually allocate at least one auxiliary channel.
   • Issue the DUPLICATE TARGET DATABASE for standby command.

   For example, enter the following at the RMAN prompt to use a configured channel to create the standby database:

   # If desired, issue a LIST command to determine the SCN of the standby 
   control file.
   # The SCN to which you recover must be greater than or equal to the control 
   file SCN.
   LIST BACKUP OF CONTROLFILE;
   LIST COPY OF CONTROLFILE;
   
   DUPLICATE TARGET DATABASE FOR STANDBY
     DORECOVER;
   
   

   RMAN uses all incremental backups, archived redo log file backups, and archived redo log files to perform incomplete recovery. The standby database is left mounted.

4. Clear the auxiliary name settings for the datafiles so that they are not overwritten by mistake. For example, enter the following at the RMAN prompt:

   # 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; 
   

D.6 Creating a Standby Database on the Local Host

When creating a standby database on the same host as the primary database, follow the same procedure as for duplicating to a remote host with a different directory structure as described in Section D.5.

Note the following restrictions when creating a standby database on the same host as the primary database:

• You can create the standby database in the same Oracle home as the target database, but you must convert the filenames with the same methods used for conversion on a separate host. That is, you must treat a standby database in the same Oracle home as if it were a database on a separate host with a different directory structure. You must not use the same names for standby and primary database files when the two databases are on the same machine.
• You must set the DB_UNIQUE_NAME initialization parameter on both databases.

  CAUTION: Do not use the NOFILENAMECHECK option when creating the standby database in the same Oracle home as the primary database. If you do, then you may overwrite the target database files or cause the DUPLICATE command to fail with an error.

D.7 Creating a Standby Database with Image Copies

This section contains these topics:

• Overview
• When Copies and Datafiles Use the Same Names
• When Copies and Datafiles Use Different Names

D.7.1 Overview

The main restriction when using RMAN image copies to create the standby datafiles is that the image copy filenames for datafiles and archived redo log files on the primary and standby hosts must be the same. For example, assume that datafile 1 is named /oracle/dbs/df1.f on the primary host. If you use the RMAN COPY command to copy this datafile to /data/df1.f, then this image copy must exist on the standby host with the same filename of /data/df1.f. Otherwise, RMAN cannot locate the metadata for the standby image copy in its repository.

You have two main ways of populating the standby host with the image copies:

• Transferring them manually with ftp or some other utility
• Mounting the standby directory structure on the primary host with a network file system (NFS)

When you use the NFS method, you can create a directory on the primary host that maps to a directory on the standby host. If you use this method, then the NFS mount point on both machines must have the same directory name. For example, you can map /data on the primary host to /data on the standby host, but you cannot map /data on the primary host to /dir on the standby host (unless you use functionality such as symbolic links in UNIX or logical drives on Windows NT).

The filename of the image copy on the standby host must be the same as the filename of the image copy on the primary host. Nevertheless, you can specify a different path name for the standby datafile by using SET NEWNAME commands or the DB_FILE_NAME_CONVERT initialization parameter.

For example, although the image copy of datafile 1 is named /data/df1.f on the standby host, you can specify the path name /oracle/sb/df1.f in the standby control file by using initialization parameters or RMAN commands. Note that you do not manually rename the physical image copy. When you run the DUPLICATE command, RMAN restores the image copy /data/df1.f and creates the standby datafile 1 as /oracle/sb/df1.f based on the information in the initialization parameters or RMAN commands.

Table D-3 illustrates two scenarios for using NFS to create a standby database with one datafile.

Table D-3  Using Image Copies to Create a Standby Database: Scenario

NFS Mount Point	Primary Datafile Filename	Image Copy Filename	Standby Datafile Filename	Procedure
/data (same on both hosts)	/oracle/dbs/df1.f	/data/df1.f	/data/df1.f (same path name as image copy)	See Section D.7.2, "When Copies and Datafiles Use the Same Names"
/data (same on both hosts)	/oracle/dbs/df1.f	/data/df1.f	/oracle/sb/df1.f (different path name from image copy)	See Section D.7.3, "When Copies and Datafiles Use Different Names"

Table D-3 assumes that the standby directory structure is mounted on the primary host, and that the mount point is /data on both hosts. Because the primary host mounts the standby host directory structure, when you create the image copy /data/df1.f on the primary host, you are actually creating the image copy /data/df1.f on the standby host.

In the first scenario, you name the standby datafiles with the same filenames as the image copies. This case is the simplest because you do not need to use RMAN at all to create the standby database. First, set the DB_FILE_NAME_CONVERT parameter in the standby initialization parameter file to convert the primary datafile filename /oracle/dbs/df1.f to the standby filename /data/df1.f. Then, copy the files to the standby host, and mount the standby database.

In the second scenario, you use different filenames for the standby datafiles and the image copies. To create this standby database, run the DUPLICATE command. The DUPLICATE command restores the image copy of datafile 1 and renames it according to either the SET NEWNAME commands or the DB_FILE_NAME_CONVERT initialization parameter.

D.7.2 When Copies and Datafiles Use the Same Names

This procedure assumes that you are using the same filenames for the standby datafiles and the image copies of the primary datafiles.

To create a standby database when the copies and standby datafiles have the same names:

1. After connecting to the primary database, and if desired, the recovery catalog database, mount but do not open the primary database and ensure the database was closed cleanly before mounting. For example, enter:

   RMAN> STARTUP MOUNT PFILE=init.ora;
   
   

2. Make sure that you set DB_FILE_NAME_CONVERT in the standby initialization parameter file so that standby datafile filenames are translated from the primary datafile filenames. For example:

   DB_FILE_NAME_CONVERT = '/oracle/dbs', '/dsk2/oracle'
   
   

3. Copy all of the datafiles and the standby control file. For example, enter:

   COPY 
     DATAFILE 1 TO '/dsk2/oracle/df_1.f',
     DATAFILE 2 TO '/dsk2/oracle/df_2.f',
     DATAFILE 3 TO '/dsk2/oracle/df_3.f',
     DATAFILE 4 to '/dsk2/oracle/df_4.f',
     DATAFILE 5 TO '/dsk2/oracle/df_5.f',
     DATAFILE 6 TO '/dsk2/oracle/df_6.f',
     DATAFILE 7 TO '/dsk2/oracle/df_7.f',
     DATAFILE 8 to '/dsk2/oracle/df_8.f',
     DATAFILE 9 TO '/dsk2/oracle/df_9.f',
     DATAFILE 10 TO '/dsk2/oracle/df_10.f',
     DATAFILE 11 TO '/dsk2/oracle/df_11.f',
     DATAFILE 12 to '/dsk2/oracle/df_12.f',
     CURRENT CONTROLFILE FOR STANDBY TO '/dsk2/oracle/cf.f';
   
   

4. Start the standby instance and mount the standby control file. For example, start SQL*Plus and enter:

   SQL> STARTUP NOMOUNT PFILE=/dsk2/oracle/dbs/initSTANDBY1.ora
   SQL> ALTER DATABASE MOUNT;
   

D.7.3 When Copies and Datafiles Use Different Names

This procedure assumes that you use different filenames for the standby datafiles and the image copies of the primary datafiles.

D.7.3.1 Creating the Standby Database Without Performing Recovery

To create the standby database without performing recovery, you do not need to run the DUPLICATE command. By default, RMAN leaves the standby database mounted and does not recover it.

To create a standby database when the copies and standby datafiles have different names without performing recovery:

1. Connect to the primary database, standby instance, and, if desired, the recovery catalog database. For example, enter:

   % rman TARGET sys/sys_pwd@prod1 AUXILIARY sys/sys_pwd@sbdb1 CATALOG 
   rman/cat@catdb
   
   

2. Mount but do not open the primary database and ensure the database was closed cleanly before mounting. For example, enter:

   STARTUP MOUNT PFILE=initPROD1.ora
   
   

3. Either set DB_FILE_NAME_CONVERT in the standby initialization parameter file so that standby datafile filenames are translated from the primary datafile filenames, or issue SET NEWNAME commands. For example, set the DB_FILE_NAME_CONVERT parameter as follows:

   DB_FILE_NAME_CONVERT = '/oracle/dbs', '/dsk2/oracle'
   
   

4. Use the COPY command to copy all of the datafiles and the standby control file. For example, issue the following commands:

   COPY 
     DATAFILE 1 TO '/dsk2/oracle/df_1.f',
     DATAFILE 2 TO '/dsk2/oracle/df_2.f',
     DATAFILE 3 TO '/dsk2/oracle/df_3.f',
     DATAFILE 4 to '/dsk2/oracle/df_4.f',
     DATAFILE 5 TO '/dsk2/oracle/df_5.f',
     DATAFILE 6 TO '/dsk2/oracle/df_6.f',
     DATAFILE 7 TO '/dsk2/oracle/df_7.f',
     DATAFILE 8 to '/dsk2/oracle/df_8.f',
     DATAFILE 9 TO '/dsk2/oracle/df_9.f',
     DATAFILE 10 TO '/dsk2/oracle/df_10.f',
     DATAFILE 11 TO '/dsk2/oracle/df_11.f',
     DATAFILE 12 to '/dsk2/oracle/df_12.f',
     CURRENT CONTROLFILE FOR STANDBY TO '/dsk2/oracle/cf.f';
   # To ensure the control file checkpoint is archived, archive the 
   # current redo log file
   SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT'; 
   
   

5. Start the auxiliary instance and mount the standby control file. For example, start SQL*Plus and enter:

   SQL> STARTUP MOUNT PFILE=/dsk2/oracle/dbs/initSTANDBY1.ora
   

D.7.3.2 Creating the Standby Database and Performing Recovery

To create the standby database and perform recovery, specify the DORECOVER option on the DUPLICATE command.

To create a standby database when the copies and standby datafiles have different names and perform recovery:

1. Connect to the primary database, standby instance, and, if desired, the recovery catalog database. For example, enter:

   % rman TARGET sys/sys_pwd@prod1 AUXILIARY sys/sys_pwd@sbdb1 CATALOG 
   rman/cat@catdb
   
   

2. Mount but do not open the primary database and ensure the database was closed cleanly before mounting. For example, enter:

   STARTUP MOUNT PFILE=initPROD1.ora
   
   

3. Either set DB_FILE_NAME_CONVERT in the standby initialization parameter file so that standby datafile filenames are translated from the primary datafile filenames, or issue SET NEWNAME commands. For example, set the DB_FILE_NAME_CONVERT parameter as follows:

   DB_FILE_NAME_CONVERT = '/oracle/dbs', '/dsk2/oracle'
   
   
   

4. Run the DUPLICATE command. Follow these steps:
   1. Ensure the end recovery time is greater than or equal to the checkpoint SCN of the standby control file and that a log file containing the checkpoint SCN is available for recovery (as described in Section D.2.2).
   2. If desired, issue a SET command to specify the end time, SCN, or log sequence number for recovery.
   3. If automatic channels are not configured, then manually allocate at least one auxiliary channel for the duplication.
   4. Copy every datafile and the standby control file.
   5. Archive the current online redo log files.
   6. Issue the DUPLICATE command with the DORECOVER option.

   For example, enter the following:

   COPY 
     DATAFILE 1 TO '/dsk2/oracle/df_1.f',
     DATAFILE 2 TO '/dsk2/oracle/df_2.f',
     DATAFILE 3 TO '/dsk2/oracle/df_3.f',
     DATAFILE 4 to '/dsk2/oracle/df_4.f',
     DATAFILE 5 TO '/dsk2/oracle/df_5.f',
     DATAFILE 6 TO '/dsk2/oracle/df_6.f',
     DATAFILE 7 TO '/dsk2/oracle/df_7.f',
     DATAFILE 8 to '/dsk2/oracle/df_8.f',
     DATAFILE 9 TO '/dsk2/oracle/df_9.f',
     DATAFILE 10 TO '/dsk2/oracle/df_10.f',
     DATAFILE 11 TO '/dsk2/oracle/df_11.f',
     DATAFILE 12 to '/dsk2/oracle/df_12.f',
     CURRENT CONTROLFILE FOR STANDBY TO '/dsk2/oracle/cf.f';
     SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT'; 
     DUPLICATE TARGET DATABASE FOR STANDBY
       DORECOVER;
   
   

   RMAN uses all incremental backups, archived redo log file backups, and archived redo log files to perform incomplete recovery. The standby database is left mounted.

D.8 Usage Scenario

In this scenario, you are performing a duplication that uses both backups and image copies of the primary datafiles. The scenario illustrates how RMAN is able to use both datafile backups and datafile copies for the standby files, and also is able to use both incremental backups and archived redo log files to recover the standby database.

Assume the following about the standby database environment:

• The primary database is on host1 and the standby database is on host2.
• Database prod1 has 30 datafiles: datafiles 1 through 25 are on a raw disk named with the pattern /dev/rdsk### (where ### is a number starting with 001 and ending with 025), and datafiles 26 through 30 are located in the /primary/datafile directory.

You perform the following actions over the course of a week:

1. On Monday, you run the following incremental level 0 database backup:

   BACKUP DEVICE TYPE sbt INCREMENTAL LEVEL 0 DATABASE PLUS ARCHIVELOG;
   
   

2. On Tuesday, copy datafiles 1 through 5 into the /standby/datafile directory on host1, then run the BACKUP ARCHIVELOG ALL command.
3. On Wednesday, copy datafiles 6 through 9 into the /standby/datafile directory on host1, then run the BACKUP ARCHIVELOG ALL command.
4. On Thursday, run the following incremental level 1 database backup:

   BACKUP DEVICE TYPE sbt INCREMENTAL LEVEL 1 DATABASE PLUS ARCHIVELOG;
   
   

5. On Friday, copy datafiles 10 through 15 into the /standby/datafile directory on host1, then run the BACKUP ARCHIVELOG ALL command.
6. On Saturday morning, run the following RMAN commands:

   COPY CURRENT CONTROLFILE FOR STANDBY TO '/standby/datafile/cf.f';
   SQL 'ALTER SYSTEM ARCHIVELOG CURRENT';
   BACKUP DEVICE TYPE sbt ARCHIVELOG ALL;
   
   

7. On Saturday night, ftp all the image copies in /standby/datafile on host1 to /standby/datafile on host2, and also ftp all the log files on host1 to host2; also make the tape backups of prod1 accessible to host2.

On Sunday, you decide to create the standby database and recover it up to the point of the Saturday backup. You want all the standby datafiles to be located in the /standby/datafile directory on host2.

You must choose a method for naming the standby datafiles. You could use the DB_FILE_NAME_CONVERT parameter to change each pattern of the raw disk datafiles, which would require 25 pairs of values in the parameter (one pair for each raw disk filename that is being renamed). Instead, you decide to use SET NEWNAME commands for the 25 datafiles on raw disk, and use the DB_FILE_NAME_CONVERT parameter only for converting the names for the five datafiles in /primary/datafile to /standby/datafile.

The image copies are located in /standby/datafile on host2, but you only made copies of datafiles 1 through 15. This is not a problem, however, because you have incremental backups of all the datafiles. RMAN always chooses to restore image copies over backups, but if no image copies are available, then RMAN restores backups. So, you run the following script:

RUN
{
  # run SET NEWNAME commands for datafiles 1-25
  SET NEWNAME FOR DATAFILE 1 TO '/standy/datafile/df1.f';
  SET NEWNAME FOR DATAFILE 2 TO '/standby/datafile/df2.f';
  .
  .
  .
  SET NEWNAME FOR DATAFILE 25 TO '/standby/datafile/df25.f';
  DUPLICATE TARGET DATABASE FOR STANDBY DORECOVER;
}

RMAN does the following actions during the duplication:

• Uses the image copies of datafiles 1 through 15.
• Restores the backups of datafiles 16 through 30 (because no image copies are available of these datafiles).
• Uses incremental backups to recover datafiles 1 through 9 and datafiles 16 through 30, but not to recover datafiles 10 through 15 because these copies were created on Friday after the Thursday incremental level 1 backup.
• Restores and applies archived redo log files as needed to datafiles 1 through 30 up to the last archived redo log file that was backed up.
• Applies archived redo log files on disk up to the last archived redo log file.