Professional Documents
Culture Documents
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.
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
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
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.
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
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
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.
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.
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> }
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
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).
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.
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:
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.
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:
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:
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:
There are two big advantages in using this feature to backup your control file:
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.
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:
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
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,
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.
And then to recover all blocks reported as corrupt from the above queries, use the CORRUPTION LIST option of the
BLOCKRECOVER command:
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:
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.
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.