Skip Headers

Oracle9i Recovery Manager User's Guide
Release 2 (9.2)
Part Number A96566-01
Go To Documentation Library
Home		 Go To Product List
Book List		 Go To Table Of Contents
Contents		 Go To Index
Index
Master Index
Feedback

Go to previous page Go to next page

13
Creating a Standby Database with Recovery Manager

This chapter describes how to create a standby database using RMAN. This chapter contains these topics:

Preparing a Standby Database with RMAN

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 "Creating a Duplicate Database on a Local or Remote Host" to account for the issues specific to a standby database.

The documentation for the preparation and maintenance of standby databases is located in Oracle9i Data Guard Concepts and Administration. Familiarize yourself with what a standby database is and how to create one before you attempt the RMAN creation procedures in this chapter.

This section contains these topics:

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 13-1.

Table 13-1 Standby Database Preparation Using RMAN
Task Procedure

Make a backup of the primary database to use for creation of standby database.

Use the normal backup procedure for your primary database as documented in Oracle9i Recovery Manager User's Guide.

Create a backup of the primary control file that is usable as a standby control file (if you do not have one).

"Creating the Standby Control File with RMAN"

Choose filenames for the standby datafiles.

"Naming the Standby Database Datafiles When Using RMAN"

Choose filenames for the standby database online redo logs.

"Naming the Standby Database Online Redo Logs When Using RMAN"

You cannot use RMAN to perform all necessary standby database preparation. You must manually perform these tasks:

Creating the Standby Control File with RMAN

In releases prior to release 8.1.7, you were required to create the standby control file with the SQL ALTER DATABASE statement. Now, you can use RMAN to make a special backup of the primary database control file that is usable as a standby database control file.

By using RMAN, you can create a standby control file in any of the ways described in the following sections:

Creating the Standby Control File with the BACKUP Command

You have these options for creating the standby control file with the BACKUP command:

To create a backup set containing only a standby control file:

  1. Connect to the primary database and, if desired, the recovery catalog database. For example, enter: 
    % rman TARGET SYS/oracle@trgt CATALOG rman/cat@catdb
  2. Mount or open the primary database. For example, enter: 
    STARTUP MOUNT
  3. Create the standby control file with the BACKUP CURRENT CONTROLFILE FOR STANDBY command. This example uses a configured channel to create the standby control file, then archives all unarchived logs and backs up any logs that have not yet been backed up at least once: 
    BACKUP CURRENT CONTROLFILE FOR STANDBY;
SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT';  # so backup is consistent and recoverable
BACKUP ARCHIVELOG ALL NOT BACKED UP 1 TIMES;

    You cannot specify a tag for a standby control file.

  4. If desired, issue a LIST command to see a listing of backup sets and pieces.

To include the standby control file within another backup:

  1. Connect to the primary database and, if desired, the recovery catalog database. For example, enter: 
    % rman TARGET SYS/oracle@trgt CATALOG rman/cat@catdb
  2. Back up the primary database and include a standby control file in the primary database backup. This example backs up all the primary datafiles to disk and also creates the standby control file: 
    BACKUP DATABASE
  INCLUDE CURRENT CONTROLFILE FOR STANDBY 
  PLUS ARCHIVELOG;

    Note that PLUS ARCHIVELOG is specified so that RMAN will archive all unarchived logs before and after running BACKUP ARCHIVELOG ALL. If you do not specify PLUS ARCHIVELOG, you should run the following command after the backup of the database:

    SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT';
  3. Issue a LIST command to see a listing of backup sets and pieces.

Creating the Standby Control File with the COPY Command

You can create a standby control file by using the COPY CURRENT CONTROLFILE command with the FOR STANDBY option.

To create a control file copy that is usable as a standby control file:

  1. Connect to the primary database and, if desired, the recovery catalog database. For example, enter: 
    % rman TARGET SYS/oracle@trgt CATALOG rman/cat@catdb
  2. 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, enter: 
    COPY CURRENT CONTROLFILE FOR STANDBY TO '/tmp/sby_control01.ctl';
  3. Issue a LIST COPY command to see a listing of image copies.

Creating the Standby Control File by Cataloging a SQL-Generated Control File

You can update the repository to include a standby control file that was generated with the ALTER DATABASE statement .

To catalog a standby control file generated with ALTER DATABASE:

  1. Create a standby control file with the SQL ALTER DATABASE statement (if you have not already created one). This example creates a standby control file by using SQL*Plus: 
    SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/tmp/sby_control01.ctl';
  2. Connect to the primary database and, if desired, the recovery catalog database. For example, enter: 
    % rman TARGET SYS/oracle@trgt CATALOG rman/cat@catdb
  3. run the CATALOG command to add metadata about the standby control file to the recovery catalog. For example, enter: 
    CATALOG CONTROLFILECOPY '/tmp/sby_control01.ctl';

    RMAN considers a control file generated with the ALTER DATABASE statement as a control file copy.

Making Image Copies of Standby Control Files

RMAN can make an image copy of a control file copy that was generated by either:

To copy an RMAN-generated control file copy or SQL-generated control file:

  1. Connect to the primary database and, if desired, the recovery catalog database. For example, enter: 
    % rman TARGET SYS/oracle@trgt CATALOG rman/cat@catdb
  2. Copy the standby control file with the COPY CONTROLFILECOPY command. For example, run the following command: 
    COPY CONTROLFILECOPY '/tmp/sby_control01.ctl' TO '/backup/sby_control01.ctl';
    Note:

    RMAN treats SQL-generated control files and RMAN-generated standby control file copies exactly the same. It inspects the header of the control file and determines whether it is a standby or a normal control file.
  3. Issue a LIST COPY command to see a listing of image copies.

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 whether 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 cannot exist in the same directories as the primary database 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:

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

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 13-2 specifies the hierarchy for the naming of datafiles in the standby database.

Table 13-2 Order of Precedence for Naming Datafiles in Standby Database
Method of Standby Datafile Naming Requirement

1

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.

2

Issue SET NEWNAME command.

You must issue this command in the RUN block for the creation of the standby database.

3

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 Also:

Oracle9i Data Guard Concepts and Administration for more information about how to use DB_FILE_NAME_CONVERT to name standby files

Naming the Standby Database Online Redo Logs When Using RMAN

RMAN does not create the online redo logs when it creates the standby database. Online redo logs are not created on the standby database by RMAN. However, as described in Oracle9i Data Guard Concepts and Administration, the online logs can be created by other actions that you perform on the standby database. After the online logs are created, they are maintained and archived according to the normal rules for online redo logs.

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

Note these restrictions when specifying filenames for the standby online redo logs:

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 Oracle9i Data Guard Concepts and Administration. Do not attempt these procedures until you have made all necessary initialization parameter settings and network configuration.

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 attempt to register the standby database in the repository for the primary database.

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

See Also:

Chapter 12, "Duplicating a Database with Recovery Manager" to learn how to use DUPLICATE to create a duplicate database that is not a standby database

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.

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 "RMAN Standby Creation Without Recovery". Instead of step 6, it performs these steps:

  1. After all data is restored, RMAN begins media recovery. If recovery requires archived redo logs, and if the logs have the status AVAILABLE in the repository, then RMAN attempts to apply them. Note that if logs marked AVAILABLE do not actually exist on disk, then RMAN returns an error. If a log that is not marked AVAILABLE is required, then RMAN attempts to restore it.
  2. RMAN recovers the standby database to the specified time, system change number (SCN), or log sequence number, or to the latest archived redo log 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. Oracle9i Data Guard Concepts and Administration 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:

One way to ensure that 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 logs of the primary database. Then, either back up the most recent archived log with RMAN or move the archived log to the standby site.

Whether or not you perform recovery, RMAN does not activate the standby database after creating it. The only way to activate a standby database is to issue the ALTER DATABASE ACTIVATE STANDBY DATABASE statement. After a standby database is activated and the redo logs are reset, all backups and archived logs of the old primary database are invalid for the new incarnation of the database.

Note:

The procedures in this chapter assume that you are using RMAN backups to create the standby database. If you are using RMAN image copies, then refer to "Creating a Standby Database with Image Copies".
See Also :

Starting RMAN and 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 the standby and primary sites have a different directory structure.

To start the standby instance:

  1. Use an operating system utility to copy 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 Oracle9i Data Guard Concepts and Administration. 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 online redo logs 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%t_%s.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

    If you use a recovery catalog, then make sure that the 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 that you can establish a connection to the standby instance. Note that you must connect to the auxiliary 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

Creating a Standby Database on a Remote Host 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 logs have the same filenames.

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 "Starting RMAN and the Standby Instance". 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 logs have the same names. Otherwise, RMAN issues an error.

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

    DUPLICATE TARGET DATABASE FOR STANDBY 
  NOFILENAMECHECK;

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 "Starting RMAN and the Standby Instance". 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 that the end recovery time is greater than or equal to the checkpoint SCN of the standby control file and that a log 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 log backups, and archived logs to perform incomplete recovery. The standby database is left mounted.

Creating a Standby Database on a Remote Host 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 online redo logs. You can do the following:

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

In this procedure, you use DB_FILE_NAME_CONVERT to name the standby datafiles and LOG_FILE_NAME_CONVERT to name the standby online redo logs.

See Also:

Oracle9i Data Guard Concepts and Administration for examples of how to use the DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT parameters to name standby database files

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 "Starting RMAN and the Standby Instance". 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.

Creating the Standby Database and Performing Recovery

After using DB_FILE_NAME_CONVERT to name the standby datafiles and LOG_FILE_NAME_CONVERT to name the standby online redo logs, 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 "Creating the Standby Database and Performing Recovery" .

Naming Standby Database Files with SET NEWNAME Commands

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

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 "Starting RMAN and the Standby Instance". Make sure to set all necessary parameters in the standby initialization parameter file.
  2. Run the DUPLICATE command. Perform the following operations:
    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;
}

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 "Starting RMAN and the Standby Instance". Make sure to set all necessary parameters in the standby initialization parameter file.
  2. Run the DUPLICATE command. Follow these steps:
    1. Ensure that the end recovery time is greater than or equal to the checkpoint SCN of the standby control file and that a log containing the checkpoint SCN is available for recovery (as described in "RMAN Standby Creation with 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 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 backups, and archived redo logs to perform incomplete recovery. The standby database is left mounted.

Naming a Standby Database Files with CONFIGURE AUXNAME Commands

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

See Also:

"Duplicating By Using CONFIGURE AUXNAME"

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 "Starting RMAN and the Standby Instance". 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;

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 "Starting RMAN and the Standby Instance". 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 that the end recovery time is greater than or equal to the checkpoint SCN of the standby control file and that a log containing the checkpoint SCN is available for recovery (as described in "RMAN Standby Creation with Recovery").
    • 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 backups, and archived redo logs 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;

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 "Creating a Standby Database on a Remote Host with a Different Directory Structure".

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

Creating a Standby Database with Image Copies

This section contains these topics:

Creating a Standby Database with Image Copies: Overview

The main restriction when using RMAN image copies to create the standby datafiles is that the image copy filenames for datafiles and archived logs 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:

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 13-3 illustrates two scenarios for using NFS to create a standby database with one datafile.

Table 13-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)

"Creating the Standby Database 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)

"Creating the Standby Database When Copies and Datafiles Use Different Names"

Table 13-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.

Creating the Standby Database 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 that the database was closed cleanly prior to 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 auxiliary 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 STANDBY DATABASE;

Creating the Standby Database 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.

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 that the database was closed cleanly prior to 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, run 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 that the control file checkpoint is archived, archive the current
# redo log
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 NOMOUNT PFILE=/dsk2/oracle/dbs/initSTANDBY1.ora
SQL> ALTER DATABASE MOUNT STANDBY DATABASE;

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 that the database was closed cleanly prior to 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 that the end recovery time is greater than or equal to the checkpoint SCN of the standby control file and that a log containing the checkpoint SCN is available for recovery (as described in "RMAN Standby Creation with Recovery").
    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 redo logs.
    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 backups, and archived redo logs to perform incomplete recovery. The standby database is left mounted.

Creating a Standby Database with Backups and Image Copies: 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 logs to recovery the standby database.

Assume the following about the standby database environment:

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, you copy datafiles 1 through 5 into the /standby/datafile directory on host1, then run BACKUP ARCHIVELOG ALL
  3. On Wednesday, you copy datafiles 6 through 9 into the /standby/datafile directory on host1, then run BACKUP ARCHIVELOG ALL
  4. On Thursday, you run the following incremental level 1 database backup: 
    BACKUP DEVICE TYPE sbt INCREMENTAL LEVEL 1 DATABASE PLUS ARCHIVELOG;
  5. On Friday, you copy datafiles 10 through 15 into the /standby/datafile directory on host1, then run BACKUP ARCHIVELOG ALL
  6. On Saturday morning, you 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, you ftp all the image copies in /standby/datafile on host1 to /standby/datafile on host2, and also ftp all the logs on host1 to host2; you 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 DB_FILE_NAME_CONVERT to change each pattern of the raw disk datafiles, which would require twenty-five 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 twenty-five datafiles on raw disk, and use DB_FILE_NAME_CONVERT 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:

Go to previous page Go to next page
Oracle
Copyright © 1996, 2002 Oracle Corporation.
All Rights Reserved.
Go To Documentation Library
Home		 Go To Product List
Book List		 Go To Table Of Contents
Contents		 Go To Index
Index
Master Index
Feedback