1
Introduction to Recovery Manager

This chapter describes the definition and advantages of the Recovery Manager (RMAN) utility.

This chapter contains these sections:

• About Recovery Manager (RMAN)
• Why Use RMAN?
• Overview of the RMAN Environment

About Recovery Manager (RMAN)

Recovery Manager (RMAN) is an Oracle utility that can back up, restore, and recover database files. The product is a feature of the Oracle database server and does not require separate installation.

Recovery Manager is a client/server application that uses database server sessions to perform backup and recovery. It stores metadata about its operations in the control file of the target database and, optionally, in a recovery catalog schema in an Oracle database.

You can invoke RMAN as a command-line executable from the operating system prompt or use some RMAN features through the Enterprise Manager GUI.

Why Use RMAN?

Most production database systems impose stringent requirements on backup and recovery. As a DBA in charge of backup and recovery, you must:

• Manage the complexity of backup and recovery operations
• Minimize the possibility of human error
• Make backups scalable and reliable
• Utilize all available media hardware
• Make backups proportional to the size of transactional changes, not to the size of database
• Make recovery time proportional to the amount of data recovered

You have two basic methods for performing these backup and recovery tasks on an Oracle release 8.0 or higher database:

• Using operating system commands to perform backup and restore operations, and SQL or SQL*Plus statements to perform recovery
• Using Recovery Manager for backup, restore, and recovery

  Note: RMAN was introduced in Oracle release 8.0 and is not compatible with Oracle databases prior to release 8.0.

Why use one method rather than the other? As illustrated in Figure 1-1, RMAN uses server sessions to perform backup and recovery operations and stores metadata in a repository. RMAN automates backup and recovery, whereas the user-managed method requires you to keep track of all database files and backups. For example, instead of requiring you to locate backups for each datafile, copy them to the correct place using operating system commands, and choose which logs to apply, RMAN manages these tasks automatically.

The advantage of using RMAN is especially true if you use Oracle Managed Files. When you let Oracle name and manage your datafiles, control files, and online redo logs, the system becomes easier to use. On the other hand, it may be harder for you to keep track of the filenames of the various database files because you have not named them yourself. RMAN users do not suffer from this problem because RMAN handles all record keeping.

Figure 1-1 Comparison of RMAN Automated and User-Managed Procedures

Text description of the illustration sbr81080.gif

Besides the obvious advantage of automation, RMAN provides a host of other useful features. Table 1-1 compares some of the differences between the RMAN methodology and the traditional user-managed methodology.

Table 1-1 Comparison Between RMAN and User-Managed Methods (Page 1 of 2)

Recovery Manager	User-Managed Method
Uses a media management API so that RMAN works seamlessly with third-party media management software. More than 20 vendors support the API.	Does not have support of a published API.
When backing up online files, RMAN rereads fractured data blocks to get a consistent read. You do not need to place online tablespaces in backup mode when performing backups.	Requires placing online tablespaces in backup mode before backing them up, and then taking the tablespaces out of this mode after the backup is complete. Serious database performance and manageability problems can occur if you neglect to take tablespaces out of backup mode after an online backup is complete.
Performs incremental backups, which back up only those data blocks that changed after a previous backup. You can recover the database using incremental backups, which means that you can recover a NOARCHIVELOG database. However, you can only take incremental backups of a NOARCHIVELOG database after a consistent shutdown.	Backs up all blocks, not just the changed blocks. Does not allow you to recover a NOARCHIVELOG database.
Computes checksums for each block during a backup, and checks for corrupt blocks when backing up or restoring. Many of the integrity checks that are normally performed when executing SQL are also performed when backing up or restoring.	Does not provide error checking.
Omits never-used blocks from datafile backups so that only data blocks that have been written to are included in a backup.	Includes all data blocks, regardless of whether they contain data.
Uses the repository to report on crucial information, including: Database schema at a specified time Which files need a backup Which files have not had a backup in a specified number of days Which backups can be deleted because they are redundant or cannot be used for recovery Current RMAN persistent settings	Does not include any reporting functionality.
Stores RMAN scripts in the recovery catalog.	Requires storage and maintenance of operating system-based scripts.
Allows you to easily create a duplicate of the production database for testing purposes, or easily create or back up a standby database.	Requires you to follow a complicated procedure when creating a test or standby database.
Performs checks to determine whether backups on disk or in the media catalog are still available.	Requires you to locate and test backups manually.
Performs automatic parallelization of backup and restore operations.	Requires you to parallelize manually by determining which files you need to back up and then issuing operating system commands in parallel.
Tests whether files can be backed up or restored without actually performing the backup or restore.	Requires you to actually restore backup files before you can perform a trial recovery of the backups.
Performs archived log failover automatically. If RMAN discovers a corrupt or missing log during a backup, then it considers all logs and log copies listed in the repository as alternative candidates for the backup.	Cannot failover to an alternative archived log if the backup encounters a problem.

Overview of the RMAN Environment

The RMAN environment consists of the utilities and databases that play a role in a backup and recovery strategy. A typical RMAN setup utilizes the following:

• RMAN executable
• Target database
• Recovery catalog database
• Media management software

Of these components, only the RMAN executable and target database are required. RMAN automatically stores its metadata in the target database control file, so the recovery catalog database is optional. Nevertheless, maintaining a recovery catalog is strongly encouraged. If you create a catalog on a separate machine, and if the production machine fails completely, then you have all the restore and recovery information you need in the catalog.

This section contains these topics:

• About the RMAN Executable
• About the Target Database
• About the RMAN Repository
• About the RMAN Media Management Interface

About the RMAN Executable

The RMAN executable is automatically included with the Oracle software installation. Its location is platform-specific and is typically located in the same place as the other Oracle executables. On Unix systems, for example, the RMAN executable is located in $ORACLE_HOME/bin.

To start the executable, simply enter the filename on the command line. For example, on a UNIX system, enter:

% rman

About the Target Database

The target database is the database that RMAN is backing up, restoring, or recovering. You can use a single recovery catalog in conjunction with multiple target databases. For example, assume that your data center contains 10 databases of varying sizes. You can use a single recovery catalog located in a different data center to manage the metadata from all of these databases.

About the RMAN Repository

The RMAN repository is a set of metadata that RMAN uses to store information about the target database and its backup and recovery operations. Among other things, RMAN stores information about:

• Backup sets and pieces
• Image copies (including archived redo logs)
• Proxy copies
• The target database schema
• Persistent configuration settings

You can access this metadata by issuing LIST, REPORT, and SHOW commands in the RMAN interface, or by using SELECT statements on the catalog views (only if you use a recovery catalog). Figure 1-2 illustrates how RMAN issues lists and reports.

Figure 1-2 RMAN Lists and Reports

Text description of the illustration sbr81077.gif

You can either create a recovery catalog in which to store the repository, or let RMAN store the repository exclusively in the target database control file. Figure 1-3 depicts RMAN using a recovery catalog.

Figure 1-3 RMAN with Optional Recovery Catalog

Text description of the illustration sbr81016.gif

Although RMAN can conduct all major backup and recovery operations using just the control file, note these advantages of using the catalog:

• Some RMAN commands and operations function only with a catalog.
• The recovery catalog retains historical backup information that can get overwritten in the control file.
• The recovery catalog stores information about backups from different incarnations of the database.

The recovery catalog is maintained solely by RMAN; the target database never accesses it directly. RMAN automatically 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. You can also propagate this information to the catalog manually using the RESYNC CATALOG command.

About the RMAN Media Management Interface

To store backups on tape, RMAN requires a media manager. A media manager is a software program that loads, labels, and unloads sequential media such as tape drives used to back up and recover data. Figure 1-4 shows the architecture for a media manager integrated with Oracle.

Figure 1-4 Architecture for MML Integrated with Oracle

Text description of the illustration sbr81015.gif

The Oracle server session is the same type of server session used when a client such as SQL*Plus connects to the database. The media management library (MML) in Figure 1-4 represents vendor-supplied media management software library that can interface with Oracle. Oracle calls MML software routines to back up and restore datafiles to and from media controlled by the media manager.