 Introduction
to Oracle Recovery Manager Backups
Sean Scott
Taking a physical backup of an Oracle database is no simple task.
For years, DBAs depended on complex shell scripts that would extract
lists of all the files that needed backup, build SQL and Unix commands
to put tablespaces into backup mode and copy files, and monitor
the process for exceptions. Backups for large databases could run
for hours because the process simply made a copy of each database
file, and there was no provision for incremental backups. Perhaps
the deepest, darkest fear of any DBA was to perform a database recovery
and realize that the entire plan was invalid due to the lack of
one small, yet crucial, file.
Enter Recovery Manager, or RMAN, introduced with Oracle 8. RMAN
is a feature-rich tool that allows an Oracle database to be backed
up through a series of simple commands. It also interfaces easily
with tape backup devices, and has provisions for four levels of
incremental backup, among other things.
Although a full treatment of RMAN is enough to fill a book and
thus well beyond the scope of this article, I will describe the
basic steps required to use RMAN to take a full or incremental backup
of a database, which will work with any version of Oracle -- from
Oracle 8 through Oracle10g. I've successfully used these techniques
to perform backups of Oracle databases on a variety of platforms,
including HP-UX, Solaris, and Red Hat Linux.
RMAN vs. Scripted Backups
RMAN offers several advantages over scripted backups, the most
significant of which is that its syntax is simpler and easier to
learn and use. And because RMAN is supported by Oracle, any problems
you encounter with RMAN backups or commands can be taken directly
to Oracle for support. Simply put, RMAN is a less complex, proven,
and more reliable method of achieving the same goal. Other advantages
include:
- Reduced overhead. With scripted backups of online tablespaces,
you must first place the tablespace into backup mode. Doing so
causes any activity on that tablespace to be recorded as redo
activity. For busy or large databases, this could become quite
significant. With RMAN, that necessity is eliminated and the overhead
is reduced.
- Smaller backup footprint. RMAN backups are often smaller than
scripted file copies, because RMAN only backs up changed data
blocks below the high water mark of a datafile.
- Support for incremental backups. There is no way with a simple
file copy strategy to backup only the data that has changed since
the last backup. With RMAN, five levels of incremental backups
are available, potentially saving hours of backup time each week.
- Automated recovery. RMAN knows which files it needs to recover
a database and restores only what it needs. Contrast this to a
manual recovery, where queries against the database dictionary
must be performed to identify which files are needed, followed
by manual restores of those files. RMAN will simply recover your
database in less time, with less intervention, and do it more
safely than you could with a scripted backup of the database.
- All files are included automatically in a full backup. With
scripted backups, the database files that need to be backed up
must be manually coded in your backup scripts, or queries against
database tables must be performed to identify which files need
to be backed up. Any change to the database represents a change
in your backup scripts that must somehow be managed. With RMAN,
that file management is internalized and automatic.
- Verification of your backup's veracity. With RMAN, you can
simulate a recovery without actually restoring your files and
be confident that, should disaster strike, your database will
be recoverable.
- Automated management of your backup files. By setting a retention
policy, RMAN can purge obsolete backups from your system and even
be used to manage archived log files. Using a retention policy,
RMAN will never remove a backup set that is required to recover
your database fully. So even if a backup fails and the last valid
files are beyond the retention period, RMAN will leave them intact.
RMAN can also be used to manage your archive log files.
Logging into RMAN
RMAN is invoked through the rman executable under ORACLE_HOME/bin
and is part of the standard installation of Oracle. You must provide
RMAN with some basic information before you can get started. RMAN
needs the login information to the target database (which is the
database we'll perform backups against) and information about the
recovery catalog that will be used.
A recovery catalog is an Oracle database that stores information
about RMAN backups. In the absence of a recovery catalog, recovery
information is stored in the database control file. Most Oracle
installations do not use a separate recovery catalog, and the included
scripts reflect this. However, it is a simple matter of changing
the connection strings to utilize a recovery catalog if you wish
to do so.
If ORACLE_HOME is in your PATH, invoke RMAN as:
rman target user/password nocatalog (without a catalog)
Or:
rman target user/password catalog rmanuser/rman_password@catalog
(with a catalog)
Those familiar with SQL*Plus will recognize the connect strings
that identify the username, password, and database alias. Note that
the login to the target database must be as a user with SYSDBA privileges.
RMAN also supports the use of OS-authenticated logins. OS-authenticated
users provide an extra layer of security and convenience for batch
operations. Consider the following login string, which can be executed
at either the command prompt or within a shell script:
rman target system/manager nocatalog
Now, from another session, execute:
bash-2.03$ ps -ef | grep rman | grep -v grep
oracle 14547 13399 0 12:01:57 pts/1 0:01 rman target system/manager nocatalog
There's the username and password for the world to see! If this is
being run via a script, somewhere on the system will be a file with
a hard-coded password. With an OS-authenticated account, a login to
RMAN is simply:
rman target / nocatalog
No password information shows up under ps -ef, and access is
controlled by OS authentication, where it is much easier to enforce
strong passwords.
Backing Up a Database
Now that we've successfully logged into RMAN, let's take a look
at a typical RMAN login and backup command:
bash-2.03$ rman target / nocatalog
Recovery Manager: Release 10.1.0.2.0 û Production
Copyright © 1995, 2004, Oracle. All rights reserved.
Connected to target database: ORA10G (DBID=3190394834)
Using target database instead of recovery catalog
RMAN> run {
2> allocate channel d1 type disk maxpiecesize=2000M;
3> backup database plus archivelog;
4> }
The first thing we see is the run block. In versions prior to Oracle9i,
it is necessary to enclose most RMAN commands within a run { } block.
(Beginning in Oracle9i, the run { } block is still supported syntax
but is not necessary.) There is no performance loss incurred by using
the run block, so I prefer this syntax because it is compatible across
all installations.
The first step within the run block is to allocate a channel for
RMAN to use for the backup command itself. Allocating a channel
allows us to limit the size of any file created (in the example
it is limited to 2,000MB) and define the location to which the files
will be backed up. It also determines whether the output of the
following commands will be directed to disk or to a tape drive.
Allocating a second or third channel will cause RMAN to parallelize
the operation whenever possible (provided you're using the Enterprise
Edition of the database).
Each channel allocated will also result in one or more backup
sets being created. A backup set is a file that contains backup
information for one or more Oracle datafiles or archive log files.
The elegance of RMAN is that a backup set is often smaller than
the sum of its parts. For example, consider a datafile that is 500MB,
but only contains 250MB of data. A straight file copy results in
a 500MB file. But in RMAN, that file will be significantly smaller
because the empty space is not written -- only the data.
The backup command can be used to backup an entire database, a
control file, archive log files, or one or more individual datafiles
or tablespaces. Where once pages of scripts took tablespaces in
and out of backup mode and copied files, a backup of your entire
database using RMAN is now potentially as simple as:
backup database plus archivelog;
Of course, although it could be that simple, it usually isn't.
Often we'll want to extend more control over the backup process. This
is a more typical set of commands to back up a database:
run {
allocate channel c1 type disk;
allocate channel c2 type disk;
backup full
filesperset 5
tag full_backup
format
'rman_%d_%t_%U.bus' database include current controlfile;
sql 'alter system archive log current';
backup filesperset 50
archivelog all
format
'rman_%d_%t_%U.bar';
release channel c1;
release channel c2;
}
Although slightly more complicated than the previous example, this
set of commands is still fairly straightforward. The differences between
this and the previous simple run block are the addition of the filesperset,
tag, and format options, the inclusion of the control file in the
backup set, the addition of a SQL command, and a separate command
to back up the archive log files.
None of these are Earth-shattering changes. filesperset limits
the number of datafiles included in each backup set. The tag is
a way of naming a backup so that queries against the recovery catalog
will make a little more sense to the operator. The format command
defines how the files generated by the backup will be named. In
this case, there are three wildcard options used in the filename.
%d and %t insert the database SID and current time,
respectively, and %U adds a unique identifier. RMAN offers
several other wildcards besides these as well.
The include current controlfile clause does just that --
it includes the current control file in the database backup set.
The control file contains information about the current state of
Oracle's database files and is required to restore the database.
I suggest that you include it in any backup that you perform, since
changes to the physical and logical structure of the database are
included in the control file. You will be unable to restore your
database if you're using an older or obsolete version of the control
file that does not reflect such changes.
As shown in the example, we can include regular SQL commands within
RMAN, too. The SQL command included here causes the current redo
log file to be written to disk, so the backup of all the archive
log files will enable a full and consistent recovery of the database.
Once the redo logs are flushed to the archive logs, we take a backup
of all the archive log files.
Note that RMAN is a very verbose tool. Most successful commands
will generate a large volume of informational messages, which is
often disquieting to users new to RMAN. If you're used to SQL*Plus
or the Oracle alert log, which return ORA-nnnnn errors to indicate
a problem with the database or failure of a command, RMAN will definitely
surprise you. Don't be alarmed. You can identify a failure in an
RMAN command by looking for the RMAN-00569 condition, which is a
general indication that an error stack will follow. When running
RMAN from within a shell script, you simply test the exit status
for a non-zero value. Listing 1 provides an example of testing the
exit status of RMAN from within a shell script.
Incremental Backups
Note that the database backup command in the previous run block
specifies "full". It is also possible to perform incremental backups
of an Oracle database using RMAN. RMAN offers five incremental levels
of backup. Level 0 is the equivalent of a full backup. Levels 1
through 4 provide fine-grained control over the amount of data that
is backed up. For example, a level 1 backup only records changes
made to the database since the last full backup. A level 2 backup
only backs up data changed since the last level 1 backup, and so
on.
Incremental backups allow you to perform full backups less frequently,
while still being protected against data loss and minimizing both
the time required to back up the database and the space on disk
or tape to store the backup.
File Copies
If you are used to or prefer file copies, RMAN can accommodate
you as well. Without RMAN, to get a consistent copy of a datafile,
you would have to place the tablespace into backup mode, copy the
file using OS commands, then take the tablespace out of backup mode.
With RMAN, the whole process is handled automatically and simply
through the copy command:
RMAN> copy datafile '/u02/oradata/ora10g/system01.dbf'
2> to '/u12/backups/ora10g/system01.dbf';
The copy command can only be used to copy files to disk, and it copies
the file bit-for-bit, so the advantages of potentially smaller backup
sizes from the backup command are lost. However, if you prefer file
copy operations, the copy command is far superior to the alternative
hot backup method.
Putting It to Work
Listing 1, rman_backup, includes a basic RMAN run block as part
of a shell script that can be used to perform a full or incremental
hot backup of your database. It accepts three command-line parameters.
The first is the database SID and is required. The second is the
destination for the backups. This can be a full path to a disk directory
or simply the value TAPE if you are writing the backups to a tape
drive. Third is the incremental backup level. The default is to
perform a full (level 0) backup if no value is provided. It can
be called from a cron job using syntax similar to the following:
00 1 * * 0 /home/oracle/dba/rman_backup ora10g TAPE 0 > \
/home/oracle/logs/rman_backup.log
Included near the top of the script is an email address to which administrative
alerts are to be sent. If either of the RMAN commands in the script
fails, the DBA (or other responsible party) is notified via email
or pager alert.
The script verifies that the database SID being called is legitimate,
then lists information about the environment, including database
connections, disk space (for disk backups), and memory before beginning
the backup itself. The backup command utilized is very similar to
the one shown above. Once the backup is complete, the same diagnostic
information is listed for comparison purposes and can be used to
identify problems with the RMAN process.
Listing and Validation
Once the backup is complete, the script invokes RMAN a second
time to list and validate backups on the system. The listing of
the backups is informational only, but the following command:
restore database validate
causes RMAN to emulate a restore of the database to make sure that
the backup is complete and valid. This is useful as a sanity check
of the process and verifies that the backup sets that have been created
could actually be used to recover your database if needed.
This script calls the file in Listing 2, oracle_env. oracle_env,
which sets up the environment for Oracle to use when the parent
script is called through a cron job.
Space Management
One feature that makes Oracle such a robust database is its ability
to recover right up until a failure. Oracle uses archive log files
to store every change made to a database. These are written to a
location on disk known as the archive log destination. Left unattended,
they will eventually consume all the space on the drive. If this
happens, Oracle will, by design, stop working until space has been
freed up on the system.
Oracle DBAs used to either manually purge these files or write
a shell script to automatically delete files older than a few days,
but there was no check to make sure that the files deleted were
genuinely obsolete. RMAN, however, offers a few options to more
efficiently manage archive log files.
Beginning in Oracle9i, the DBA can set a retention policy for
backup sets as a whole. This includes database backups and archive
log backups:
RMAN> configure retention policy to recovery window of 3 days;
When a backup becomes older than three days, RMAN will mark it as
obsolete. Deleting these old backups is as simple as allocating a
maintenance channel (similar to allocating a disk or tape channel)
and telling RMAN to delete them. The beauty of this method is that
RMAN knows whether a backup older than three days is still needed
for a full recovery. If so, it won't be marked as obsolete (and won't
be deleted):
RMAN> run {
2> allocate channel for maintenance device type disk;
3> delete obsolete;
4> }
This method is convenient if you're storing backups and archive log
files on disk.
The second method works well when your backup policy writes files
to tape and is available for all versions of RMAN. It simply requires
the addition of the option delete input to the archive log
backup command. For example:
backup filesperset 50
archivelog all
format
'rman_%d_%t_%U.bar' delete input;
Once the archive log file is backed up, Oracle deletes the files automatically.
This command can be added to the rman_backup script, which can be
run at a regular interval not only to back up the database and archive
log files but to keep the archive log destination clean.
Another solution is included in Listing 3, which mimics the functionality
of setting a retention policy for pre-Oracle9i installations. It
requires two parameters -- the database SID, and a retention period
(in days) inside which files are to be kept. This script calls SQL*Plus
to identify files that are outside the retention period and that
are not needed to fully back up the database in the event of failure.
It then removes these files using the OS rm command.
Once the files are removed from the system, they need to be removed
from the recovery catalog. This is accomplished by allocating a
maintenance channel then performing the two crosscheck commands.
Crosscheck verifies that the files in the recovery catalog are actually
available in their expected location. When a backup piece is missing,
RMAN marks it as "EXPIRED".
The RMAN delete command can then be used to remove recovery catalog
references to expired files. In the script, this is accomplished
with three commands:
delete noprompt expired backup of database;
delete noprompt expired backup of controlfile;
delete noprompt expired backup of archivelog all;
Summary
Oracle's RMAN is a robust and feature-rich application that simplifies
backing up Oracle databases and managing the files created by the
backups. It should be the tool of choice for those responsible for
managing backup and recovery of Oracle databases. RMAN's ability
to interface with popular media management tools, such as those
offered by Veritas and HP, makes it as easy to back up to tape as
to disk.
The multiple levels of incremental backups make RMAN an excellent
tool for managing backups of large databases, as well as high-transaction
environments where a minimal performance impact from backups is
required. The simplicity of commands makes it accessible to every
DBA, regardless of their level of experience, and puts a successful
backup policy within their grasp.
Sean Scott has ten years of experience as an Oracle database
administrator on Solaris, HP, AIX, Linux, and Windows. He has worked
in the manufacturing, military, energy, scientific, automotive,
pharmaceutical, and e-commerce markets. His technical skills include
backup and recovery, replication, performance tuning, PL/SQL, and
database design. He is also well versed with MS SQL Server, MySQL,
and PostgreSQL. | 
