Recovery Manager (RMAN)

Introduction:

This document explains the basic operation of SMR & RMAN. Because of the
enormous flexibility of RMAN only the most basic features will be covered
here. For more information, please read the Oracle8 Server Backup & Recovery
Guide or Oracle8i Recovery Manager User's Guide. For comprehensive examples,
please view the online case*.rcv scripts in $ORACLE_HOME/rdbms/demo.

For the sake of clarity, I have excluded RMAN error messages and return
codes unless necessary. It is usually obvious when an error occurs!
 
See also :
Note 120084.1 RMAN 8.0 to 8i - Getting Started
Note.360416.1 Oracle10g - Getting Started with Recovery Manager (RMAN)
 

1. What is RMAN?

RMAN can be used to backup and restore database files, archive logs, and
control files. It can also be used to perform complete or incomplete
database recovery. Note that RMAN cannot be used to backup initialization
files or password files.
 

RMAN starts Oracle server processes on the database to be backed up or
restored. The backup, restore, and recovery is driven through these processes
hence the term 'server-managed recovery'.

Note that SMR can also be controlled from OEM's Backup Manager GUI. This
article will not discuss Backup Manager.
 

2. Terminology

2.1. Backup sets

 A backup set is characterised by the following:

       - Contains one or more datafiles or archivelogs
       - Stored in an Oracle proprietary format
       - Comprises a complete set of backup pieces
       - Constitutes a full or incremental backup
 

2.2. Backup pieces

A backup set is comprised of a number of backup pieces. Each backup piece
is a single output file. The size of a backup piece can be restricted;
if the size is not restricted, the backup set will comprise one backup
piece. Backup piece size should be restricted to no larger than the
maximum file size that your filsystem will support.

2.3. Image copies

An image copy is a copy of a single file (datafile, archivelog, or
controlfile). It is very similar to an O/S copy of the file. It is not
a backupset or a backup piece. No compression is performed.

2.4. Full backup sets

A full backup is a backup of one or more datafiles that contains all used
blocks in the datafile. Blocks that have never been used are not backed up
i.e. oracle performs backup set compression.

2.5. Incremental backup sets

An incremental backup is a backup of one or more datafiles that contains
only those blocks that have been modified since a previous backup at the
same or lower level. As with full backups, compression is performed.

2.6. File multiplexing

Datablocks from multiple datafiles can be multiplexed in the same
backupset.

2.7. Recovery catalog resyncing

Resyncing the recovery catalog involves synchronising the recovery
catalog with the target database controlfile. Certain operations perform
this implicitly. To resync manually, issue the 'resync catalog;' command
from RMAN. The catalog should be resynced frequently, especially if
the target database generates many archive logs. It should also be
resynced after making any structural changes to the target database.
Although the target database's controlfile is automatically updated
whenever new controlfile records are created (for example, creation of
new archived logs or new datafiles), if the target is not resync'd
and a backup controlfile is restored, the new records must be cataloged
manually (catalog archivelog '';).

2.8. Snapshot Controlfile

When RMAN needs to resynchronize from a read-consistent version
of the control file, it creates a temporary snapshot control file. The default
name for the snapshot control file is port-specific. Use the 'set snapshot
controlfile name to file_name' command to change the name of the snapshot
control file; subsequent snapshot control files that RMAN creates use the
name specified in the command. The snapshot control file name can also
be set to a raw device. This operation is important for OPS databases in
which more than one instance in the cluster use RMAN because server sessions
on each node must be able to create a snaphost control file with the same name
and location.

2.9. Resetlogs Operation

Whenever you open the database with the RESETLOGS option, all datafiles
get a new RESETLOGS SCN and timestamp. Archived redo logs also have
these two values in their header. Because Oracle will not apply an archived
redo log to a datafile unless the RESETLOGS SCN and timestamps match,
the RESETLOGS operations prevents you from corrupting your datafiles with
old archived logs.

2.1.0 Database Incarnation

Whenever you perform incomplete recovery or perform recovery using a
backup control file, you must reset the online redo logs when you open the
database. The new version of the reset database is called a new incarnation.
All archived redo logs generated after the point of the RESETLOGS on the
old incarnation are invalid in the new incarnation.

2.1.1. Resetting the Recovery Catalog

Before you can use RMAN again with a target database that you have
opened with the RESETLOGS option, notify RMAN that you have reset
the database incarnation. The reset database command directs RMAN
to create a new database incarnation record in the recovery catalog.
This new incarnation record indicates the current incarnation. RMAN
associates all subsequent backups and log archiving done by the target
database with the new database incarnation. If you issue the ALTER
DATABASE OPEN RESETLOGS statement but do not reset the
database, then RMAN cannot access the recovery catalog because it
cannot distinguish between a RESETLOGS command and an accidental
restore of an old control file. By resetting the database, you inform
RMAN that the database has been opened with the RESETLOGS option.
In the rare situation in which you wish to undo the effects of opening
with the RESETLOGS option by restoring backups of a prior incarnation
of the database, use the 'reset database to incarnation key' command to
change the current incarnation to an older incarnation.