GETTING STARTED WITH RMAN

Darl Kuhn, Sun Microsystems

Scott Schulze, Level 3 Communications

Introduction
Oracle Recovery Manager (RMAN) is a tool that DBAs can use to backup, restore, and recover their databases. RMAN
doesn't require an extra license or installation, it comes as a standard utility when you install the Oracle binaries. Although
RMAN has been available since version 8.0, many organizations have been slow to adopt it. Change can be difficult,
especially when tried-and-true database backup mechanisms have already been implemented. And no self-respecting
database administrator wants to be blindsided when it comes to backup and recovery situations. But RMAN offers numerous
advantages over the traditional techniques and thus warrants serious consideration when designing and implementing backup
strategies. This paper will help you decide whether or not to use RMAN, and then discuss architectural and implementation
decisions, before covering new Oracle9i RMAN features.

Why Use RMAN?

When your livelihood depends on your ability to back up and recover the database, why implement a technology like
RMAN? The reason is that RMAN comes with several benefits:
• Incremental backups that only copy data blocks that have changed since the last backup
• Tablespaces are not put in backup mode, thus no extra redo log is generated during online backups
• Detection of corrupt blocks during backup
• Parallelisation of I/O operations
• Automatic logging of all backup and recovery operations
• Built in reporting and listing commands
• Integration with Media Management Layer (MML)

RMAN’s incremental backup abilities could alone sway a decision for its use. The term “incremental” is used because
RMAN has the ability to only backup those database blocks that have changed since a prior backup. Why is this important?
Because the time and resources required to perform either a backup or a restore can be significantly diminished. Using this
incremental feature ensures that the resources required to perform a backup are proportional to the transactional activity that
has taken place within the database, and not to the size of the database; each block is read, but only modified blocks are
written. For large databases, this provides a significant advantage over the traditional backup methods.

When RMAN performs an on-line backup, the tablespaces are not put in backup mode. This means that there is no extra
writing of entire blocks to the redo logs. For shops that experience high transaction volumes during backups, this could be a
huge performance savings.

Corruption needs to be detected at the earliest possible stage; before its presence finds its way into our “trusted” backup files.
Prior to RMAN, common techniques would be to use full exports or perhaps DBVERIFY, each of which either has its own
limitations or performance considerations. RMAN, however, has the presence of mind to check for corruption during the
backup process; remember that each block is touched. If corruption is identified, it is logged to several dictionary tables
which can be easily scanned and reported against.

RMAN does not execute commands in a parallel fashion. RMAN will complete each command before it goes on to the next
one in a serial fashion. Why is it then that parallelisation is touted as a benefit to using RMAN? It is because RMAN has the
ability to allocate multiple processes at the same time to file copy operations. Thus, if you have multiple I/O devices, you can
substantially reduce the time to backup or restore files.

With traditional mechanisms, the onus is put on the DBA to record the specifics of each backup operation in case the backup
is required for recovery purposes. RMAN, on the other hand, records the specifics of each backup operation within the

www.rmoug.org RMOUG Training Days 2002

Getting Started with RMAN Kuhn and Schulze

control files of the database that is being backed up. Having this information readily available not only facilitates database
file restoration but also allows for the easy generation of risk assessment reports.

Being able to determine the status of backup, restore, and recovery operations is of paramount importance to the DBA.
RMAN comes with default, out of the box reporting facilities. For example, you can use RMAN commands to generate lists
showing what backups have been made, when they were made, and the status of each. You can also write your own SQL to
query the data dictionary views and report on all activity associated with backup and recovery.

There are several companies that provide software to help with the management of reading and writing files to tape. This 3rd
party software is often called the Media Management Layer (MML). The MML interfaces with your O/S to read and write
files to tape, and it also keeps track of what files are on what tapes. RMAN can be configured to communicate directly with a
MML. This relieves you from having to write your own code to do I/O with the tape devices and track what files went to
which tape. In the event a file needs to be restored, this relieves the System Administrator, DBA, or tape operator of having
to query the tape system for the required files.

RMAN Architecture
You should now have a good understanding of why you would want to use RMAN. If you are going to use RMAN, it is
important that you understand how the pieces work together, and how it interacts with your Oracle database. This section
details all of the critical components of RMAN:
• RMAN executable
• Server processes
• Channels
• Target database
• Backups, backup sets, and backup pieces
• Recovery catalog database (optional)
• Media Management Layer (optional)

RMAN Executable
The RMAN executable, named rman, is the program that you use to manage all backup and recovery operations. You interact
with the RMAN executable to specify backup and recovery operations that you want to perform. The rman executable then
works with the target database, starts the required server processes, and performs the operations that you requested. Finally,
the RMAN executable records those operations in the target database's control file, and in the recovery catalog database (if
you are using one).

Server Processes
RMAN server processes are background processes started on the server that are used to communicate between RMAN and
the databases being used, and also to communicate between RMAN and any I/O devices (disk or tape) being used. RMAN
server processes do all the work for a backup or restore operation. A typical backup, restore, or copy operation will result in
several server processes being started.

Channels
A channel is an RMAN server process that is started when there is a need to communicate to an I/O device, such as a disk or
tape. A channel is what reads and writes RMAN backup files. Anytime you issue an RMAN allocate channel command, a
server process is started on the target database host. It is through the allocation of channels that you manage I/O
characteristics such as:
• Type of I/O device being read or written to
• Maximum size of files created on I/O devices

www.rmoug.org RMOUG Training Days 2002

Getting Started with RMAN Kuhn and Schulze

• Number of processes simultaneously accessing an I/O device

• Maximum rate at which database files are read
• Maximum number of files open at a time

Target Database
The target database is the database that RMAN is going to operate on to perform backup, restore, and recovery operations.
This is the database that owns the datafiles, control files, and archived redo files that are being backed up and recovered.
RMAN does not backup the on-line redo logs of the target database.

Backups, Backup Sets, and Backup Pieces

What physically gets created when you issue an RMAN backup command? RMAN creates backup sets which are logical
groupings of physical files. The physical files that RMAN creates on your backup media are called backup pieces. When
working with RMAN, you need to understand that the following terms have very specific meanings:

RMAN backup
Not surprisingly, a backup is created anytime you run the RMAN backup command. A backup consists of one or more
backup sets.
Backup set
There can be one or more backup sets created anytime you issue a backup command. An RMAN backup set is a logical
grouping of the physical files associated with the backup. A backup set can have one or more backup pieces within it.
Backup piece
A physical file created by RMAN during a backup. Backup pieces are files written to your backup medium. Backup piece
files contain physical blocks from the target database's datafiles, archived redo log files, and control files. RMAN is the only
tool that can make use of backup piece files. When RMAN constructs a backup piece from datafiles, there are a several rules
that it follows:
• A datafile cannot span backup sets
• A datafile can span backup pieces
• Datafiles and control files can be in the same backup set
• Archived redo log files are never in the same backup set as datafiles or control files

Recovery Catalog Database

The recovery catalog database is an optional information store for RMAN metadata concerning backup and recovery
activities performed against the target database. The recovery catalog database consists of three components:
• Usually a separate database from the target database
• A schema within the recovery catalog database
• Objects within the catalog schema that contain data pertaining to RMAN backup and recovery operations performed
on the target

The catalog is typically a database that you build on a different machine than your target database. The reason for this is that
you don't want a failure on the target machine to interfere with your ability to use the recovery catalog. If both recovery
catalog and target are on the same box, a single hardware or media failure could put you in a scenario where you would not
be able to recover your target database. Inside the catalog database is a special schema containing the tables used to store
metadata information about RMAN backup and recovery activities.
Why is the recovery catalog considered optional? When RMAN performs any backup operation, it writes information about
that task to the target database control files. Therefore, RMAN does not need a catalog to function. If you choose to
implement a recovery catalog database, then RMAN will additionally store the backup metadata in the catalog. A common

www.rmoug.org RMOUG Training Days 2002

Getting Started with RMAN Kuhn and Schulze

misconception is that the catalog stores the physical backup files for the target database. The catalog only contains
information about the backups of the target database - not the physical backup files themselves. The advantage that a catalog
brings to the table is that it can be used with many different target databases. This advantage allows you to manage all target
backup and recovery activities from a centralized location. Additionally, a catalog allows for a longer history of backup
operations.

Media Management Layer

The Media Management Layer (MML) is a 3rd party piece of software that manages the reading and writing of files to and
from tape. A MML also keeps track of what O/S files have been written to what tapes. If you want to backup your database
files to tape, RMAN requires the use of a MML. If you use RMAN to backup database files only to disk, then you do not
need a MML. There are several reasons why you might want to backup files to tape, and thus require to use a MML:
• Tape is more cost effective than disk, therefore your business requirement might be to backup all database files to
tape (especially true for large databases)
• Your wish to store your backup files somewhere other than on the same server as the target database, thus reducing
your risk of losing both the target database and backup files at the same time

When backing up files to tape, an MML keeps track of what files were written to which tapes. In the event that restoration of
a database file is required, RMAN will send to the MML a list of the database files that are required in order to restore the
database. The MML will then determine which tapes store the required database files. The MML will then retrieve the
requested files, send them back to RMAN, and RMAN will restore the database.

Comparison of a Hot Backup to RMAN On-line

To drive home some of the points, lets compare a hot backup with an RMAN on-line backup. Table 1 illustrates the
traditional method to an Oracle8i and Oracle9i RMAN implementation. When reviewing this table, take a mental note of
complexities that would be involved in writing an on-line (hot) backup script. Depending on a DBA’s skill at scripting, an
on-line backup routine can be fairly complex since there is a change of context between those tasks that need to be
accomplished from an Oracle perspective and those tasks that need to be accomplished from an O/S perspective.

Table 1. On-Line Backup Comparison

Traditional On-Line (hot) Backup
Identify tablespaces to backup
Identify datafiles to backup
Place tablespaces into backup mode
Use an O/S copy mechanism to copy
the datafiles
Switch the on-line redo logs
Backup the archived redo logs
Backup the control file
Oracle8i RMAN On-Line Backup
RMAN provides this functionality
RMAN provides this functionality
Not necessary
Accomplished with the backup
command
SQL is used from within RMAN to
switch the on-line redo logs
A separate RMAN backup command is
executed
SQL is used to backup the control file
Oracle9i RMAN On-Line Backup
RMAN provides this functionality
RMAN provides this functionality
Not necessary
Accomplished with the backup
command
The on-line redo logs are switched as a
result of the backup command
The archived redo logs are backed up as
a result of the backup command
Issue this command just once and it
will persist across all RMAN sessions
RMAN> configure controlfile
autobackup on;

www.rmoug.org RMOUG Training Days 2002

Getting Started with RMAN Kuhn and Schulze

As you can see from this table, RMAN provides the functionality that the DBA would otherwise be responsible for when
implementing an on-line backup routine. When boiling this table down to functional scripts for RMAN with Oracle8i and
Oracle9i, they would respectively look something like:

RMAN> run {
2> allocate channel d1 type disk;
3> backup incremental level 2
4> format '/backupdir/rm_l_0_%d_%t_%U.bus'
5> database include current controlfile;
6> sql "alter system archive log current";
7> release channel d1;
8> allocate channel d1 type disk;
9> backup format '/backupdir/rm_arch_%d_%t.bus' archivelog from time 'sysdate - 2';
10> release channel d1;
11> sql "alter database backup controlfile to ''/backupdir/bckup_ctlfile.ctl'' reuse";
12> }

Well, that is pretty simple but let’s compare it to an Oracle9i equivalent:

RMAN> backup database plus archivelog;

Wow! More on Oracle9i features in a bit.

Implementation Decisions
Before you use RMAN, there are several key implementation decisions that you should consider. The major implementation
decisions revolve around some optional components of RMAN, specifically:
• Implementing a recovery catalog or not
• Implementing an MML or not

Catalog or Just Control File

One of the first decisions you'll have to make is whether or not to use a recovery catalog. The first point to make is that the
recovery catalog is an optional component and that RMAN can be successfully implemented without a catalog. Here is a note
from Oracle's 9i RMAN documentation, "RMAN works perfectly well without a recovery catalog. In fact, the recovery
catalog receives all its information from the control file."
Furthermore, you could argue that the recovery catalog adds a great deal of complexity to your backup and recovery
architecture because it adds another network connection, server, and database that need to be accessed in the event of a
backup or restore operation. So if you are trying to keep your backup and recovery strategy as simple as possible, why would
you use a recovery catalog? Here are some reasons to consider:
• Need to store information about backups for long periods of time
• Have a large numbers of datafiles (thousands)
• Desire to use scripts stored in the catalog
• Desire a centralized repository for all database backup operations
• Need a catalog to perform an RMAN restore of controlfiles (Oracle8i only)

If you decide not to implement a catalog, you may need to increase the parameter control_file_record_keep_time, because
that controls the length of time that RMAN information is stored in the catalog before it is overwritten. Also if you do not use
a catalog in an Oracle8i environment, ensure that you are backing up your controlfile outside of RMAN (i.e. SQL alter
database backup controlfile command).

www.rmoug.org RMOUG Training Days 2002

Getting Started with RMAN Kuhn and Schulze

Tape or Disk
The MML is another optional RMAN component. Integrating with a MML allows you to write files directly to any media
device supported by the MML. Usually you use a MML when you have a need to have RMAN write the backup files directly
to tape. Here are the steps involved with a backup to tape:
• Configure RMAN to backup to tape
• Implement MML
• Set channel type sbt_tape

The advantages of tape are that it allows for large amounts of database to be stored in the most economically feasible manner.
Additionally if you are writing to tape, the MML keeps track of a long history of what database files have been backed up to
which tapes, thus alleviates you of having to track that information.
One of the disadvantages of using a MML is that it adds complexity; it adds another moving part in that you now have a tape
device, 3rd party software, and a network connection added to your backup and recovery architecture. This can lead to more
frustration during your RMAN implementation and more headaches when maintaining your implementation.
If you don't implement a MML, then you are required to setup RMAN to write the backup files directly to disk. The steps
involved with this are:
• Set channel type disk
• Let O/S backup scrape files to tape
• Sometime after O/S backup has completed, delete RMAN backup files from disk

The advantages of a disk based implementation are that is straightforward to set up and maintain. You have fewer moving
parts to maintain and manage. Additionally, disk access is usually much faster than tape access, so the time required to do a
backup and restore are much shorter.
The main disadvantage to writing backup files directly to disk is that disk space is usually finite, and therefore you cannot
afford to store months and months of backup information on disk. In the scenario where you let the O/S backups copy the
RMAN backups from disk to tape, and then you delete your RMAN backups from disk, if you need those files for recovery it
is then up to you to inform the tape operator which files are required for restoration.

RMAN Oracle9i New Features

Oracle9i comes with new user-friendly features and performance enhancements to RMAN and also more flexibility in
backup, restore, and recovery scenarios. Some of the major improvements are:
• Streamlined syntax for backup and restore
• Configurable persistent channel settings for your target environment
• Automatic backup of control file
• Improved options for backing up archived redo logs
• Performance optimization of backup and restore operations
• Block level recovery

Prior to Oracle9i, you were required to wrap backup, restore, and channel allocation operations within the RUN{} command
syntax. This syntax can be a bit cumbersome, especially if you have to manually type in all of the required commands during
a late night recovery scenario. With Oracle9i you no longer have that obligation. For example, the commands to restore and
then recover your database now can be cut down to:

RMAN> restore database;

RMAN> recover database;

www.rmoug.org RMOUG Training Days 2002

Getting Started with RMAN Kuhn and Schulze

This is made possible through a streamlined syntax and also the ability to configure channel settings that remain the same
from one RMAN session to the next.

Configure Persistent Channel Configuration

One of the nice new features that makes things easier with your backup and recovery operations is the ability to configure
persistent RMAN channel settings. Via the new RMAN Oracle9i CONFIGURE command, you can set defaults for channel
file formats, degree of parallelism, device type, maximum read rate, maximum piece sizes, and so forth. The channel
configuration settings are stored in the target database control file, thus you do not have to reissue channel configuration
commands each time you issue a backup, restore, or copy command. The advantage to this is that you lessen the amount of
code required to carry out an RMAN operation, which in turn lessens the likelihood of DBA introduced errors. Let’s compare
a standards backup operation in Oracle8i with Oracle9i. Shown here is a standard Oracle8i backup script with the necessary
run{} command and channel configuration settings:

RMAN> run {
2> allocate channel d1 type disk;
3> allocate channel d2 type disk;
4> setlimit channel d1 kbytes 1800000;
5> setlimit channel d2 kbytes 1800000;
6> backup format '/ora01/bck/rman%U.bus' database;
7> release channel d1;
8> release channel d2;
9> }

To achieve the same result in Oracle9i , first you specify your channel characteristics with the following two CONFIGURE
commands:

RMAN> configure device type disk parallelism 2;

RMAN> configure channel device type disk format = "/ora01/bck/rman%U.bus"
2> maxpiecesize 1800M;

And from that point forward, anytime you issue a backup command, RMAN automatically allocates two disk channels and
creates the backup piece files with the preferred file format and specified size. After you configure your channel settings, the
Oracle9i backup command becomes:
RMAN> backup database;

To display only the RMAN configuration settings that you have specifically set in your target environment, issue a query
against the new v$rman_configuration view:

SQL> select * From v$rman_configuration;

If you want to see all of your channel configuration settings use the new SHOW ALL command. For example, this command
displays your current target database channel settings:

RMAN> show all;

Autobackup of Control File

Another new ease-of-use-feature provides you with the capability to have your control file automatically backed up. Once the
control file autobackup feature is enabled, anytime you kick off a BACKUP or COPY command, your control file is
automatically backed up. You can enable this option by using the CONFIGURE command as follows:

RMAN> configure controlfile autobackup on;

There are two big advantages in using this feature to backup your control file:

www.rmoug.org RMOUG Training Days 2002

Getting Started with RMAN Kuhn and Schulze

• Ensures your control file is backed up frequently

• Relieves you of being reliant on a recovery catalog in certain restore control file situations

When AUTOBACKUP is enabled, you are certain to have a backup of your control file each time you initiate a backup
operation. This alleviates you of having to manually type in or script these commands each time you want to backup the
control file.
With Oracle8i, Oracle recommended implementing RMAN with a recovery catalog. One of the important reasons for using a
recovery catalog was that it gave you the capability to recover your control file in the situation where you had lost all control
files. With Oracle8i, in the event you lost all of your control files, you were required to connect to a recovery catalog when
using RMAN to restore them. With Oracle9i, if you have enabled the autobackup of your control files, you are no longer
required to connect to a recovery catalog to restore your control files. This provides you with the flexibility of being able to
recover control files in the event your recovery catalog is unavailable.

Automated Archive Redo Log File Backup Tasks

Archived redo log files are an important part of a backup and recovery strategy. Oracle9i RMAN gives you some new
alternatives for backing up these essential files. For example, before Oracle9i, you had to manually script your backups to
switch the on-line redo logs and backup any archived redo logs generated during the backup. Here’s a typical Oracle8i script
that does that:

run {
allocate channel d1 type disk;
backup database format ‘/ora01/bck/rman_%U.bus’;
sql “alter system archive log current”;
backup archivelog all format ‘/ora01/bck/archlog_%U.bus’;
release channel d1;
}

Archived redo logs are backed up in this fashion to make sure that the database datafiles can be recovered to a consistent
state. Now with Oracle9i, this can all be automated via the BACKUP PLUS ARCHIVELOG command. For example, if you
want to backup all database files and additionally the archived redo log files, you would use the following command:

RMAN> backup database plus archivelog;

When you use this command RMAN performs the following commands for you in this order:
1. Runs ALTER SYSTEM ARCHIVE LOG CURRENT command
2. Issues the BACKUP ARCHIVELOG ALL command
3. Backs up all files as specified by the BACKUP command
4. Runs ALTER SYSTEM ARCHIVE LOG CURRENT command
5. Backs up all archived redo logs that have been generated during the backup

Backup and Restore Performance Improvements

Oracle9i RMAN backup and restore operations have slightly changed to improve performance. Backups can now be
configured to skip files that have not changed since the last backup. This feature is enabled with the CONFIGURE
OPTIMIZATION command as shown:

RMAN> configure backup optimization on;

This new command tells RMAN to check previously backed up files and examine the timestamp and SCN, and if no changes
are detected, then the file is not backed up again. This could be especially handy when backing up archived redo log files,
because these files are static and do not change.
The RESTORE command has also been enhanced to improve performance. Previous to Oralce9i, when you issued a restore
command, RMAN copied back all of the specified datafiles whether they needed media recovery or not. With Oracle9i,

www.rmoug.org RMOUG Training Days 2002

Getting Started with RMAN Kuhn and Schulze

before RMAN restores a file it checks to see if the file is in the proper location and also examines the file header. If RMAN
finds the correct information in the file header, it will not restore the datafile. The benefit of this is that if you issued a
RESTORE DATABASE command and only one file was missing or corrupt, that file would be the only file restored, thus
saving you time during a full database recovery. You can override this default behavior via the new FORCE option of the
RESTORE command.

Recover at the Block Level

With Oracle8i, the lowest level of recoverability was at the datafile level. That changed in Oracle9i with the new RMAN
BLOCKRECOVER command. This command gives you the capability to recover isolated corrupt blocks, even while the
datafile is online. RMAN as a normal part of doing a backup or copy operation will check each block for corruption and log
the results. Corrupt media can then be queried from the v$backup_corruption and v$copy_corruption views. To report on
corrupt blocks that have been detected during an RMAN copy or backup operation:

SQL> select * from v$copy_corruption;

SQL> select * from v$backup_corruption;

And then to recover all blocks reported as corrupt from the above queries, use the CORRUPTION LIST option of the
BLOCKRECOVER command:

RMAN> blockrecover corruption list;

Alternatively, you can recover specific blocks. In this example, block number 20 of datafile number 3 was detected as
corrupt and is recovered as follows:

RMAN> blockrecover datafile 3 block 20;

The advantage to block level recovery is that if you discover you have corrupt blocks in a large datafile, instead of having to
restore and recover the entire datafile, you can now selectively recover only the bad blocks. This could significantly reduce
the amo unt of time it takes you to restore and recover. Block level recovery is not intended to replace datafile recovery, it
should be used in cases where you have small numbers of isolated corrupt blocks.

About the Authors

Darl Kuhn (darl.kuhn@sun.com), an Oracle DBA and software developer with 14 years experience, is a senior DBA with
Sun Microsystems. Before joining Sun, his work as a consultant ranged from database administration to custom application
development. Darl is the coauthor of the O'Reilly book RMAN Pocket Reference, and enjoys learning and exploring new
Oracle technologies.

Scott Schulze (scott.schulze@level3.com), an Oracle DBA and software developer with 12 years experience, is a senior DBA
at Level(3) Communications. Scott has worked for several companies in the telecom and data storage industries. Scott is the
coauthor of the O’Reilly book RMAN Pocket Reference. He has also taught Oracle relational modeling and PL/SQL courses
for the graduate department of Computer Information Systems at Regis University.

www.rmoug.org RMOUG Training Days 2002