Recovery manager (RMAN) is a command line utility used to perform backup and recovery operations. RMAN provide greater ease of management and administration of the backup and recovery operations.

1. Benefits of recovery manager

The key objective of recovery manager is to provide greater ease of management and administration of the backup and recovery operations, while maintaining superior performance and increased availability of the database. recovery manager and the oracle server minimize operational errors, by automating the backup and recovery process, and by performing multiple consistency checks throughout the procedure.

Recovery manager is a command line component (similar to sql*plus) that interacts with the oracle server code to perform backup and recovery operations. recovery manager decides how to execute backup, restore, or recovery operations based on information in the database's recovery catalog, control file, and the current state of the datafiles, then instructs and coordinates oracle server processes to perform the desired operation. recovery manager calls the oracle server to back up and recover the database rather than using operating system products such as the unix dd command.

The oracle server maintains records of all successful backups initiated by recovery manager within that database's control file. at the end of a backup, this information is propagated to an optional recovery catalog for long-term storage.

2. Features of RMAN backup

There are a number of significant benefits/Features to using recovery manager

• an increase in usability, reliability and performance
• automation of backup, restore and recovery operations
• whole database backups (or backups of any logical unit: control file, datafile, tablespace or archive log)
• open or closed backups
• two types of backup: image copies to disk or backup sets to disk or to tape with media management software
• intelligent management of the archived redo logs for both backup and recovery
• corrupt block detection
• tablespace point-in-time recovery support
• ability to catalog on disk operating system backups
• integration with oracle enterprise manager’s backup manager gui
• incremental backups at the oracle block level for high performance backup and recovery
• omission of empty blocks during backup for optimization
• recoverability redundancy when both incrementals and archiving are used
• no extra redo is generated during open database backup
• intelligent buffering with multiplexing of multiple input files for high speed tape streaming
• support for oracle parallel server backup and recovery
• ability to recover through unrecoverable operations, when using incremental backups
• o/s-independent scripting language

Automation of backup and recovery

Recovery manager automates backup and recovery by querying information in the recovery catalog, the database’s control file, and any datafiles affected by the operations requested. recovery manager decides the most efficient method of executing the requested backup, restore, or recovery operation and then issues these steps to the oracle server. recovery manager and the server achieve this by automatically identifying changes in the structure of the database, and dynamically adjusting the current operation to cater to the changes.

Restore and recovery

recovery manager also uses the recovery catalog to decide which backups are most applicable for
restoration and recovery, then hands control over to the oracle server, which performs the required actions. the user does not need to maintain records of which files were backed up or maintain historical information on the structure of the database at any point in time, as this information is inherent to the recovery catalog.

recovery manager greatly simplifies recovery by automatically identifying the most appropriate backups (full and incrementals) and archived redo logs to use, then restores and recovers them. database point-in-time recovery is made simple, as recovery manager intelligently restores only the files that existed in the database at that time.

recovery manager also backs up archived redo logs. only redo logs that have been completely archived are backed up by recovery manager. this safeguard prevents the common problem of backing up an incomplete archived redo log (i.e., backing up the log before it has been completely written by the arch process). once successfully backed up, the archived redo log can optionally be deleted by recovery manager.

Corrupt block detection

The integrity checks that are normally performed when reading a datafile to satisfy a sql operation, are also performed when creating or restoring from a backup. therefore, many types of corruption are detected and noted by the RMAN while the backup is in progress.

Checksums for additional reliability

As an additional reliability measure, a checksum is computed for each block written to a backup. the checksum is verified during restore and recovery. this makes it possible for oracle to identify whether a block in the backup has been in any way corrupted or tampered with in the time between when it was first written out to backup, and the time when it is being restored.

Skip unused blocks

Blocks that have never been written to, such as blocks above the high water mark (HWM) in a table, are not backed up by RMAN when the backup is an RMAN backupset. Traditional backup methods have no way to know which blocks have been used.

incremental backups

An incremental backup is a backup of a datafile that includes only oracle blocks that were changed since a previous incremental. performing incremental backups typically results in reduced backup size and time for restore and recovery operations.

Block-level recovery

To potentially avoid downtime during a recovery operation, RMAN supports block-level recovery for recovery operations that only need to restore or repair a small number of blocks identified as being corrupt during the backup operation. The rest of the tablespace and the objects within the tablespace can remain online while RMAN repairs the damaged blocks.

Multiple I/O channels

During a backup or recovery operation, RMAN can utilize many I/O channels, via separate operating system processes, to perform concurrent I/O.
Traditional backup methods, such as a Unix cp command or an Oracle export, are typically single-threaded operations.

Platform independence

Backups written with RMAN commands will be syntactically identical regardless of the hardware or software platform used, with the only difference being the media management channel configuration. On the other hand, a Unix script with lots of cp commands will not run very well if the backup script is migrated to a Windows platform!

Tape manager support

All major enterprise backup systems are supported within RMAN by a third-party media management driver provided by a tape backup vendor.

Support for oracle parallel server (RAC)

recovery manager is able to distribute backups, restores and recoveries over multiple instances in an oracle parallel server configuration. to do this, the dba specifies multiple connect strings in the
recovery manager backup or restore command ¾ server processes on the instances specified will then be started to perform the actions specified.

there are a number of requirements imposed by recovery manager in an oracle parallel server environment:

• recovery manager assumes all backup files are equally available and restorable on all nodes configured to be able to restore files. this is only an issue as some media management products assume that a file backed up on one node will only be restored on that node.
• archivelog backups can easily be distributed over all desired nodes, however the initial instance recovery manager connects to must be able to read the archivelog headers as a preparation for their backup, and also must be able to read the archivelogs during recovery. the requirement that the node performing the recovery is able to read archivelogs is not specific to recovery manager, but has always been required in an oracle parallel server environment.

Cataloging backups

A record of all RMAN backups is recorded in the target database control file, and optionally in a recovery catalog stored in a different database. This makes restore and recovery operations relatively simple compared to manually tracking operating system–level backups using “copy” commands.

Scripting capabilities

RMAN scripts can be saved in a recovery catalog for retrieval during a backup session. The tight integration of the scripting language, the ease of maintaining scripts in RMAN, and the Oracle scheduling facility make it a better choice than storing traditional operating system scripts in an operating system directory with the operating system’s native scheduling mechanisms.

Encrypted backups

RMAN uses backup encryption integrated into Oracle Database 11g to store encrypted backups. Storing encrypted backups on tape requires the Advanced Security Option.

Backup compression

RMAN can also use an Oracle-specific binary compression mode to save space on the backup device. Although operating system–specific compression techniques are available with traditional backup methods

There is a slight increase in CPU time during an RMAN compressed backup or recovery operation,
The amount of media used for backup may be significantly reduced, as well as network bandwidth if the backup is performed over the network.
Multiple CPUs can be configured for an RMAN backup to help alleviate the compression overhead.

Open database backups

Tablespace backups can be performed in RMAN without using the begin/end backup clause with alter tablespace. Whether using RMAN or a traditional backup method, however, the database must be in ARCHIVELOG mode.

RMAN does not support the backup of password files and other non-database files such as tnsnames.ora, listener.ora, and sqlnet.ora. However, these files are relatively static in nature, and they can easily be backed up and restored using a traditional backup method such as the Unix cp command.

3. Components of the RMAN Environment

Target database and the RMAN client are the required components.

RMAN Channels

• An RMAN channel represents one stream of data to a device type, and corresponds to one server session.
• Each channel establishes a connection from the RMAN client to a target or auxiliary database instance.
• The server session performs the backup, restore, and recovery.
• RMAN comes preconfigured with one DISK channel that you can use for backups to disk.

The Flash Recovery Area

• With Automatic Disk-Based Backup and Recovery, you can create a flash recovery area
• Automates management of backup-related files.
• Choose a location on disk and an upper bound for storage space
• Set a retention policy that governs how long backup files are needed for recovery
• DB manages the storage used for backups, archived redo logs, and other recovery-related files within that space.
• Files no longer needed are eligible for deletion when RMAN needs to reclaim space for new files.

Automatic Disk-Based Backup and Recovery

With Automatic Disk-Based Backup and Recovery, you can create a flash recovery area, which automates management of backup-related files. Choose a location on disk and an upper bound for storage space, and set a retention policy that governs how long backup files are needed for recovery, and the database manages the storage used for backups, archived redo logs, and other recovery-related files for your database within that space. Files no longer needed are eligible for deletion when RMAN needs to reclaim space for new files.

If you do not use a flash recovery area, you must manually manage disk space for your backup-related files and balance the use of space among the different types of files. Oracle Corporation recommends that you enable a flash recovery area to simplify your backup management.

Related Articals:

1. Introduction to RMAN [Part-1]
2. Backup and recovery operations using RMAN (Part-2)
3. Using RMAN Repository (Part-3)