Oracle9i Recovery Manager User's Guide
Release 1 (9.0.1)

Part Number A90135-01
Go To Documentation Library
Go To Product List
Book List
Go To Table Of Contents
Go To Index

Master Index


Go to previous page Go to next page

Recovery Manager Architecture

This chapter describes the Recovery Manager (RMAN) interface and the basic elements of the RMAN environment.

This chapter contains these topics:

Overview of RMAN Architecture

This section contains these topics:

About the RMAN Environment

Recovery Manager (RMAN) is a client application that performs backup and recovery operations. The Recovery Manager environment consists of the various applications and databases that play a role in a backup and recovery strategy.

The RMAN environment can be as simple as an RMAN executable connecting to a target database, or as complex as an RMAN executable connecting to multiple media managers and multiple target, recovery catalog, and auxiliary databases, all accessed through Oracle Enterprise Manager. Table 4-1 lists possible components of the RMAN environment.

Table 4-1 Components of the RMAN Environment
Component  Description  Required? 

Target database 

The control files, datafiles, and optional archived redo logs that RMAN is in charge of backing up or restoring. RMAN uses the target database control file to gather information about the database and to store information about its own operations. The actual work of the backup and recovery jobs is performed by server sessions on the target database. 


RMAN executable 

The client application that manages backup and recovery operations for a target database. The RMAN client uses Oracle Net to connect to a target database, so it can be located on any host that is connected to the target host through Oracle Net. 


Recovery catalog database 

A database containing the recovery catalog schema, which contains the metadata that RMAN uses to perform its backup and recovery operations.  


Recovery catalog schema 

The user within the recovery catalog database that owns the metadata tables maintained by RMAN. RMAN periodically propagates metadata from the target database control file into the recovery catalog. 


Standby database 

A copy of the primary database that is updated using archived logs created by the primary database. RMAN can create or back up a standby database. 


Media management application 

A vendor-specific application that allows RMAN to back up to a storage system such as tape. When doing backups or restores, the RMAN client connects to the target instance and directs the instance to talk to its media manager. No direct communication occurs between the RMAN client and the media manager: all communication occurs on the target instance. 


Media management catalog 

A vendor-specific repository of information about a media management application. 


Oracle Enterprise Manager 

A GUI-based application that you can use as an interface to RMAN. 


As the table illustrates, the only required components in an RMAN environment are the target database and the RMAN executable. Nevertheless, most real-world configurations are more complicated.

Figure 4-1 depicts an example of a realistic RMAN environment. In this environment, five nodes are networked together, with each machine serving a different purpose. The five nodes share duties as follows:

In this scenario, you can run the RMAN executable from a client machine, and then connect to the target, catalog, and auxiliary databases. You can then run backup and recovery jobs. You can also connect to the client hosting Oracle Enterprise Manager and use the GUI interface to access RMAN.

Figure 4-1 Example RMAN Environment

Text description of rmang001.gif follows
Text description of the illustration rmang001.gif

RMAN Session Architecture

The RMAN client application directs database server sessions to perform all backup and recovery tasks. The meaning of "session" in this sense depends on the operating system. For example, on a UNIX system a server session corresponds to a server process. On a Windows NT system, an server session corresponds to a thread within the Oracle service.

When you connect the RMAN client to the target database server, RMAN allocates server sessions on the target instance and directs them to perform the backup and recovery operations. The RMAN client itself does not perform the backup, restore, or recovery.

Storage of RMAN Metadata

Because RMAN manages backup and recovery operations, it requires a place to store necessary information about the database. RMAN always stores this information in the target database control file. You can also store RMAN metadata in a recovery catalog schema contained in a separate database. The recovery catalog schema must be stored in a database other than the target database. RMAN periodically migrates information from the control file to the recovery catalog.

RMAN Command Interface

Use the RMAN interface to enter commands that you can use to manage all aspects of backup and recovery operations.


All RMAN commands for Oracle release 8.0 and higher also work in Oracle9i

This section contains these topics:

RMAN PL/SQL Packages

The RMAN executable uses PL/SQL packages to communicate with the target database and recovery catalog. The PL/SQL packages perform the following functions:

The DBMS_RCVCAT and DBMS_RCVMAN packages are internal, undocumented packages created by the CREATE CATALOG command. RMAN uses DBMS_RCVCAT to maintain information in the recovery catalog and DBMS_RCVMAN to query the recovery catalog or control file.

The DBMS_BACKUP_RESTORE package is an internal package created by the dbmsbkrs.sql and prvtbkrs.plb scripts. This package, along with the target database version of DBMS_RCVMAN, is automatically installed in every Oracle database when the catproc.sql script is run. This package interfaces with the Oracle database server and the operating system to provide the I/O services for backup and restore operations as directed by RMAN.

How RMAN Compiles and Executes Commands

RMAN processes most commands in the two phases discussed in this section:

Compilation Phase

During the compilation phase, RMAN determines which objects the command will access by, for example, translating a TABLESPACE keyword into the names of its component datafiles. Then, RMAN constructs a sequence of remote procedure calls (RPCs) that instruct the target database to perform the desired operation, such as backing up, restoring, or recovering datafiles.

Execution Phase

During the execution phase, RMAN sends the RPC calls to the target database, monitors their progress, and collects the results. If more than one channel is allocated, then RMAN can execute certain commands in parallel so that all of the channels' target database sessions are concurrently executing an RPC call. RMAN coordinates this parallel execution and monitors the progress on all channels that are doing work.

Types of RMAN Commands

RMAN commands can be divided in this way:

Besides these commands, RMAN also supports a number of command-line arguments that you can specify when you start RMAN.

See Also:

Oracle9i Recovery Manager Reference for a complete description of RMAN commands and command-line options 

Standalone Commands

Unlike job commands, standalone commands cannot appear as subcommands within RUN. Following are some of the commands that you must use on the RMAN prompt:

Some of these commands are not strictly standalone, however, because they must be preceded by an ALLOCATE CHANNEL FOR MAINTENANCE command.

See Also:

Syntax entries in Oracle9i Recovery Manager Reference to determine which must be executed at the RMAN prompt 

Job Commands

Unlike standalone commands, job commands must appear within the brackets of a RUN command. Following are examples of job commands:

RMAN executes the job commands inside of a RUN command block sequentially. If any command within the block fails, then RMAN ceases processing--no further commands within the block are executed. In effect, the RUN command defines a unit of command execution. When the last command within a RUN block completes, Oracle releases any server-side resources such as I/O buffers or I/O slave processes allocated within the block.

See Also:

Oracle9i Recovery Manager Reference to learn about RUN command syntax 

Command Exceptions

Although some commands are either standalone commands or job commands exclusively, other commands can be issued either at the prompt or within a RUN command. Whether issued at the prompt or within RUN, the commands can make use of automatic channels. Note that you can manually allocate channels only within a RUN command, and in this case the manually allocated channels override any configured automatic channels.

The following are examples of commands that can function as both standalone and job commands:

User Execution of RMAN Commands

RMAN uses a command language interpreter (CLI) that can execute commands in interactive or batch mode. You can also specify the LOG option at the command line to write RMAN output into a log file.

See Also:

"Terminating an RMAN Command" to learn how to end an RMAN session 

Interactive Mode

To run RMAN commands interactively, start RMAN and then type commands into the command-line interface. For example, you can start RMAN from the UNIX command shell and then execute interactive commands as follows:

% rman TARGET sys/sys_pwd@prod1 CATALOG rman/rman@rcat

After the RMAN prompt is displayed, you can enter commands such as follows:


Batch Mode

You can type RMAN commands into a file, and then run the command file by specifying its name on the command line. The contents of the command file should be identical to commands entered at the command line.

When running in batch mode, RMAN reads input from a command file and writes output messages to a log file (if specified). Batch mode is most suitable for performing regularly scheduled backups through an operating system job control facility.

In this example, a sample RMAN script is placed into a command file called b_l0.rcv. You can run this file from the operating system command line and write the output into the log file log.f as follows:

% rman TARGET / CATALOG rman/rman@rcat CMDFILE b_l0.rcv LOG log.f

See Also:

Oracle9i Recovery Manager Reference for more information about RMAN command line options 

Stored Scripts

A stored script is a block of RMAN job commands that is stored in the recovery catalog. Stored scripts allow you to plan, develop, and test commands for backing up, restoring, or recovering the database. Also, scripts minimize the potential for user errors. Note that each stored script relates to only one target database.

To create a stored script, either enter the script interactively into the RMAN command-line interface, or type the RMAN commands into a command file and run the command file.

Following is an example of a stored script:

REPLACE SCRIPT b_whole_l0 
  # back up whole database and archived logs
    TAG b_whole_l0

You can execute this stored script from the RMAN prompt as follows:

RUN { EXECUTE SCRIPT b_whole_10 };

View stored scripts by querying the recovery catalog view RC_STORED_SCRIPT:


---------- -------   ------------------------------------------------------
         1 RMAN      full_backup
         1 RMAN      incr_backup_0
         1 RMAN      incr_backup_1
         1 RMAN      incr_backup_2
         1 RMAN      log_backup

See Also:

"Managing RMAN Scripts Stored in the Recovery Catalog" for more on stored scripts. Also see to the sample scripts in the $ORACLE_HOME/rdbms/demo directory. 

RMAN Pipe Interface

The RMAN pipe interface is an alternative method for issuing commands to RMAN and receiving the output from those commands. With this interface, RMAN obtains commands and sends output by using the DBMS_PIPE PL/SQL package. RMAN does not read or write any data using the operating system shell. By using this interface, it is possible to write a portable programmatic interface to RMAN.

The pipe interface is invoked by using the PIPE command-line parameter. RMAN uses two public pipes: one for receiving commands and the other for sending output. The names of the pipes are derived from the value of the PIPE parameter. For example, you can invoke RMAN with the following command:

% rman PIPE abc TARGET SYS/sys_pwd@some_db

RMAN opens the following pipes in the target database:

All messages on both the input and output pipes are of type VARCHAR2.

Note that RMAN does not permit the pipe interface to be used with public pipes, because they are a potential security problem. With a public pipe, any user who knows the name of the pipe can send commands to RMAN and intercept its output.

See Also:

"Executing RMAN Commands Through a Pipe" to learn how to execute RMAN commands through a pipe 

RMAN Repository

The RMAN repository is the collection of metadata about the target databases that RMAN uses to conduct its backup, recovery, and maintenance operations. You can either create a recovery catalog in which to store this information, or let RMAN store it exclusively in the target database control file. Although RMAN can conduct all major backup and recovery operations using just the control file, some RMAN commands function only when you use a recovery catalog.

The recovery catalog is maintained solely by RMAN; the target database never accesses it directly. RMAN propagates information about the database structure, archived redo logs, backup sets, and datafile copies into the recovery catalog from the target database's control file.

See Also:

Chapter 16, "Managing the Recovery Manager Repository" to learn how to manage the RMAN repository, and "Understanding Catalog-Only Command Restrictions" for a list of catalog-only commands 

Storage of the RMAN Repository in the Recovery Catalog

The recovery catalog is an optional repository of information about the target databases that RMAN uses and maintains. It is recommended that you store the catalog in a dedicated database. RMAN uses the information in the recovery catalog, which is obtained from the control file, to determine how to execute requested backup and recovery operations.

This section contains these topics:

Registration of Databases in the Recovery Catalog

The enrolling of a database in a recovery catalog is called registration. You can register more than one target database in the same recovery catalog. For example, you can register databases prod1, prod2, and prod3 in a single catalog owned by catowner in the database rcatdb. You can register a database only once in a given catalog schema: for example, you cannot register prod1 in the catowner catalog and then register prod1 again in the catowner catalog.

Each database registered in a given catalog must have a unique database identifier (DBID), but not a unique name. For example, you can register database prod1 with DBID 862893450 and database prod1 with DBID 951781249 in the same catalog. You cannot register two databases with the same DBID in the same catalog. For example, you cannot register database prod1 with DBID 862893450 and database prod2 with DBID 862893450 in the same catalog. Thus, you cannot copy a database manually and then register it in the same catalog with its parent because their DBIDs are the same. Instead, use the DUPLICATE command to create a test database with a unique DBID that you can register in the catalog along with its parent.

Contents of the Recovery Catalog

The recovery catalog contains information about RMAN operations, including:

Resynchronization of the Recovery Catalog

The recovery catalog obtains crucial RMAN metadata from the target database control file. Resynchronization of the recovery catalog ensures that the metadata that RMAN obtains from the control file stays current.

Resynchronizations can be full or partial. In a partial resynchronization, RMAN reads the current control file to update changed data, but does not resynchronize metadata about the database physical schema: datafiles, tablespaces, redo threads, rollback segments, and online redo logs. In a full resynchronization, RMAN updates all changed records, including schema records.

RMAN automatically detects when it needs to perform a full or partial resynchronization and executes the operation as needed. You can also force a full resynchronization by issuing a RESYNC CATALOG command.

To ensure that the catalog stays current, run the RESYNC CATALOG command periodically. A good rule of thumb is to run it at least once every n days, where n is the setting for the initialization parameter CONTROL_FILE_RECORD_KEEP_TIME. Because the control file employs a circular reuse system, backup and copy records eventually get overwritten. Resynchronizing the catalog ensures that these records are stored in the catalog and so are not lost.

See Also:

"Types of Records in the Control File" for more information about control file records 

Snapshot Control File

RMAN generates a snapshot control file, which is a temporary backup control file, each time it performs a full resynchronization. This snapshot control file ensures that RMAN has a consistent view of the control file. Because the snapshot control file is intended for RMAN's short-term use, it is not registered in the recovery catalog. RMAN records the snapshot control file checkpoint in the recovery catalog to indicate the currency of the recovery catalog.

The Oracle9i server ensures that only one RMAN session accesses a snapshot control file at any point in time. This safeguard is necessary to ensure that two RMAN sessions do not interfere with each other's use of the snapshot control file.


You can specify the name and location of the snapshot control file. For instructions, refer to "Configuring the Snapshot Control File Location"

See Also:

"Managing the Control File When You Use a Recovery Catalog" to learn how to resynchronize the recovery catalog, and Oracle9i Recovery Manager Reference for syntax 

Backups of the Recovery Catalog

A single recovery catalog is able to store information for multiple target databases. Consequently, loss of the recovery catalog can be disastrous. You should back up the recovery catalog frequently.

If the recovery catalog is destroyed and no backups of it are available, then you can partially reconstruct the catalog from the current control file or control file backups. Nevertheless, you should always aim to have a valid, recent backup of the catalog.

See Also:

"Backing Up the Recovery Catalog" to learn how to back up the recovery catalog 

Compatibility of the Recovery Catalog

When you use RMAN with a recovery catalog, the RMAN environment contains the following components:

Each of these components has a release number associated with it. For example, you can use a release RMAN executable with a release 8.1.6 target database, and store the repository in a release 8.1.5 recovery catalog database whose catalog schema was created in release 8.1.6.

See Also:

Oracle9i Recovery Manager Reference for a chart describing the compatibility of the components in the RMAN environment 

Storage of the RMAN Repository Exclusively in the Control File

Because most information in the recovery catalog is also available in the target database's control file, RMAN supports an operational mode in which it uses the target database control file instead of a recovery catalog. This mode is especially appropriate for small databases where installation and administration of another database for the sole purpose of maintaining the recovery catalog is burdensome.

Oracle does not support the following features in this operational mode:

Types of Records in the Control File

When you do not use a recovery catalog, the control file is the exclusive source of information about backups and copies as well as other relevant information. The control file contains two types of records: circular reuse records and noncircular reuse records.

Circular Reuse Records

Circular reuse records contain noncritical information that is eligible to be overwritten if the need arises. These records contain information that is continually generated by the database. Some examples of information circular reuse records include:

Circular reuse records are arranged in a logical ring. When all available record slots are full, Oracle either expands the control file to make room for a new record or overwrites the oldest record. The CONTROL_FILE_RECORD_KEEP_TIME initialization parameter specifies the minimum age in days of a record before it can be reused.

See Also:

"Monitoring the Overwriting of Control File Records" to learn how to manage Oracle's treatment of circular reuse records 

Noncircular Reuse Records

Noncircular reuse records contain critical information that does not change often and cannot be overwritten. Some examples of information in noncircular reuse records include datafiles, online redo logs, and redo threads.

Recovery Without a Catalog

To restore and recover the database without using a recovery catalog, Oracle recommends that you:

If you lose the current control files, then you can restore a control file autobackup even if you do not use a recovery catalog.

See Also:

Media Management

To use tape storage for database backups, RMAN requires a media manager. A media manager is a utility that loads, labels, and unloads sequential media such as tape drives for backing up and recovering data.

Oracle publishes a media management API that third-party vendors can use to build software that works with RMAN. To use RMAN to make backups to sequential media such as tape, integrate media management software with your Oracle software. Note that Oracle does not need to connect to the media management library (MML) software when it backs up to disk.

Some media management products can manage the entire data movement between Oracle datafiles and the backup devices. Such products may use technologies such as high-speed connections between storage and media subsystems, which can remove much of the backup load from the primary database server.

Backup and Restore Operations with a Media Manager

The following RMAN command performs a datafile backup to tape:


When Recovery Manager executes this command, it sends the backup request to the Oracle server session performing the backup. The Oracle server session identifies the output channel as a media management device and makes a request to the media manager to write the output.

The media manager labels and keeps track of the tape and names of files on each tape. If your site owns an automated tape library, then the media manager automatically loads and unloads the tapes required by Oracle; if not, the media manager requests an operator to load a specified tape into the drive.

The media manager handles restore as well as backup operations. When you restore a file, the following steps occur:

  1. Oracle requests the restore of a particular file.

  2. The media manager identifies the tape containing the file and reads the tape.

  3. The media manager passes the information back to the Oracle server session.

  4. The Oracle session writes the file to disk.

Proxy Copy

Oracle has integrated proxy copy functionality into its media management API. Vendors can use this API to develop media management software that takes control of backup and restore operations. RMAN provides a list of files requiring backup or restore to the media manager, which in turn makes all decisions regarding how and when to move the data.

Media Manager Testing

A client program, sbttest, is a standalone test of the media management software that is linked with Oracle to perform backups to tape. Use it when Oracle is unable to create or restore backups using either the bundled Legato Storage Manager or another vendor's media management product. Only use the sbttest program at the direction of Oracle support.

Backup Solutions Program

The Oracle Backup Solutions Program (BSP), part of the Oracle Partner Program, is a group of leading media management software vendors whose products are compliant with Oracle's MML specification. Software that is compliant with the MML interface enables an Oracle server session to back up to a media manager and request the media manager to restore backups.

Note that RMAN does not issue specific commands to load, label, or unload tapes. When backing up, RMAN gives the media manager a stream of bytes and associates a unique name with that stream. When RMAN needs to restore the backup, it asks the media manager to retrieve the identical byte stream. All details of how and where that stream is stored are handled entirely by the media manager.

One MML-compliant product is the Legato Storage Manager (LSM), which is available for several common platforms. Oracle includes LSM with software that it ships for these platforms. If your version of the Oracle software includes LSM, then refer to Legato Storage Manager Administrator's Guide to learn about its features. If your shipment includes other BSP media management products, then refer to your platform-specific documentation for information.

Several other products may be available for your platform from media management vendors. For a current list of available products, you can access the Backup Solutions Program Web site at:

You can also contact your Oracle representative for a complete list.

To use a specific media management product, contact the media management vendor directly to determine whether it is a member of Oracle BSP. Note that Oracle Corporation does not certify media vendors for compatibility with RMAN, so any questions about availability, version compatibility, and functionality should be directed to the media vendor, not Oracle Corporation.

Go to previous page Go to next page
Copyright © 1996-2001, Oracle Corporation.

All Rights Reserved.
Go To Documentation Library
Go To Product List
Book List
Go To Table Of Contents
Go To Index

Master Index