Release 3 (8.1.7)
Part Number A85455-01
 Library |
 Product |
 Contents |
 Index |
| Oracle8i Documentation Addendum Release 3 (8.1.7) Part Number A85455-01 |
|
This chapter describes new and changed features for RMAN in Oracle8i Release 3 (8.1.7). This chapter contains these topics:
The procedure for preparing a standby database using RMAN is basically the same as for preparing a duplicate database. The duplication procedure is documented in "Duplicating a Database with RMAN" from Oracle8i Recovery Manager User's Guide and Reference. Nevertheless, you need to amend the duplication procedure to account for the issues specific to a standby database.
The documentation for the preparation and maintenance of standby databases is located in Oracle8i Standby Database 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:
You can either use manual methods or the Recovery Manager DUPLICATE
command to create a standby 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 7-1.
| Task | Procedure |
|---|---|
|
Make a backup of the database to use for creation of standby database. |
Use normal backup procedure as documented in Oracle8i Recovery Manager User's Guide and Reference. |
|
Create a standby control file (if you do not have one). |
|
|
Choose filenames for the standby datafiles. |
|
|
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:
Oracle8i Standby Database Concepts and Administration for a complete discussion of standby database preparation, including initialization parameter settings. You must perform all necessary preparation tasks described in this document before RMAN can successfully create the standby database files and mount the standby database.
See Also :
In pre-8.1.7 releases, you were required to create the standby control file using the SQL ALTER DATABASE statement. Now, RMAN allows you to create the standby control file using an RMAN command.
Using RMAN, you can create a standby control file in any of the ways described in the following sections:
You have these options for creating the standby control file using the BACKUP command:
BACKUP CURRENT CONTROLFILE command with the FOR STANDBY option.
BACKUP ... INCLUDE CURRENT CONTROLFILE command with the FOR STANDBY option.
To create a backup set containing only a standby control file:
% rman TARGET / CATALOG rman/rman@rcat
To write the output to a log file, specify the file at startup. For example, enter:
% rman TARGET / CATALOG rman/rman@rcat LOG "/oracle/log/mlog.f"
RMAN> STARTUP MOUNT
BACKUP ... FOR STANDBY command. This example backs up the standby control file to tape:
RUN { ALLOCATE CHANNEL ch1 TYPE 'sbt_tape'; BACKUP CURRENT CONTROLFILE FOR STANDBY; }
You cannot specify a tag for a standby control file.
LIST command to see a listing of backup sets and pieces.
To include the standby control file within another backup:
% rman TARGET / CATALOG rman/rman@rcat
To write the output to a log file, specify the file at startup. For example, enter:
% rman TARGET / CATALOG rman/rman@rcat LOG /oracle/log/mlog.f
RUN { ALLOCATE CHANNEL ch1 TYPE DISK; BACKUP DATABASE INCLUDE CURRENT CONTROLFILE FOR STANDBY; }
LIST command to see a listing of backup sets and pieces.
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:
% rman TARGET / CATALOG rman/rman@rcat
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:
RUN { ALLOCATE CHANNEL ch1 TYPE DISK; # create standby control file by copying current control file of # target database COPY CURRENT CONTROLFILE FOR STANDBY TO '/oracle/backup/standbycf.f'; }
LIST COPY command to see a listing of image copies.
You can record a standby control file generated using the ALTER DATABASE statement in the repository.
To catalog a standby control file generated using ALTER DATABASE:
ALTER DATABASE statement. This example creates a standby control file in SQL*Plus:
SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/oracle/dbs/stbycf.f';
% rman TARGET / CATALOG rman/rman@rcat
CATALOG command to add metadata about the standby control file to the recovery catalog. For example, enter:
RMAN> CATALOG CONTROLFILECOPY '/oracle/dbs/stbycf.f';
RMAN considers a control file generated using ALTER DATABASE as a control file copy.
You can use RMAN to make an image copy of a control file copy that was generated using:
To copy an RMAN-generated control file copy or SQL-generated control file:
% rman TARGET / CATALOG rman/rman@rcat
COPY CONTROLFILECOPY command. 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.
For example, run the following command:
RUN { ALLOCATE CHANNEL ch1 TYPE DISK; # copy standby control file created using ALTER DATABASE COPY CONTROLFILECOPY '/oracle/dbs/sql_generated_cf.f' TO '/backup/standbycf_sql.f'; # copy standby control file created using RMAN COPY CONTROLFILECOPY '/oracle/dbs/rman _generated_cf.f' TO '/backup/standbycf_rman.f'; }
LIST COPY command to see a listing of image copies.
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.
When the directory structures are different for the primary and standby hosts, you have these options for naming the standby datafiles:
DB_FILE_NAME_CONVERT
SET AUXNAME or SET NEWNAME commands in RMAN when creating the standby database
When the directory structures are the same for the primary and standby hosts, then you have these naming options:
DB_FILE_NAME_CONVERT or issuing a SET AUXNAME or SET NEWNAME command) and specifying the NOFILENAMECHECK option of the DUPLICATE command
DB_FILE_NAME_CONVERT, SET AUXNAME, or SET NEWNAME to rename the standby datafiles
Because you can specify datafile filenames in the standby control file in multiple ways, a method for prioritizing settings is necessary. Table 7-2 specifies the hierarchy for the naming of datafiles in the standby database.
Until a standby database is opened read-only or activated, it does not have online redo logs. Because a standby database is updated through archived logs received from the primary database, the online logs are not needed. The online redo logs are created at standby activation, not standby creation. When you perform failover to a standby database, thereby making the standby database a primary database, Oracle accesses the standby control file to obtain the names for the online redo logs, and then creates them.
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 specify filenames for the online redo logs by setting LOG_FILE_NAME_CONVERT in the standby initialization parameter file. If you do not set this parameter, then the filenames in the standby control file for the online logs are the same as the log filenames in the primary database.
Note these restrictions when specifying filenames for the standby online redo logs:
LOG_FILE_NAME_CONVERT to name the online redo logs if the primary and standby databases use different naming conventions for the logs.
SET NEWNAME or SET AUXNAME to rename the online redo logs.
LOGFILE clause of the DUPLICATE command to specify filenames for the online redo logs.
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 section assume that you have already completed the standby setup and preparation as outlined in Oracle8i Standby Database Concepts and Administration. Do not attempt these procedures until you have made all necessary initialization parameter settings and network configuration.
This section contains these topics:
These procedures assume that you are using RMAN backups to create the standby database. If you are using RMAN image copies, then see "Using Image Copies to Create a Standby Database".
Note:
After you have performed the steps necessary for preparing the standby instance, use the Recovery Manager DUPLICATE command to create the standby database. The steps differ depending on whether you specify that RMAN should 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:
If you do specify the DORECOVER option of the DUPLICATE command, then RMAN automates these steps of the standby creation procedure during duplication:
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. Oracle8i Standby Database Concepts and Administration discusses gap sequence resolution in detail.
Note:
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 using 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.
|
See Also :
Oracle8i Standby Database Concepts and Administration to learn how to manage a standby database. |
For the complete list of DUPLICATE restrictions for creating a standby database using RMAN, see "DUPLICATE".
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:
_DEST and _PATH and specify a pathname
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_*
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
prod1 as SYS and start the database:
SQL> CONNECT SYS/sys_pwd@prod1 AS SYSDBA SQL> STARTUP PFILE=initPROD1.ora
If you use a recovery catalog, make sure that the catalog database is open. For example, enter the following to connect to rcat as SYS and start the database:
SQL> CONNECT SYS/sys_pwd@rcat AS SYSDBA SQL> STARTUP PFILE=initRCAT.ora
SYSDBA privileges, so a password file must exist.
% rman TARGET / AUXILIARY SYS/sys_pwd@sbdb1 NOCATALOG
In this example, the user SYS is on both the target and standby databases and has SYSDBA privileges. A net service name is used for the target as follows:
% rman AUXILIARY sys/sys_pwd@sbdb1 TARGET SYS/sys_pwd@prod1 NOCATALOG
In this example, RMAN connects to the primary, catalog, and auxiliary databases, all using net service names:
% rman CATALOG rman/rman@rcat TARGET SYS/sys_pwd@prod1 AUXILIARY SYS/sys_pwd@sbdb1
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.
To create a standby database on a different host with the same directory structure:
Follow these steps during the duplication to create but not recover the standby datafiles:
NOFILENAMECHECK option in the DUPLICATE command. The NOFILENAMECHECK option is required when the standby and primary datafiles and logs have identical filenames. Otherwise, RMAN signals an error.
For example, enter the following:
RUN { ALLOCATE AUXILIARY CHANNEL ch1 TYPE 'sbt_tape'; DUPLICATE TARGET DATABASE FOR STANDBY NOFILENAMECHECK; }
Follow these steps during duplication to restore and recover the standby datafiles:
SET command to specify the end time, SCN, or log sequence number for recovery.
NOFILENAMECHECK parameter in the DUPLICATE command, and use the DORECOVER option.
For example, enter the following at the RMAN prompt:
# 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; ALLOCATE AUXILIARY CHANNEL ch1 TYPE 'sbt_tape'; 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.
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:
LOG_FILE_NAME_CONVERT in the standby initialization parameter file to name the standby database online redo logs. If you do not set LOG_FILE_NAME_CONVERT, then you must use the NOFILENAMECHECK option of the DUPLICATE command.
DB_FILE_NAME_CONVERT in the standby initialization parameter file to name the standby datafiles.
SET NEWNAME command or the SET 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 Also:
SET NEWNAME and SET AUXNAME
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.
To create a standby database using parameters to name standby files:
After allocating one or more auxiliary channels, issue the DUPLICATE command. For example, enter the following:
RUN { ALLOCATE AUXILIARY CHANNEL ch1 TYPE 'sbt_tape'; DUPLICATE TARGET DATABASE FOR STANDBY; }
After restoring the backups, RMAN leaves the standby database mounted.
Follow these steps:
SET command to specify the end time, SCN, or log sequence number for recovery.
DUPLICATE command with the DORECOVER option.
For example, enter the following at the RMAN prompt:
# 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 LOGSEQ 612; ALLOCATE AUXILIARY CHANNEL ch1 TYPE 'sbt_tape'; 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.
In this procedure, you use SET NEWNAME commands to name the standby datafiles.
To create a standby database using the SET NEWNAME command:
Perform the following operations:
SET NEWNAME commands.
DUPLICATE command.
For example, enter the following:
RUN { # allocate at least one auxiliary channel of type DISK or 'sbt_tape' ALLOCATE AUXILIARY CHANNEL standby1 TYPE 'sbt_tape'; . . . # set new filenames for the datafiles SET NEWNAME FOR DATAFILE 1 TO '$ORACLE_HOME/dbs/standby_data_01.f'; SET NEWNAME FOR DATAFILE 2 TO '$ORACLE_HOME/dbs/standby_data_02.f'; . . . # issue the DUPLICATE command DUPLICATE TARGET DATABASE FOR STANDBY; }
RMAN uses all incremental backups, archived redo log backups, and archived redo logs to perform incomplete recovery.
Follow these steps:
SET command to specify the end time, SCN, or log sequence number for recovery.
DUPLICATE command with the DORECOVER option.
For example, enter the following at the RMAN prompt:
# 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'; ALLOCATE AUXILIARY CHANNEL ch1 TYPE 'sbt_tape'; # Set new filenames for the datafiles SET NEWNAME FOR DATAFILE 1 TO '$ORACLE_HOME/dbs/standby_data_01.f'; SET NEWNAME FOR DATAFILE 2 TO '$ORACLE_HOME/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.
In this procedure, you use SET AUXNAME commands to name the standby datafiles. See the chapter "Creating a Duplicate Database with Recovery Manager" in Oracle8i Recovery Manager User's Guide and Reference.
To create a standby database using the SET AUXNAME command:
# set auxiliary names for the datafiles SET AUXNAME FOR DATAFILE 1 TO '/oracle/auxfiles/aux_1.f'; SET AUXNAME FOR DATAFILE 2 TO '/oracle/auxfiles/aux_2.f'; ... SET AUXNAME FOR DATAFILE n TO '/oracle/auxfiles/aux_n.f';
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_tape' ALLOCATE AUXILIARY CHANNEL standby1 TYPE 'sbt_tape'; . . . # issue the DUPLICATE command DUPLICATE TARGET DATABASE FOR STANDBY; }
Follow these steps:
SET command to specify the end time, SCN, or log sequence number for recovery.
DUPLICATE TARGET DATABASE for standby command.
For example, enter the following at the RMAN prompt:
# 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 SCN 1000; ALLOCATE AUXILIARY CHANNEL ch1 TYPE 'sbt_tape'; 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.
# un-specify auxiliary names for the datafiles SET AUXNAME FOR DATAFILE 1 TO NULL; SET AUXNAME FOR DATAFILE 2 TO NULL; ... SET AUXNAME FOR DATAFILE n TO NULL;
When creating a standby database on the same host as the target database, follow the same procedure as for duplicating to a remote host with a different directory structure ("Creating a Standby Database on a Remote Host with a Different Directory Structure").
Note that you can create the standby database in the same Oracle home as the target database, but you must convert the filenames using the same methods used for conversion on a separate host. In other words, 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.
The main restriction when using RMAN image copies to create the standby datafiles is that the image copy filenames for datafiles and archived redo 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:
ftp or some other utility
When you use the NFS mount 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 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 pathname 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 pathname /oracle/sb/df1.f in the standby control file using initialization parameters or RMAN commands. Note that you do not manually rename the physical image copy. When you issue 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 7-3 illustrates two scenarios for creating a standby database with one datafile using NFS.
| 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 |
(same pathname as image copy) |
"Creating the Standby Database When Image Copies and Standby Datafiles Share the Same Filenames" |
|
/data (same on both hosts) |
/oracle/dbs/df1.f |
/data/df1.f |
(different pathname from image copy) |
"Creating the Standby Database When Image Copies and Standby Datafiles Do Not Share the Same Filenames" |
Table 7-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 using 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, use the DUPLICATE command. The DUPLICATE command restores the image copy of datafile 1 and renames it according to either SET NEWNAME commands or DB_FILE_NAME_CONVERT.
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:
% rman TARGET / CATALOG rman/rman@rcat
RMAN> STARTUP MOUNT PFILE=init.ora;
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')
RUN { ALLOCATE CHANNEL ch1 TYPE DISK; 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', CURRENT CONTROLFILE FOR STANDBY TO '/dsk2/oracle/cf.f'; }
SQL> STARTUP NOMOUNT PFILE=/dsk2/oracle/dbs/initSTANDBY1.ora SQL> ALTER DATABASE MOUNT STANDBY DATABASE;
This procedure assumes that you are using different 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 different names:
% rman TARGET / CATALOG rman/rman@rcat AUXILIARY sys/pwd@sbdb
RMAN> STARTUP MOUNT PFILE=init.ora
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')
Perform these steps:
DUPLICATE command.
For example, enter:
RUN { ALLOCATE CHANNEL ch1 TYPE DISK; ALLOCATE AUXILIARY CHANNEL ch2 TYPE DISK; 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', 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'; DUPLICATE TARGET DATABASE FOR STANDBY; }
Follow these steps:
SET command to specify the end time, SCN, or log sequence number for recovery.
DUPLICATE command with the DORECOVER option.
For example, enter the following:
RUN { ALLOCATE CHANNEL ch1 TYPE DISK; ALLOCATE AUXILIARY CHANNEL ch2 TYPE DISK; 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', 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.
This section contains these topics:
RMAN can back up the standby database and its associated archived redo logs. Standby backups of datafiles and archived redo logs are fully interchangeable with primary database backups. In other words, you can issue the RESTORE command to restore a backup of a standby datafile to the primary database, and you can restore a backup of a primary datafile to the standby database. The standby control file and primary control file, however, are not interchangeable.
Backing up standby files is often better than backing up the production files, for the following reasons:
If you activate a standby database using ALTER DATABASE ACTIVATE STANDBY DATABASE, then the standby database becomes the new primary database. Because a RESETLOGS must be performed at standby activation, RMAN creates a new incarnation record for the new primary database. Backups of this new incarnation of the primary database are not different from backups of the primary database after a RESETLOGS operation.
|
See Also:
"Opening the Database After Media Recovery" in "Chapter 5, Performing Media Recovery" from Oracle8i Backup and Recovery Guide to learn about |
Note these restrictions when making backups of a standby database:
DUPLICATE command on the standby database to create another standby database.
Oracle8i Standby Database Concepts and Administration for more information about backing up standby databases, and Oracle8i Recovery Manager User's Guide and Reference to learn how to make RMAN backups
See Also:
If you are making archived log backups on the standby site, you must ensure that all necessary archived logs are available on the primary site in the event of a failure. The situation can be confusing because archived logs can be:
The recovery catalog view RC_ARCHIVED_LOG indicates when an archived redo log is located at the primary site and when it is located at the standby site. This information is important because you need to know when you must back up a log or copy it to the primary site from the standby site.
For example, assume that you connect to the recovery catalog and issue this query:
SQL> SELECT SEQUENCE#, IS_STANDBY FROM RC_ARCHIVED_LOG; SEQUENCE# IS_ ---------- --- 113 YES 114 NO 115 NO 116 YES 116 NO 117 NO 118 NO 119 NO 120 NO
The IS_STANDBY column indicates whether the log is located at the standby site (YES) or at the primary site (NO). If the same log sequence number has IS_STANDBY set to both YES and NO, then the log is located at both the standby and primary sites. For example, sequence number 116 has both a YES and NO value for IS_STANDBY, so it is at the primary and standby sites.
To understand how an archived log can be located at both sites, assume that you have a primary database, a recovery catalog database, and a standby database in managed recovery mode. The following sequence of events occurs:
RUN { ALLOCATE CHANNEL c1 TYPE 'sbt_tape'; BACKUP ARCHIVELOG ALL DELETE INPUT; }
This command backs up archived log 113 and deletes it from the primary site.
SELECT SEQUENCE#, IS_STANDBY FROM RC_ARCHIVED_LOG WHERE SEQUENCE#=113;
SEQUENCE# IS_ ---------- --- 113 YES
This query returns only one row, 113 YES, because the primary site copy of the archived log has been removed. Only the copy of log 113 at the standby site is available.
Consequently, you cannot use log 113 to perform media recovery at the primary site unless RMAN has backed it up. If you try to perform recovery of the primary database without either using the backup of the log just taken or moving the standby copy to the primary site, then RMAN stops media recovery at log 112 because it cannot locate log 113.
RC_ARCHIVED_LOG and see the following row:
SEQUENCE# IS_ ---------- --- 120 NO
RC_ARCHIVED_LOG (after resynchronization of the recovery catalog) shows:
SEQUENCE# IS_ ---------- --- 120 NO 120 YES
This result indicates that archived log 120 is located at both sites.
RUN { ALLOCATE CHANNEL c1 TYPE 'sbt_tape'; BACKUP ARCHIVELOG ALL DELETE INPUT; }
RC_ARCHIVED_LOG again and see only one row for log sequence number 120, indicating that the log is only available at the standby site:
SEQUENCE# IS_ ---------- --- 120 YES
RUN { ALLOCATE CHANNEL c1 TYPE 'sbt_tape'; BACKUP ARCHIVELOG ALL DELETE INPUT; }
When you query RC_ARCHIVED_LOG, the catalog shows no more rows for sequence number 120.
If you are making all your backups at the standby site, then you must ensure that you have backed up all the archived logs needed for recovery of the primary database. You have two methods for determining whether you need to back up a standby database archived log so that RMAN can use it for recovery.
Use the LIST command to determine which logs RMAN has backed up.
To determine whether a log backup is needed by using the LIST command:
SQL> SELECT SEQUENCE#, IS_STANDBY FROM RC_ARCHIVED_LOG;
SEQUENCE# IS_ ---------- --- 113 YES 114 NO 115 NO 116 NO
This output indicates that log sequence 113 is at the standby site but not at the primary site, and archived logs 114 - 116 are at the primary site but not the standby site.
LIST BACKUP command. For example, issue the following:
RMAN> LIST BACKUP OF ARCHIVELOG ALL; RMAN-03022: compiling command: list RMAN-03025: performing implicit partial resync of recovery catalog RMAN-03023: executing command: partial resync RMAN-08003: starting partial resync of recovery catalog RMAN-08005: partial resync complete List of Backup Sets Key Recid Stamp LV Set Stamp Set Count Completion Time ------- ---------- ---------- -- ---------- ---------- ---------------------- 319 4 394624547 0 394624546 5 11-APR-00 List of Backup Pieces Key Pc# Cp# Status Completion Time Piece Name ------- --- --- ----------- ---------------------- ------------------------ 320 1 1 AVAILABLE 11-APR-00 /vobs/oracle/dbs/05boavh2_1_1 List of Archived Logs Included Thrd Seq Low SCN Next SCN Low Time Next Time ---- ------- ---------- ---------- --------------- --------------- 1 116 95153 95156 07-APR-00 07-APR-00
This output shows that RMAN has backed up archived log 116, but has not backed up archived log 113. Because log 113 exists only at the standby site, you should either back up this log or copy it to the primary site.
You can query the recovery catalog to determine which logs RMAN has backed up.
To determine whether a log backup is needed by querying the catalog:
RC_ARCHIVED_LOG recovery catalog view to determine whether all archived logs necessary for recovery are on disk. For example, issue the following query, where first_log_needed_for_recovery is the sequence number of the log that begins recovery and expected_num_of_logs is the number of logs that should be applied during complete recovery:
SELECT 1 FROM RC_ARCHIVED_LOG WHERE SEQUENCE# >= first_log_needed_for_recovery AND IS_STANDBY='NO' AND STATUS='A' HAVING COUNT(*) = expected_num_of_logs;
If the query returns no rows, then you do not have all logs necessary for complete recovery on disk. If the query does return rows, then you do have the necessary logs for complete recovery on disk.
RC_BACKUP_REDOLOG view to determine whether you have backups of the logs necessary for complete recovery. For example, issue the following query, where first_log_needed_for_recovery is the sequence number of the log that begins recovery and expected_num_of_logs is the number of logs that should be applied during complete recovery:
SELECT 1 FROM RC_BACKUP_REDOLOG WHERE SEQUENCE# >= first_log_needed_for_recovery AND STATUS='A' HAVING COUNT(DISTINCT SEQUENCE#) = expected_num_of_logs;
If the query returns no rows, then you do not have backups of all logs necessary for complete recovery. If the query does return rows, then you do have backups of all logs necessary for complete recovery.
Use the RMAN BACKUP command to back up the standby database. A backup of the standby database is exactly the same as a backup of the primary database, except that the backup takes place on the standby site. The primary database has no influence on the backup of the standby database. Note that when you connect to the standby database to perform the backup, you connect using the TARGET keyword and not the AUXILIARY keyword.
As the following table illustrates, whether the standby database backup is consistent or inconsistent depends on the state of the standby database when the backup is made. Only a consistent backup can be restored without performing media recovery.
To make a whole database backup of a standby database:
TARGET keyword (not the AUXILIARY keyword) and the recovery catalog database. You must be connected to the recovery catalog. For example, enter:
% rman TARGET SYS/change_on_install@sbdb1 CATALOG rman/rman@rcat
% SQLPLUS sys/change_on_install@sbdb1 SQL> SHUTDOWN IMMEDIATE SQL> STARTUP MOUNT PFILE=initSTANDBY.ora
You can back up the standby database when it is in any other mode, but the backups will be inconsistent.
DISK or type 'sbt_tape'. This example backs up all the datafiles as well as the control file:
RUN { ALLOCATE CHANNEL ch1 TYPE 'sbt_tape'; BACKUP DATABASE; BACKUP ARCHIVELOG ALL; }
If desired, use the FORMAT parameter to specify a filename for the backup piece. For example, enter:
RUN { ALLOCATE CHANNEL ch1 TYPE 'sbt_tape'; BACKUP DATABASE FORMAT '/oracle/backup/standby_%U'; # %U generates a unique filename }
If desired, use the TAG parameter to specify a tag for the backup. For example, enter:
RUN { ALLOCATE CHANNEL ch1 TYPE 'sbt_tape'; BACKUP DATABASE TAG = 'weekly_standby_backup'; # gives the standby backup a tag identifier }
LIST command to see a listing of backup sets and pieces.
You can use the VALIDATE keyword of the BACKUP command to do the following:
RMAN does not actually produce backup sets, but scans the specified files to determine whether they can be backed up. In this sense, the BACKUP VALIDATE command is similar to the RESTORE VALIDATE command, except for backups rather than restore jobs.
For example, you can validate that all database files and archived redo logs can be backed up by issuing a command as follows:
RUN { ALLOCATE CHANNEL ch1 TYPE 'sbt_tape'; BACKUP VALIDATE DATABASE ARCHIVELOG ALL; }
Note that you cannot use the MAXCORRUPT or PROXY parameters with the VALIDATE option.
Use the SET SNAPSHOT CONTROLFILE LOCATION TO DEFAULT command to set the default filename that is used for the snapshot control file. This default value is platform-specific and depends on the Oracle home. For example, the default filename on some UNIX platforms in release 8.1.7 is $ORACLE_HOME/dbs/snapcf_@.f.
If you upgrade to the current release from a previous release, for example, to release 8.1.7 from release 8.1.6, then the snapshot control file location is not set to the default value. RMAN uses the snapshot location that is already stored in the control file. In this case, the snapshot control file location does not change if you change the Oracle home.
If you create a new database in release 8.1.7, then the snapshot control file location does have the default value. In this case, the default snapshot control file location changes if you change the Oracle home.
This section contains these topics:
You can allocate multiple maintenance channels before issuing one of these commands:
RMAN checks on all channels that have the same device type as the channel used to create the backup. Because the multi-channel feature does not parallelize maintenance operations, you should only use this feature in these scenarios:
This feature uses the existing RMAN syntax. No new syntax options are required.
When you allocate multiple maintenance channels before a CROSSCHECK, DELETE EXPIRED, or CHANGE ... DELETE command, RMAN performs the crosscheck or delete on all channels that have the appropriate device type. For example, assume that you do not use a media manager, and have created only one backup of a database as follows:
RUN { ALLOCATE CHANNEL ch1 TYPE DISK CONNECT 'x/x@node2'; BACKUP DATABASE; }
Assume that you issue the following series of commands at the RMAN prompt:
ALLOCATE CHANNEL FOR MAINTENANCE TYPE DISK CONNECT 'x/x@node1'; alLOCATE CHANNEL FOR MAINTENANCE TYPE DISK CONNECT 'x/x@node2'; ALLOCATE CHANNEL FOR MAINTENANCE TYPE 'sbt_tape'; CROSSCHECK BACKUP OF DATABASE;
RMAN checks the first two channels because they both have the device type of disk and finds the backup on the second channel. RMAN does not perform a crosscheck on the third channel because you did not make backups using a media manager.
This feature adds the following new restrictions when deleting backup pieces or proxy copies:
CHANGE ... DELETE command results in an error and fails if you attempt to delete a backup using CHANGE ... DELETE when either of these conditions is met:
DELETE EXPIRED BACKUP results in an error and fails if any expired backups really do exist. In some rare cases, the repository can mark a backup as EXPIRED even though the backup exists. For example, a directory containing a backup is corrupted at the time of the crosscheck, but is later repaired.
CHANGE ... CROSSCHECK, the media handle must have been created on the same device type specified on the first allocated maintenance channel. Typically, you allocate only a single maintenance channel before issuing CHANGE ... CROSSCHECK, but you may want to crosscheck several individual backup pieces or backup sets that were created on different device types. You can still supply keys instead of media handles. This restriction exists because a media handle is not unique among device types.
RMAN can perform crosschecks on more than one media at the same time. For example, you can perform a crosscheck for backups of the database on disk and tape channels as follows:
RMAN> ALLOCATE CHANNEL FOR MAINTENANCE TYPE DISK; RMAN> ALLOCATE CHANNEL FOR MAINTENANCE TYPE 'sbt_tape'; RMAN> CROSSCHECK BACKUP OF DATABASE;
This feature is useful in an OPS configuration in which tape backups exist on various nodes in the cluster. For example, you can perform a crosscheck on two nodes of an OPS cluster as follows:
RMAN> ALLOCATE CHANNEL node_1 TYPE DISK CONNECT 'sys/sys_pwd@node_1'; RMAN> ALLOCATE CHANNEL node_2 TYPE DISK CONNECT 'sys/sys_pwd@node_2'; RMAN> CROSSCHECK BACKUP;
You can also perform deletions on all allocated channels as in this example:
RMAN> ALLOCATE CHANNEL FOR MAINTENANCE TYPE DISK; RMAN> ALLOCATE CHANNEL FOR MAINTENANCE TYPE 'sbt_tape'; RMAN> CHANGE BACKUPSET 1,2,3,4,5 DELETE;
RMAN searches for the specified backup sets on all channels and deletes any that it finds.
You can release all allocated maintenance channels currently allocated by using this command:
RMAN> RELEASE CHANNEL;
RMAN can only connect to one instance in an Oracle Parallel Server (OPS) cluster at a time. For example, assume that inst1, inst2, and inst3 are net services names for the three instances in an OPS cluster. In this case, you can connect to the target database using only one of these net service names. For example, you can connect as follows:
% rman TARGET SYS/sys_pwd@inst2 CATALOG rman/cat_pwd@cat_str
Each net service name must specify one and only instance. You cannot specify a net service name that is used by all three instances in the cluster.
Note that the fact that RMAN connects to only one instance does not preclude running a backup using all three instances. For example, you can run a backup job as follows:
RUN { ALLOCATE CHANNEL c1 TYPE DISK CONNECT = 'SYS/sys_pwd@inst1'; ALLOCATE CHANNEL c2 TYPE DISK CONNECT = 'SYS/sys_pwd@inst2'; ALLOCATE CHANNEL c3 TYPE DISK CONNECT = 'SYS/sys_pwd@inst3'; BACKUP DATABASE; }
The RMAN maintenance commands are as follows:
In release 8.1.6, several uses of these commands required a recovery catalog. In release 8.1.7, fewer maintenance commands require the use of a recovery catalog.
The only options of the CHANGE command that now require a recovery catalog are the following:
CHANGE ... AVAILABLE (however, the catalog is only required when used on objects other than backup sets, backup pieces, and proxy copies)
CHANGE ... UNAVAILABLE
The CROSSCHECK and DELETE EXPIRED commands no longer require a recovery catalog in release 8.1.7.
In this scenario, you are connected to the target database while it is not open and attempt to perform an RMAN operation. You receive the following error message:
PLS-00553: character set name is not recognized
Typically, this error message means that the character set value in the client environment, that is, the environment in which you are running the RMAN executable, is different from the character set value in the target database environment.
NLS_LANG variable on the client and server:
% echo $NLS_LANG
NLS_LANG environment variable on a UNIX system as follows:
% setenv NLS_LANG WE8ISO8859P1
In Oracle8i Release 2 (8.1.6), the CONFIGURE COMPATIBLE command set the compatibility level in the recovery catalog. This command helped to solve problems resulting from the way in which RMAN updated and deleted catalog records. In Oracle8i Release 3 (8.1.7), these problems are solved, so the CONFIGURE COMPATIBLE command is deprecated.
In release 8.1.6, if you set CONFIGURE COMPATIBLE to 8.1.5 or lower, then RMAN updated the associated record to status DELETED when you issued CHANGE ... DELETE. RMAN did not remove the record, but only changed its status. In release 8.1.7, RMAN always removes the recovery catalog record when you issue CHANGE ... DELETE.
This section contains these topics:
The RMAN environment can contain the following components:
Each component has a release number. For example, you can use a release 8.1.5 RMAN executable with:
In general, the rules of RMAN compatibility are as follows:
Table 7-4 shows version requirements for RMAN components.
| Target/Auxiliary Database | RMAN Executable | Catalog Database | Catalog Schema |
|---|---|---|---|
|
8.0.3 |
8.0.3 |
8.x |
8.0.3 |
|
8.0.4 |
8.0.4 |
8.x |
>= 8.0.4, see "Note: 8.1 Catalog Schemas and 8.0 Targets" |
|
8.0.5 |
8.0.5 |
8.x |
>= 8.0.5, see "Note: 8.1 Catalog Schemas and 8.0 Targets" |
|
8.0.6 |
8.0.6 |
8.x |
8.0.6 |
|
8.0.6 |
8.0.6 |
8.1.x |
8.1.x |
|
8.1.5 |
8.1.5 |
8.1.x |
>= 8.1.5 |
|
8.1.6 |
8.0.6.1 |
8.x |
8.0.6 |
|
8.1.6 |
8.0.6.1 |
8.1.x |
>= RMAN executable |
|
8.1.6 |
>= 8.1.5 |
8.1.x |
>= RMAN executable |
|
8.1.7 |
8.0.6.1 |
8.x |
8.0.6 |
|
8.1.7 |
8.0.6.1 |
8.1.x |
8.1.x |
|
8.1.7 |
>= 8.1.5 |
8.1.x |
>= RMAN executable |
RMAN cannot create 8.1 catalog schemas in 8.0 catalog databases.
Restore operations for an 8.0.4 or 8.0.5 target with an 8.1 catalog schema do not work when both these conditions are met:
If any of these conditions is not met, then you can use an 8.1 catalog schema with an 8.0.4 or 8.0.5 target database
Using a pre-8.1.6 release of the RMAN executable with recovery catalog schema of release 8.1.6 (newly created by 8.1.6 RMAN executable using the CREATE CATALOG command) requires the following update at the catalog database:
SQL> UPDATE CONFIG SET VALUE='080004' WHERE NAME='COMPATIBLE';
Assume that you maintain four production databases of the following releases:
You want to record metadata about these databases in a single recovery catalog database. According to Table 7-4, you can use a single 8.1.7 recovery catalog database, but you must use two different catalog schemas. You must use an 8.0.5 catalog schema to register the 8.0.5 target database, but you can use an 8.1.7 catalog schema to register the 8.0.6, 8.1.6, and 8.1.7 target databases. The 8.0.5 catalog schema and 8.1.7 catalog schema can co-exist in a single 8.1.7 catalog database.
Note that you cannot use a single RMAN executable to back up all the databases. You must use an 8.0.5 executable to back up the 8.0.5 target database, but you can use an 8.0.6.1 RMAN executable to back up the other databases.
The following RMAN syntax diagrams have changed for release 8.1.7:
No keywords or parameters have changed, but the semi-colon is now optional.
Note the following restrictions involved when using the DUPLICATE command to create a standby database:
RUN block. You can allocate multiple auxiliary channels if needed.
ORA-1152 because the standby control file backup or copy was taken after the point in time.
SKIP READONLY and LOGFILE options of the DUPLICATE command. These options are legal for a duplicate database but illegal for the creation of the standby database.
SET NEWNAME or SET AUXNAME to transform the filenames for the online redo logs on the standby database.
DUPLICATE command to activate a standby database.
The recovery catalog views are unchanged except for new columns that are added to the following views.
The following changes to V$ views are relevant for RMAN operations involving the standby database.
|
 Copyright © 1996-2000, Oracle Corporation. All Rights Reserved. |
|