COMPELLING REASONS TO USE ORACLE9I R2 RMAN
Wayne Linton, I.S.P., OCP, Shell Canada Limited
Recovery Manager (RMAN) is Oracle‟s server-managed database backup and recovery utility. Although it has been
available since the release of Oracle8, many DBAs continue to perform their database backups (and recoveries) using
old „tried-n-true‟ manual techniques. DBAs may be forgiven for taking a pass on early versions of the product, but
the functionality and reliability of Oracle9i R2 RMAN available today demands another look.
We have all faced a restore and recovery situation at sometime in our DBA careers (and if not yet, you will !). With
every restore come the questions:
What backups do I need to effect this particular recovery?
Where are the backup files located?
Do I have ALL the archive logs required?
Am I confident that there is no corruption in the backups?
How do I know if this database is actually recoverable?
The RMAN utility can answer these questions for the DBA, and Oracle9i R2 RMAN does so rather nicely.
A MATTER OF TRUST?
RMAN is tightly integrated with the database and is fully supported by Oracle. RMAN is aware of the structure of
your database, variably-blocksized tablespaces, which blocks have never been used and which ones have already been
backed up. It knows what blocks of data are being worked on while the backup is taking place (fractured block) and
it will automatically reread those blocks. It might be obvious to say, but Oracle knows everything about your
Which begs the question: Since you trust the management of your database to Oracle, why would you not trust the
management of your database backup and recovery to Oracle?
WHAT IS RMAN ?
The RMAN backup and recovery utility evolved from Oracle7‟s Enterprise Backup Utility and has been vastly
improved upon from its earliest Oracle8 versions. It is distributed as part of every database and is not separately
licensed. It can be invoked at the operating system command line or through the Enterprise Manager GUI wizards.
RMAN requires no further installation if used without a catalog, and will store all relevant recovery information in the
controlfile of the database. It is recommended, however, that a catalog be created to store the recovery metadata for
several databases in a separate instance, preferably on a separate machine (your OEM repository instance would be a
Paper # 36487
good place for the RMAN catalog!). It is not difficult to set up this catalog, but care must be taken to ensure that the
catalog version is compatible with the database versions being backed up. Check out the compatibility matrix on
Metalink for details.
LISTS AND REPORTS
Whether you use the catalog or not (NOCATALOG is the default), RMAN can list and report on this metadata to
determine such things as:
The recoverability of the database
Whether there are any tablespaces in need of backing up
What backups are obsolete and can be deleted
What backups of datafiles, archive logs, controlfiles and spfiles exist and where they are located
SERVER-MANAGED BACKUP AND RECOVERY
The old „tried-n-true‟ method of performing backup and recovery is a completely manual process and as such is
prone to error. Backup jobs are typically cobbled together with a combination of Oracle utility commands wrapped
inside OS-specific scripts. The scripts are usually coded in such a way that the backup SQL commands are
dynamically generated from data dictionary views, spooled to a file, and then executed. To dynamically split up the
backup stream into multiple jobs for parallel execution is
polling / monitor
RMAN spawns separate server processes to perform the
backups. It knows what files are to be backed up, and target home
will read and write in parallel with just a simple DB RMAN binary RMAN
configuration parameter setting. The RMAN client server processes Catalog
connects to the target database (and optional catalog) via channels Target
Net8 and can run on a machine different than the cf version
database. [The version of the RMAN executable MUST media compatible
match that of the database, so for this reason I always layer
run RMAN from the same ORACLE_HOME and on
the same machine as the target database.]
The RMAN restore and recover operations similarly spawn multiple server processes to perform the reads of the
backup files and writes to the database.
RMAN is aware of blocks that have never been used and excludes them from backup. It also knows what blocks
have already been backed up and will skip them when performing incremental backups. Since it is integrated with the
database, RMAN knows when a block being backed up is also being changed (fractured block) and will automatically
reread that block to back it up. This eliminates the need to use the BEGIN BACKUP and END BACKUP
commands for consistent online backups, and the additional amount of redo normally generated with user-managed
backups is avoided.
Paper # 36487
Backups are written to disk by default, but an API is available to facilitate writing directly to tape. This API is called
the Media Management Layer (MML). The Legato MML is distributed with RMAN, but other vendors have MML
modules specific for their technologies that are licensed separately and directly from them. A current list of vendors
participating in the Backup Solutions Program can be found at http://otn.oracle.com/deploy/availablity .
RMAN supports complete and incomplete recovery, tablespace point-in-time recovery (TSPITR), database
duplication for cloning and the creation of standby databases. I can not cover all of the many features of RMAN
here, and I point you to the reference material mentioned at the end of this paper.
COMPELLING REASONS TO USE ORACLE9I R2 RMAN
I want first to highlight just a few of the basic features of RMAN, and then delve into what I believe to be the most
significant of the new and advanced features available in the latest release. There are many good reasons to upgrade
your databases to 9iR2, and when you do I think you will find the following points compelling reasons to use RMAN
as your databases backup and recovery solution.
Although the items are numbered, there is no implied degree of importance. The first five points are basic to all
RMAN versions (for the most part), but they are still compelling reasons to move your manual backup processes to
server-managed RMAN. The rest of the items pertain to 9i and 9iR2 features and enhancements that are sure to
#1 RMAN IS FULLY INTEGRATED WITH THE DATABASE, AND FULLY SUPPORTED BY ORACLE
The fact that RMAN is integrated with the database is significant. Oracle knows better than anyone else the internals
of its database. And who but Oracle knows what new features are forthcoming that a server-managed backup and
recovery solution would need to handle? RMAN knows what Oracle knows about the database – everything! This
includes the ability to know when a block is fractured during backup and the ability to handle that situation. It means
that RMAN can tell when blocks are used or changed or even if the state of a file is such that it doesn‟t need to be
restored or backed up. It knows about standby databases and can even recover the primary database from a backup
taken on the standby database. It knows about RAC.
And when you run into problems backing up or recovering your database, it is comforting to know that you can call
on support from the same people who support the database.
#2 RMAN SUPPORTS INCREMENTAL BACKUPS
Because RMAN knows what blocks have been backed up and when (by SCN), it is possible to set up a process
whereby only those blocks that have changed are backed up. This forms the basis of a multi-level incremental (and
cumulative) backup scheme.
Depending on the operational characteristics of your database, incremental backups can save backup storage space
and reduce the amount of time needed for both backup and recovery. But incremental backups do not necessarily
benefit all types of databases.
Paper # 36487
Take for example a database where the majority of blocks in
the database change daily. Nothing is gained with an
incremental backup as virtually the entire database will be
backed up in any event. But in a database where little of the
data changes over time, incremental backups could prove to
be most beneficial.
It is important to know that every block in the database is
read during an incremental backup regardless of how much
change has taken place. This is the only way for RMAN to
detect which blocks have changed and are in need of backup.
The side benefit is that every block is checked for corruption
along the way!
Incremental backups are not restricted to databases that are running in archivelog mode. A database in noarchivelog
mode can also participate in an incremental backup scheme, but must be an offline backup taken with the database in
the mount state.
#3 ONLINE BACKUPS SIMPLY & EFFICIENTLY
Much of this compelling reason has already been mentioned but is worth summarizing once again.
Because RMAN can detect fractured blocks and reread them, there is no need to use the BEGIN-END BACKUP
commands associated with the user-managed backup processes. This results in reduced redo generation and
eliminates the dynamic scripts that generate the backup command stream. Further, multiple output streams
(channels) can be used to write to multiple backup devices (disk or tape). To do so is as simple as setting a
configuration parameter (more on this later).
Muliplexing the backupset is accomplished by the FILESPERSET keyword. This causes multiple datafiles to be read
in parallel and the data blocks interleaved with each other into one backupset file. Now is a good time to mention
that the format of RMAN backupsets is proprietary and you must use RMAN to restore them.
RMAN can, however, be instructed to create backup copies (rather than backupsets) which in effect creates a backup
datafile image on another disk (not tape) which can be used directly in a recovery operation without restoring.
One of the problems traditionally faced with user-managed online backups is the archiving of the redo generated
during the hot backup (from the first BEGIN BACKUP to the last END BACKUP). This includes the current redo
log. The manual process must handle the log switching, wait for it to be completely archived, then back up this
archived log in order to have a consistent recovery package. This can be problematic but RMAN takes care of all this
rather nicely as we will see later.
Paper # 36487
#4 RMAN CAPTURES & REPORTS ON BACKUP AND RECOVERY METADATA
The controlfile records all log switches and archive logs and backups in the controlfile. Special attention needs to be
given to the CONTROL_FILE_RECORD_KEEP_TIME parameter. This parameter defines the number of days of
recovery information to retain in the controlfile after which time it is recycled and over-written. It is recommended
that this parameter be set to 1 day more than the number of days of backups you want to keep.
You can retain more metadata including that of previous database incarnations by creating an RMAN catalog (a
onetime process) and registering each database to the catalog. By connecting to both the target and catalog databases
RMAN will record and retain the metadata in both the controlfile and the catalog, but it will be retained in the catalog
based on the retention policy configuration parameter (more on this later). If for some reason the catalog can not be
connected to during a backup run, 9iR2 RMAN will continue with the backup and record the metadata in the
controlfile. The next time RMAN connects to the catalog the metadata will be resynchronized from the controlfile.
There are a number of enhancements in the 9iR2 RMAN reporting commands, and work was done to improve the
consistency of syntax across the reporting command set. The LIST command can be used to display information
about what backups are available, and where they are located. The REPORT command analyzes the metadata and
reports the status of your database or backups, for example:
REPORT NEEDS BACKUP
Now THAT is useful information!
#5 RMAN IS FREE!!
Worth mentioning – RMAN is included with your database license fee. 3rd Party tools license their products based on
the number of gigs of data being backed up, or number of databases, or number of servers. RMAN is free and is
without restriction on size or number of databases or servers. Today‟s 9iR2 RMAN competes extremely well in the
server-managed backup and recovery marketplace. You would have to present some really good reasons to your
management if you chose to pay for functionality that is already included with the database.
Although RMAN is free, the MML interfaces to vendor media are not. As previously mentioned, the Legato media
management layer (MML) is distributed with RMAN, but if you wish to write to tape and use a different media
vendor, you will need to license their MML product separately. Check out http://otn.oracle.com/deploy/availablity
for a list of participating vendors.
#6 RMAN 9I USES PERSISTENT CONFIGURATION PARAMETERS
Much of what has been discussed so far is pretty close to being basic functionality that is available in 8i versions of
RMAN. What separates 9i from 8i, and makes 9i RMAN so much more usable are Persistent Configuration
With these parameters, much of the verbose scripting required in 8i RMAN backups can be eliminated. There are a
Paper # 36487
number of these parameters, a special few of
which I find compelling reasons to use 9iR2
RMAN and I will mention them in the sections to 8i vs 9i RMAN Backup Script
follow. Suffice to say that many lines of 8i
RMAN scripting can be condensed to a single allocate channel d1 type disk; backup database
incremental level 0
9iR2 RMAN command as simple as: allocate channel d2 type disk;
allocate channel d3 type disk; plus archivelog all delete input;
sql "alter system switch logfile";
BACKUP DATABASE; incremental level 0
filesperset 5 (database include current controlfile);
sql "alter system archive log current";
Now THAT‟S nice! format '$HOME/BACKUP/%d_%t_%s_%p.bus'
(archivelog all delete input);
release channel d1;
release channel d2;
release channel d3;
# 6A CONFIGURE RETENTION POLICY
One of the basic features missing from 8i RMAN is the ability to act upon the information provided by the REPORT
OBSOLETE command. There is no DELETE OBSOLETE command equivalent. I was forced to conjure up some
manual process to delete the OS backup files when I thought they were no longer needed, and then CROSSCHECK
the catalog against the OS files so that RMAN would clean up its catalog. Not a pretty process.
Now with 9iR2, you can configure a RETENTION POLICY upon which RMAN will base its obsolete backup
determination. This policy can be based on the number of redundant backups to keep, or on a recovery window
specified as the number of days of backup to keep
CONFIGURE RETENTION POLICY TO REDUNDANCY 2;
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
Now it is easy to cleanup obsolete backups from both the catalog and the OS file system with a single command:
For me, this was THE best new feature in 9iR2 RMAN!
# 6B AUTOMATIC CHANNEL ALLOCATION AND PARALLELISM
In 8i RMAN whenever you want to interact with the OS file system you have to allocate a channel. If you want to
write out to three disk drives in parallel, you allocate three channels. And at the end of the run, you release all three
channels. This is also required for some catalog maintenance work. It‟s a pain in the neck!
In 9i RMAN, these same three channels can be automatically allocated by setting the configuration parameter
CONFIGURE DEVICE TYPE DISK PARALLELISM 3;
Paper # 36487
RMAN names the channels, allocates them, and at the end of the job releases them automatically. The configuration
parameter is remembered (stored in the controlfile) and is used again in subsequent RMAN jobs.
# 6C AUTOMATIC BACKUP OF THE CONTROLFILE AND SPFILE
In 8i you have to specifically backup the controlfile (unless you are backing up the system tablespace). Between
backup runs if you make structural changes to your database, RMAN does not know about them and in the case of
restore and recovery this can present a problem. (Oracle recommends that you always multiplex your controlfiles on
separate disks, and backup your controlfile whenever you make a structural change to your database).
With 9i RMAN‟s CONFIGURE CONROLFILE AUTOBACKUP ON; any structural change will automatically
result in Oracle taking an RMAN backup of your controlfile!! You don‟t need to invoke RMAN, you don‟t need to
do anything! It‟s done automatically and the event is recorded in the alert log. Now how nice is THAT!?
And if your database is started with a persistent server parameter file (SPFILE), it will also be included in this backup.
Another good reason to use an SPFILE! Note that the regular init.ora pfile is not backed up by RMAN.
# 6D BACKUP OPTIMIZATION
You can skip over read-only tablespaces by specifying:
CONFIGURE BACKUP OPTIMIZATION ON;
During backup, if RMAN determines that the file has not changed since it was last backed up, it will be skipped
entirely. This determination is made through examination of the file header only. You can force backup of all
datafiles regardless of its file header status by clearing this parameter.
#7 AUTOMATIC ARCHIVING AND BACKUP OF THE CURRENT REDO
During an online backup, it is vital that you capture ALL the redo that was generated while the backup was in
progress. This includes the final set of redo sitting in the current redo log. As mentioned earlier, this can be
problematic to do with manual processes to know for certain that you capture everything you require. In 9iR2
RMAN this is all done for you simply with the command:
BACKUP DATABASE PLUS ARCHIVELOG;
Archive logs are also checked for corruption, and if multiple archive destinations exist, RMAN will interrogate them
all in search of a good archive log. Only one copy of the archive logs will be backed up.
#8 CLEARING OF MULTIPLE ARCHIVELOG DESTINATIONS
In 8i, you can clear out the archive log destination after backing them up with the syntax:
ARCHIVELOG ALL DELETE INPUT
Paper # 36487
But if you have multiple archive log destinations, only one of them is cleared. The archive logs in the other
destinations remain. 9iR2 has corrected this shortcoming and all destinations will now be cleared out with the
BACKUP DATABASE PLUS ARCHIVELOG DELETE ALL INPUT;
#9 LESS VERBOSE RUNTIME MESSAGES
The 8i RMAN message stream is cluttered with informational messages of questionable value, and every message is
RMAN-xxxxx prefixed. This makes for a lot of „visual noise‟ when trying to look through the log for relevant
information. 9iR2 has addressed this by making the RMAN-xxxxx message prefix optional (off by default) and
reducing the quantity of informational messages.
# 10 BLOCK MEDIA RECOVERY
I contemplated moving this compelling reason near the top of the list as it is perhaps the most significant high
availability improvement to RMAN in 9iR2. This feature permits the recovery of corrupted blocks within a datafile
without having to restore the entire file, and without having to take the file offline. The file remains online and
available for use. This feature is useful when there are relatively few blocks that are corrupted in the datafile. If there
are many, you might consider recovering the entire file.
Performing a BACKUP or a BACKUP VALIDATE will check every datafile block for corruption. If a block is
found to be corrupted, it is listed in the alert log and an entry is inserted into the view v$database_block_corruption.
The block recovery can be performed by specifying the file and block numbers as listed in the alert log:
BLOCKRECOVER DATAFILE 8 BLOCK 20;
or by specifying a “corruption list” clause that processes all entries in the v$database_block_corruption view:
BLOCKRECOVER CORRUPTION LIST;
# 11 RMAN BACKUP AND RESTORE JOBS ARE RESTARTABLE
It always seems to be the case that if a backup job fails, it‟s near the end of the job. Starting the backup all over again
is a waste of time and machine resources. It‟s even more painful when a restore job fails after restoring the majority
of datafiles successfully and people are breathing down your neck asking when the database will be available.
With RMAN 9i, both backup and restore operations are restartable saving both time and resources. Should a backup
fail, you can restart the job and instruct RMAN to backup only those datafiles that have not been backed up since a
specified time. If your overnight backup job fails, you can submit a job in the morning to finish off the backup of
only those datafiles that were missed:
BACKUP DATABASE NOT BACKED UP SINCE TIME „18-AUG-2003 03:00:00‟;
Similarly, should a job fail after restoring most of the datafiles successfully, simply resubmit the restore job. RMAN
Paper # 36487
will examine the datafile headers and only those that are in an incorrect state or location will be restored. The ones
already restored successfully will be skipped over.
Provision is made for forcing the restore of datafiles even if RMAN thinks they are in a good state. This is done with
RESTORE FORCE …
# 12 RMAN WILL STAGE ARCHIVE LOGS DURING RECOVERY TO SAVE DISK SPACE
It is not uncommon for a recovery to require more archive logs to be loaded onto the archive log destination disk
than there is space to hold them. Manual recoveries would handle this by applying the archive logs, deleting them,
loading up the new set of logs, applying them, and so forth until the recovery is complete.
RMAN 9iR2 provides the capability to automatically handle this type of situation during recovery. By specifying an
ARCHIVELOG MAXSIZE space limit on the restore command, RMAN will load-apply-delete the logs as required
to remain within the specified disk space limitation:
RECOVER DATABASE DELETE ARCHIVELOG MAXSIZE 100M ….
In this example, only 100 megs of disk space is available for archive logs and RMAN will manage to this limit.
# 13 RMAN CAN BACKUP ITS DISK-LOCATED BACKUPSETS
If you have the disk space available, writing your RMAN backups to disk facilitates not only faster backups but faster
restores and recoveries as well. I like to keep at least a week of archive log and incremental backups on disk just for
this purpose [our databases are typically on SAN disk, and I use local disk to store the backups]. When disk space
begins to run short and more room must be made available for current backups, you could:
1. delete older backupsets from disk (i.e. implement a shorter retention policy)
2. use RMAN to copy the older backupsets to tape and automatically remove them from disk. RMAN records
the fact that the backupsets have been moved to tape so you don‟t have to compromise your retention policy
for the sake of disk space.
BACKUP BACKUPSET … CREATED BEFORE … DELETE INPUT;
Another side benefit of this feature is that RMAN will read and check every backupset block for corruption, ensuring
that the backupsets on tape are in good condition.
# 14 OTHER IMPORTANT RMAN FEATURES
There are MANY more features of RMAN, but I‟d like to mention just a few more in closing:
RMAN can restore a previous incarnation of a database if the RMAN catalog is used to store recovery
Paper # 36487
9iR2 RMAN will automatically tag (label) backups and this tag can be referenced by certain commands
9iR2 RMAN provides a DBNEWID command that can be used to alter the name and internal number
of the database. This is particularly useful for changing the internal number of a manually cloned
database (which retains the internal database number of the original source database). RMAN requires
this number to be unique within its catalog, and before this command there was no way to change it.
The DUPLICATE command can be used to create a complete or partial clone of a database, or to build
a standby database
BACKUP VALIDATE and RESTORE VALIDATE will check datafiles and backupsets for corruption
by reading them but not actually writing anything out
Tablespace-point-in-time-recovery (TSPITR) is somewhat automated with RMAN. It makes use of the
DUPLICATE and transportable tablespace technology to simplify the process
Retention policies can be overridden for backups that you want to keep for longer periods of time by
using the RMAN command:
BACKUP … KEEP [UNTIL TIME „date‟ | FOREVER]
Up to four copies of backups can be written out to separate destinations simultaneously
If you are performing your backups using OS-specific scripts and „tried-n-true‟ user-managed backup techniques, I
hope this paper has given you some insight into the power and functionality of Oracle‟s server-managed RMAN
utility. If you‟ve tried RMAN in an earlier version or never looked at the utility before, I hope this paper has given
you some basis upon which to trust Oracle with your backups and recoveries and to give RMAN serious
For those who have endured the shortcomings of 8i RMAN, I‟m certain that this paper has added a little more push
to your efforts to upgrade your databases to Oracle9i R2. Personally, I can‟t wait to get all of my databases upgraded!
And for those who currently enjoy and appreciate the benefits of server-managed backup and recovery but are paying
a 3rd party vendor sums of money for the privilege, I hope you‟ll put away your cheque book and make the switch to
There are many references available to help you implement and use RMAN for backup and recovery at your shop. I
mention a few here that I have found useful:
Database Backup and Recovery Strategies and Best Practices,
Tammy Bednar, Oracle Corporation.
Paper #213, OracleWorld 2001.
Are You Using the Best Solution of Protection Your Enterprise?,
Tammy Bednar, Oracle Corporation, Rich Bernat, Chevrontexaco Corporation.
Paper # 36487
Paper # 32513, OracleWorld 2002
A Practical Introduction to Oracle9i RMAN,
Dave Anderson, SkillBuilders, Inc.
Oracle9I RMAN Backup and Recovery,
Freeman & Hart, ISBN 0-07-222662-5
Metalink, Top Tech Docs, contains a valuable library of papers and notes on using RMAN for a variety of typical and
not so typical situations.
And last, but definitely not least, I point you to the Oracle documentation for RMAN available on Technet:
Oracle9i Recovery Manager User‟s Guide A96566-01
Oracle9I Recovery Manager Reference A96565-01
Oracle9I Recovery Manager Quick Reference A96564-01
Paper # 36487