Oracle® Data Guard Concepts and Administration 10g Release 2 (10.2) Part Number B14239-04 |
|
|
View PDF |
This appendix describes how to use Oracle Recovery Manager to create a standby database. This appendix contains the following topics:
Creating a Standby Database with the Same Directory Structure
Creating a Standby Database with a Different Directory Structure
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 databases.
RMAN automates renaming of files including Oracle Managed Files (OMF), and 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 standby database in Chapter 3, "Creating a Physical Standby Database" and Chapter 4, "Creating a Logical Standby Database" before you attempt the RMAN creation procedures described in this chapter.
This section contains these topics:
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 F-1.
Table F-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 F.1.2, "Creating the Standby Control File with RMAN". |
Choose file names for the standby datafiles. |
See Section F.1.3, "Naming the Standby Database Datafiles When Using RMAN". |
Choose file names for the standby database archived redo log files and standby redo log files. |
See Section F.1.4, "Naming the Standby Database Log Files When Using RMAN". |
In addition to the RMAN tasks described in Table F-1, you must perform the following tasks to set up your standby database:
Set all necessary initialization parameters on the primary database.
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.
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 1 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.
Note:
If you already created a standby control file with the SQLALTER DATABASE CREATE STANDBY CONTROLFILE AS
statement, you can use the RMAN CATALOG
command to add metadata about the standby control file to the recovery catalog:
CATALOG CONTROLFILECOPY '/tmp/sby_control01.ctl';
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 file names the same as the primary file names (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 file names in the standby control file in multiple ways, a method for prioritizing settings is necessary. Table F-2 specifies the hierarchy for the naming of datafiles in the standby database.
Table F-2 Order of Precedence for Naming Datafiles in Standby Database
See Oracle Database Reference for more information about how to use DB_FILE_NAME_CONVERT
to name files on a standby database.
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 file names for the log files, as specified in the standby control file. If the log file names on the standby must be different from the primary file names, then one option is to specify file names for the redo logs by setting LOG_FILE_NAME_CONVERT
in the standby initialization parameter file.
Note these restrictions when specifying file names 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 file names for the redo log files.
If you want the redo log file names on the standby database to be the same as the primary redo log file names, 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.
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 use 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, issue the Recovery Manager DUPLICATE
...
FOR
STANDBY
command to create the standby database using 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 the following;
Whether or not you specify that RMAN should recover the standby database after creating it
Whether or not you use Oracle Managed Files (OMF)
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.
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:
RMAN establishes connections both to the primary and standby databases, and the recovery catalog (if used).
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.
If you use a media manager, then RMAN contacts the media manager on the standby host to request the backup data.
RMAN restores the standby control file to the standby host, thereby creating the standby control file.
RMAN restores the primary datafile backups and copies to the standby host, thereby creating the standby database datafiles.
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.
If you do specify the DORECOVER
option of the DUPLICATE
command, then RMAN performs the same Steps 1-5 in Section F.2.1. Instead of Step 6, it performs these steps:
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.
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.
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.
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 Section F.7.See Oracle Database Backup and Recovery Reference for t
he list of DUPLICATE
restrictions for creating a standby database with RMAN.
No matter which standby creation scenario you choose, you must first start the standby database and then connect RMAN to this database. The details of this procedure vary depending on whether or not the standby and primary systems have a different directory structure, and whether or not Oracle Managed Files (OMF) is used:
Setting Up a Standby Database When Files Are Not Oracle Managed Files
Setting Up a Standby Database When All Files Are Oracle Managed Files
Setting Up a Standby Databases When a Subset of Files Are Oracle Managed Files
Perform the following steps to set up a standby database that does not use OMF:
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's 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 these initialization parameters:
Those 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'
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
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
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.
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
If the standby database uses OMF for all files, you must set the following parameters on the standby database or auxiliary instance before you perform the RMAN duplication. Oracle recommends using a server parameter file (SPFILE) when the database control files are OMF files. Otherwise, at end of the following procedure, be sure to update the CONTROL_FILE
initialization parameter with the value of the control file names column in V$CONTROLFILE
view.
Required initialization parameter changes:
Set up a different DB_NAME
parameter for duplicate databases and a different DB_UNIQUE_NAME
parameter for standby databases
Do not set the LOG_FILE_NAME_CONVERT
and DB_FILE_NAME_CONVERT
parameters
Do not set the CONTROL_FILE
parameter (if the database control files are to be OMF files)
Set the DB_CREATE_FILE_DEST
parameter (all datafiles, control file and online redo log will be created in this destination)
Set the STANDBY_FILE_MANAGEMENT
=AUTO
parameter (for standby database duplication only)
You can use the ALTER SYSTEM RESET
statement to clear initialization parameters in the SPFILE for steps 2 and 3. For example:
ALTER SYSTEM RESET CONTROL_FILE SCOPE=SPFILE SID='*'
Optional initialization parameter changes:
Set the DB_CREATE_FILE_DEST
parameter to create one copy of the control file and one member of the online redo log. To create more than one control file and online redo log file, set the DB_CREATE_ONLINE_LOG_DEST_
n
(where n
can be an integer from 1 to 5) parameter, depending on the number of multiplexed copies you require. The control file and online redo log files are not created in DB_CREATE_FILE_DEST
when one DB_CREATE_ONLINE_LOG_DEST_
n
parameter is set. For example, if you set DB_CREATE_ONLINE_LOG_DEST_
1
and DB_CREATE_ONLINE_LOG_DEST_2
, then you will get two copies of the control file and online redo log file on each destination.
If only some of the primary database files are OMF files, or if there are datafiles spread across more than one disk group, you may want to create a duplicate database with exactly the same structure.
For example, fast datafiles may reside in +'FAST'
disk group and slow datafiles may reside in '+SLOW'
disk group. After duplicating the database, you would like to have its datafiles reside in '+FAST2'
disk group and its slow datafiles reside in '+SLOW2'
disk group. To set up the standby database, configure the LOG_FILE_NAME_CONVERT
and DB_FILE_NAME_CONVERT
parameters as ('+FAST'
, '+FAST2'
, '+SLOW'
, '+SLOW2'
). If you want the database to be in the same disk group but with a different name, then change the middle part of the name. For example, use ('/boston/', '/sfo/'
) where boston
is the DB_UNIQUE_NAME
of the primary database and sfo
is the DB_UNIQUE_NAME
of the duplicate database.Use the following steps to set initialization parameters on the standby database or auxiliary instance before performing the RMAN duplication.
Required initialization parameter changes:
Set up a different DB_NAME
parameter for duplicate database and a different DB_UNIQUE_NAME
for standby database
Set up the LOG_FILE_NAME_CONVERT
and DB_FILE_NAME_CONVERT
parameters to convert file names
Modify the CONTROL_FILE
parameter to specify new control files
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 file names for the standby datafiles. The primary and standby datafiles and log files have the same file names.
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:
Follow the steps in Section F.3, "Setting Up the Standby Database". Make sure to set all necessary parameters in the standby initialization parameter file.
Follow these steps during duplication to create but not recover the standby datafiles:
If automatic channels are not configured, then allocate at least one auxiliary channel. This channel performs the work of duplication.
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;
To create the standby database and perform recovery, specify the DORECOVER
option on the DUPLICATE
command.
To create a standby database and perform recovery:
Follow the steps in Section F.3. Make sure to set all necessary parameters in the standby initialization parameter file.
Follow these steps to restore and recover the standby datafiles:
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.
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.
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.
If you create the standby database on a host with a different directory structure, you need to specify new file names 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:
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.
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.4 for examples of how to use the DB_FILE_NAME_CONVERT
and LOG_FILE_NAME_CONVERT
parameters to name standby database files.
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:
Follow the steps in Section F.3. Make sure to set all necessary parameters in the standby initialization parameter file.
Run the DUPLICATE
command. For example, run the following:
DUPLICATE TARGET DATABASE FOR STANDBY;
After restoring the backups, RMAN leaves the standby database mounted.
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 F.4.2.
In this procedure, you use SET
NEWNAME
commands to name the standby datafiles.
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:
Follow the steps in Section F.3. Make sure to set all necessary parameters in the standby initialization parameter file.
Run the DUPLICATE
command. Perform the following steps:
If automatic channels are not configured, then manually allocate at least one auxiliary channel.
Specify new file names for the standby database datafiles with SET
NEWNAME
commands.
Issue the DUPLICATE
command.
The following example uses a configured channel to create the standby database:
RUN { # set new file names 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; }
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:
Follow the steps in Section F.3. Make sure to set all necessary parameters in the standby initialization parameter file.
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 F.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.
Specify new file names for the standby database datafiles.
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 file names 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.
In this procedure, you use CONFIGURE
AUXNAME
commands to name the standby datafiles.
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:
Follow the steps in Section F.3. Make sure to set all necessary parameters in the standby initialization parameter file.
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';
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; }
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;
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:
Follow the steps in Section F.3. Make sure to set all necessary parameters in the standby initialization parameter file.
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';
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 F.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.
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;
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 F.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 file names 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.
This section contains these topics:
The main restriction when using RMAN image copies to create the standby datafiles is that the image copy file names 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 file name 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).
The file name of the image copy on the standby host must be the same as the file name 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 F-3 illustrates two scenarios for using NFS to create a standby database with one datafile.
Table F-3 Using Image Copies to Create a Standby Database: Scenario
NFS Mount Point | Primary Datafile File Name | Image Copy File Name | Standby Datafile File Name | Procedure |
---|---|---|---|---|
(same on both hosts) |
|
|
(same path name as image copy) |
See Section F.7.2, "When Copies and Datafiles Use the Same Names" |
(same on both hosts) |
|
|
(different path name from image copy) |
See Section F.7.3, "When Copies and Datafiles Use Different Names" |
Table F-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 file names 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 file name /oracle/dbs/df1.f
to the standby file name /data/df1.f
. Then, copy the files to the standby host, and mount the standby database.
In the second scenario, you use different file names 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.
This procedure assumes that you are using the same file names 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:
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;
Make sure that you set DB_FILE_NAME_CONVERT
in the standby initialization parameter file so that standby datafile file names are translated from the primary datafile file names. For example:
DB_FILE_NAME_CONVERT = '/oracle/dbs', '/dsk2/oracle'
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';
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;
This procedure assumes that you use different file names for the standby datafiles and the image copies of the primary datafiles.
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:
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
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
Either set the DB_FILE_NAME_CONVERT
initialization parameter on the standby database so that standby datafile file names are translated from the primary datafile file names, or issue SET
NEWNAME
commands. For example, set the DB_FILE_NAME_CONVERT
parameter as follows:
DB_FILE_NAME_CONVERT = '/oracle/dbs', '/dsk2/oracle'
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';
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
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:
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
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
Either set DB_FILE_NAME_CONVERT
in the standby initialization parameter file so that standby datafile file names are translated from the primary datafile file names, or issue SET
NEWNAME
commands. For example, set the DB_FILE_NAME_CONVERT
parameter as follows:
DB_FILE_NAME_CONVERT = '/oracle/dbs', '/dsk2/oracle'
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 F.2.2).
If desired, issue a SET
command to specify the end time, SCN, or log sequence number for recovery.
If automatic channels are not configured, then manually allocate at least one auxiliary channel for the duplication.
Copy every datafile and the standby control file.
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.
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:
On Monday, you run the following incremental level 0 database backup:
BACKUP DEVICE TYPE sbt INCREMENTAL LEVEL 0 DATABASE PLUS ARCHIVELOG;
On Tuesday, copy datafiles 1 through 5 into the /standby/datafile
directory on host1
, then run the BACKUP
ARCHIVELOG
ALL
command.
On Wednesday, copy datafiles 6 through 9 into the /standby/datafile
directory on host1
, then run the BACKUP
ARCHIVELOG
ALL
command.
On Thursday, run the following incremental level 1 database backup:
BACKUP DEVICE TYPE sbt INCREMENTAL LEVEL 1 DATABASE PLUS ARCHIVELOG;
On Friday, copy datafiles 10 through 15 into the /standby/datafile
directory on host1
, then run the BACKUP
ARCHIVELOG
ALL
command.
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;
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 file name 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.