1
Recovery Manager Architecture

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

This chapter contains these topics:

• About the RMAN Environment
• RMAN Command Line Client
• RMAN Repository
• Media Management

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.

Table 1-1 lists possible components of the RMAN environment.

Table 1-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 metadata about the target database and to store information about its own operations. The work of backup and recovery is performed by server sessions running on the target database.	Yes
RMAN client	The client application that manages backup and recovery operations for a target database. The RMAN client can use 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.	Yes
Recovery catalog database	A database containing the recovery catalog schema, which contains the metadata that RMAN uses to perform its backup and recovery operations.	No
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.	No
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. You can fail over to the standby database if the primary database goes down.	No
Duplicate database	A copy of the primary database that you can use for testing purposes.	No
Media management application	A vendor-specific application that allows RMAN to back up to a storage system such as tape.	No
Media management catalog	A vendor-specific repository of information about a media management application.	No
Enterprise Manager	A browser-based interface to the Oracle database, including backup and recovery through RMAN.	No

The only required components in an RMAN environment are the target database and the RMAN client, but most real-world configurations are more complicated. One might use an RMAN client connecting to multiple media managers and multiple target, recovery catalog, and auxiliary databases, all accessed through Enterprise Manager.

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 UNIX, a server session corresponds to a server process, while on Windows it corresponds to a thread within the database service.

The RMAN client itself does not perform backup, restore, or recovery operations. When you connect the RMAN client to a target database, RMAN allocates server sessions on the target instance and directs them to perform the operations. The RMAN client uses internal, undocumented PL/SQL packages to communicate with the target database and recovery catalog.

RMAN Command Line Client

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

Even when you use the backup and recovery features in Enterprise Manager that are built on top of RMAN, an RMAN client executes behind the scenes.

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 (for example, resolving a tablespace name into its component datafiles). Then, RMAN constructs a sequence of remote procedure calls (RPCs) that instruct the server sessions on the target database to perform the desired operation.

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.

Issuing RMAN Commands

RMAN uses a command language interpreter (CLI) that can execute commands in interactive or batch mode.

Entering Commands at the RMAN Prompt

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/oracle@trgt CATALOG rman/cat@catdb

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

RMAN> BACKUP DATABASE; 

Using RMAN with Command Files

A command file is a text file which contains RMAN commands as you would enter them at the command line. You can run the a command file by specifying its name on the command line. The contents of the command file will be interpreted as if entered at the command line. If the LOG command line argument is specified, RMAN directs output to the named log file. Command files are one way to automate scheduled backups through an operating system job control facility.

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

% rman TARGET / CATALOG rman/cat@catdb CMDFILE commandfile.rcv LOG outfile.txt

Stored Scripts

A stored script is a block of RMAN job commands that is stored in the recovery catalog. By storing scripts in the recovery catalog, the script is available to any RMAN client that connects to the catalog and the target database. Stored scripts can be associated with a single database in the catalog, or they can be global stored scripts, which can be executed against any target database in the catalog.

Commands Valid Only in RUN Blocks

There are RMAN commands which are only valid in RUN blocks. These typically involve setting up the environment within which the statements in the RUN block will execute. Typical of this group are ALLOCATE CHANNEL and SET NEWNAME FOR DATAFILE. Using these commands outside of a RUN block will generate an error.

Commands Not Valid in RUN Blocks

There are a number of RMAN commands which cannot be used in RUN blocks. Typically these are used to control the RMAN environment (connecting to different databases, or configuring RMAN defaults), or to manage or query the recovery catalog (including creating and using stored scripts). Here are some examples:

• CONNECT
• CONFIGURE
• CREATE CATALOG, DROP CATALOG, UPGRADE CATALOG
• CREATE SCRIPT, DELETE SCRIPT, REPLACE SCRIPT
• LIST
• REPORT

You can include these commands inside command files, as long as they are not wrapped inside a RUN block. You cannot use them inside a stored script from the recovery catalog, because the contents of a stored script are executed within a RUN block.

Controlling RMAN Output

When you run RMAN in command line mode, it sends the output to the terminal. If you specify the LOG option, then RMAN writes the output to a specified log file instead.

Output for currently executing RMAN jobs is also stored in the V$RMAN_OUTPUT view, which reads only from memory (that is, the information is not stored in the control file). The V$RMAN_STATUS view stores metadata about jobs in progress as well as completed jobs. The metadata for completed jobs is stored in the control file.

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 private 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/oracle@trgt

RMAN opens the two pipes in the target database: ORA$RMAN_ABC_IN, which RMAN uses to receive user commands, and ORA$RMAN_ABC_OUT, which RMAN uses to send all output back to RMAN.

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.

RMAN Repository

The RMAN repository is the collection of metadata about the target databases that RMAN uses for backup, recovery, and maintenance. RMAN always stores this information in records in the control file. The version of this information in the control file is the authoritative record of RMAN's backups of your database. This is one reason why protecting your control file is a important part of your backup strategy. RMAN can conduct all necessary backup and recovery operations using just the control file to store the RMAN repository information, and maintains all records necessary to meet your configured retention policy.

You can also create a recovery catalog, an external Oracle database in which to store this information. The control file has finite space for records of backup activities, while a recovery catalog can store a much longer history. The added complexity of operating a recovery catalog database can be offset by the convenience of having the extended backup history available if you have to do a recovery that goes further back in time than the history in the control file.

There are also a few features of RMAN that only function when you use a recovery catalog. For example, RMAN stored scripts are stored in the recovery catalog, so commands related to them require the use of a recovery catalog. Other RMAN commands are specifically related to managing the recovery catalog and so are not available (and not needed) if RMAN is not connected to a recovery catalog.

The recovery catalog's version of the RMAN repository is maintained solely by RMAN. The target instance 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 after any operation that updates the repository, and also before certain operations.

Storage of the RMAN Repository in the Recovery Catalog

It is recommended that you store the recovery catalog in a dedicated database. If you store the recovery catalog alongside other data in some other database, then if you lose that other database you will lose your recovery catalog as well. This will make your recovery more difficult.

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 catdb. Because RMAN distinguishes databases by unique database identifier (DBID), each database registered in a given catalog must have a unique DBID.

Contents of the Recovery Catalog

The recovery catalog contains information about RMAN operations, including:

• Datafile and archived redo log backup sets and backup pieces
• Datafile copies
• Archived redo logs and their copies
• Tablespaces and datafiles on the target database
• Stored scripts, which are named user-created sequences of RMAN commands
• Persistent RMAN configuration settings

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.

Snapshot Control File

RMAN creates a snapshot control file, which is a temporary backup control file, in an operating system specific location 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 database 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.

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.

Compatibility of the Recovery Catalog

When you use RMAN with a recovery catalog in an environment where you have run past versions of the Oracle database, you can wind up with versions of the RMAN client, recovery catalog database, recovery catalog schema, and target database that all originated in different releases of the database. You will find a compatibility matrix in Oracle Database Recovery Manager Reference that describes supported interoperability scenarios.

Storage of the RMAN Repository 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 a separate recovery catalog database is burdensome. The only RMAN feature that is not supported in NOCATALOG mode is stored scripts.

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. Circular reuse records are arranged in a logical ring. When all available record slots are full, the database 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.

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 Recovery catalog

To make it easier to restore and recover the database without using a recovery catalog, Oracle Corporation recommends that you:

• Enable the control file autobackup feature, which causes RMAN to automatically back up the control file, and also enables RMAN to restore the control file autobackup without access to a repository
• Keep a record of your DBID, which you may need to recover your database in the event that you lose your control file
• Use a minimum of two multiplexed or mirrored control files on separate disks
• Keep all Recovery Manager backup logs.

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

Media Management

Oracle Corporation's Media Management Layer (MML) API lets third-party vendors build a media manager, software that works with RMAN and the vendor's hardware to allow backups to sequential media devices such as tape drives. The media manager handles loading, unloading and labeling of sequential media such as tapes. You must install media manager software to use RMAN with sequential media devices.

When backing up or restoring, the RMAN client connects to the target instance and directs the instance to send requests to its media manager. No direct communication occurs between the RMAN client and media manager.

Performing Backup and Restore with a Media Manager

Before performing backup or restore to a media manager, you must allocate one or more channels to handle the commuication with the media manager. You can also configure default channels for use with the media manager, which will be applied for all backup and recovery tasks that use the media manager where you do not explicitly allocate channels. For a conceptual overview of channels, see "About RMAN Channels". Configuring or allocating channels for backups is discussed further in "Configuring and Allocating Channels for Use in Backups".

For example, this sequence of commands would configure channels for the media manager and back up the database to the media manager:

RMAN> CONFIGURE DEVICE TYPE sbt PARALLELISM 1;
RMAN> CONFIGURE DEFAULT DEVICE TYPE TO sbt;
RMAN> CONFIGURE CHANNEL DEVICE TYPE sbt PARMS 'ENV=(NSR_SERVER=bksvr1)';
RMAN> BACKUP DATABASE;

When RMAN executes the BACKUP DATABASE command, it sends the backup request to the database server session performing the backup. The database server session identifies the output channel as a media management device and makes a request to the media manager to write the output.

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 byte stream. All details of how and where that stream is stored are handled entirely by the media manager.

The media manager labels and keeps track of the tape and names of files on each tape, and automatically loads and unloads tapes, or signals an operator to do so.

Some media managers support proxy copy functionality, in which they handle the entire data movement between datafiles and the backup devices. Such products may use technologies such as high-speed connections between storage and media subsystems to reduce load on the primary database server. 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.

Backup Solutions Program

The Oracle Backup Solutions Program (BSP), part of the Oracle Partner Program, is a group of leading media manager vendors whose products are compliant with Oracle Corporation's MML specification. Several products may be available for your platform from media management vendors. For more information, you can contact your Oracle representative for a list of available products, contact individual vendors to ask them if they participate, or access the Backup Solutions Program Web site at:

http://otn.oracle.com/deploy/availability

Note that Oracle Corporation does not certify media manager vendors for compatibility with RMAN. Questions about availability, version compatibility, and functionality can only be answered by the media manager vendor, not Oracle Corporation.