CONFIGURE This! Taking Advantage of Oracle 9i Recovery Manager (RMAN) Features During Backups

Recovery Manager (RMAN) features have been expanded significantly in Oracle 9i.
This article discusses several of these new features and includes examples on
how to implement them to make any Oracle DBA’s backup, restoration, and
disaster recovery plans more effective.

Oracle Recovery Manager (RMAN) is one of the most
versatile tools in any Oracle DBA’s toolbox to insure that a database is highly
available. Our DBA group has been using it as our prime tool for database
backup, recovery, duplication, and migration since we created our first Oracle
8i production databases in early 2001, and we continue to use it for those
tasks after upgrading our databases to Oracle 9i Release 2 (9iR2).

The Oracle 8i RMAN command set is backward compatible, so
when I upgraded our databases to 9iR2, I did not have to change our backup
scripts. When I recently had a chance to refresh my Oracle 9i backup and recovery
skills at Oracle University, however, I found out that I had been missing out
on several of RMAN’s newer features. Here is a short list of several RMAN
features that were enhanced as of 9iR2:


The new CONFIGURE command encapsulates and replaces a
number of older RMAN directives. For example, I can configure default settings
for automatic backup channels so that my backup scripts do not require
channel configuration statements each time they are run.

For example, to set default channels to use disk, set the
default degree of parallelism to 2, and set up the default disk channel
settings to be used during backup and recovery operations, the following
commands would be issued:


(Note that I can also use these directives to configure
default settings for media management software layers – often a tedious task prior
to implementation of CONFIGURE – but this is beyond the scope of this article.)

The standard ALLOCATE CHANNEL command can be used to
override the default settings for channels created via the CONFIGURE command.
For example, issuing the following command will change the destination of the
RMAN backups created, but still leave the default destination intact:

ALLOCATE CHANNEL d1 TYPE DISK FORMAT 'k:rmanbkupdf0_%d_%s_%t';

Arrggh! I Forgot To Remember to Back Up The Control File!

Oracle recommends that the database’s control file be
backed up as part of a solid database backup and recovery strategy, since any
changes to the database, such as the addition of datafiles or new tablespaces
affect the control file.

directive, RMAN will automatically back up the database’s control file whenever
a BACKUP or COPY command is issued during a backup. And – more importantly – it
also creates a new controlfile backup whenever a database structural change

Finally, if your database is using a Server Parameter
File (SPFILE) to store a binary version of the initialization parameters file,
issuing this command will insure that the SPFILE is backed up automatically
whenever it is changed as well.

Backup Space Management: Setting Default Retention Policies

My current production database configuration gives me the
luxury of creating level 0 incremental backups every night to disk. Another DBA
task I do not relish, is having to make sure my production database server has
enough disk space to accommodate the daily RMAN backup pieces. Under Oracle 8i,
I had to create a few scripts to delete the physical files from the backup
directories and then issue CROSSCHECK BACKUP; and DELETE EXPIRED BACKUP;
commands to clear out the backups from the database’s control file.

Under Oracle 9iR2, though, the CONFIGURE RETENTION POLICY
command gives me another set of options: I can simply tell RMAN to make sure I
have enough backups to meet a specific recovery window. I can also tell
RMAN to keep a specific number of copies of datafiles and controlfiles.
For example, to make sure I have enough backups to recover the database as it
stood up to three days ago, I would issue:


Moreover, to insure that I have at least two
copies of each datafile and controlfile backup, I would issue:


RMAN keeps all archived redo logs and incremental backups
necessary to insure the retention policies can be met. When a backup piece is
no longer needed, RMAN marks it as obsolete. If I want to clear out all obsolete
backup files, I simply need to run the DELETE OBSOLETE; RMAN command and RMAN
handles the deletion of the corresponding physical files.

Improved Archived Redo Log (ARL) Backup Management

Managing ARL backups is also much improved under 9iR2.
The BACKUP ARCHIVELOG command now accepts a new directive, NOT BACKED UP
{integer} TIMES. RMAN will check to see if the ARL has already been backed up
the specified number of times and exclude it from the backup if the criteria
are met.

In addition, the RMAN DELETE command now includes a
directive that will automatically delete an ARL once it has been backed up the
specified number of times to the same device type:


CATALOG? We don’t need no steenkin’ CATALOG!

In Oracle 9i, NOCATALOG is now the default when the RMAN
command is invoked. Take heart: It is indeed possible to perform RMAN backups
without a Recovery Catalog on a separate database and server. In fact, I have
been using this technique successfully for a full year against several
production databases without any issues.

Now, a warning. Be aware that the database’s control file
only has enough room to store a limited number of RMAN backup entries in its
catalog. Therefore, this option is only appropriate if you are backing up your
full database on an almost-daily basis, or if you will have only a few backup
files created every day between full database or incremental level 0 backups.

Scripts and Output

I have provided example scripts and actual output from
RMAN sessions for some practical examples. Script
shows my original Oracle 8i RMAN backup script. Script 2 shows how to implement the
CONFIGURE command to set default values. Finally, Script 3 is an example of the
minimized scripting required after the CONFIGURE command has set the defaults
for RMAN backups.

References and Additional Reading

I have
drawn upon the following Oracle 9i Release 2 documentation for the deeper
technical details of this article:

A96565-01 Oracle 9i Recovery Manager

A96566-01 Oracle 9i Recovery Manager User’s


See All Articles by Columnist
Jim Czuprynski

Jim Czuprynski
Jim Czuprynski
Jim Czuprynski has accumulated over 30 years of experience during his information technology career. He has filled diverse roles at several Fortune 1000 companies in those three decades - mainframe programmer, applications developer, business analyst, and project manager - before becoming an Oracle database administrator in 2001. He currently holds OCP certification for Oracle 9i, 10g and 11g. Jim teaches the core Oracle University database administration courses on behalf of Oracle and its Education Partners throughout the United States and Canada, instructing several hundred Oracle DBAs since 2005. He was selected as Oracle Education Partner Instructor of the Year in 2009. Jim resides in Bartlett, Illinois, USA with his wife Ruth, whose career as a project manager and software quality assurance manager for a multinational insurance company makes for interesting marital discussions. He enjoys cross-country skiing, biking, bird watching, and writing about his life experiences in the field of information technology.
Get the Free Newsletter!
Subscribe to Cloud Insider for top news, trends & analysis
This email address is invalid.
Get the Free Newsletter!
Subscribe to Cloud Insider for top news, trends & analysis
This email address is invalid.

Latest Articles