RMAN is the Oracle supplied DBMS backup utility and like any other integrated utility, it 'understands' how the database fits together and so is a much safer way to backup a database than to simply shut it down then backup the underlying flatfiles. As well as permitting database backups while the database is active, RMAN does a lot of data validation to ensure that a backup is complete and can be used to restore a good copy of a database. Most RMAN facilities are managed by DBAs but RMAN usually interfaces with Storage products like Spectrum Protect (TSM) or NBU for backend storage, so it is necessary to have an understanding of how RMAN works in case you get problems with that interface.
As well as database files, a database depends on other types of files, such as network configuration files, password files, and the contents of the Oracle home. These files are not backed up with RMAN and so must be backed up with your standard backup and recovery tool.

RMAN calls the users databases 'Target Databases' or in other words, the target database is the database that RMAN is backing up, restoring, or recovering. Data about backups is usually held in a Recovery Catalog, which is just another database and it can contain backup information about multiple target databases. This information will include stuff like Backup sets, Image copies, archived redo logs, target database schemas and configuration settings.

Oracle uses the terminology consistent backups and inconsistent backups for databases. A consistent backup occurs when the database is shut down and so is in a consistent state.
A backup made when the database is open is inconsistent. Oracle backs up both the database and the relevant parts of the redo logs, so when a database is restored from an inconsistent backup, Oracle will apply any pending changes from the redo logs. The term 'inconsistent' is a little bit misleading, as inconsistent backups are sound, acceptable and frequently used. The beauty of inconsistent backups is that you do not have to shut the database down to run them, which is invaluable in today's 24*7 world. The only issue is that RMAN will fail the backup if the database is in NOARCHIVELOG mode, a quite common type of failure that needs a DBA to fix.

Backup Sets, Backup Pieces and Incremental backups

It is worth knowing how RMAN uses Backup Sets and Backup Pieces, so you have some idea what the various RMAN log messages mean.

A backup set contains the data from one or more datafiles, archived redo logs, or control files or server parameter file to create a complete backup of a database.
A backup set contains one or more binary files called backup pieces. By default a backup set will contain one backup piece, but a backup can be split into multiple pieces using multiple channels in parallel, each of which produces one backup piece. The backup pieces are the files that you see recorded in your backup software and each backup piece has a uniquely generated name. As every backup piece has a unique name, your backup software just needs to keep one backup version of each file.

By default, RMAN makes full backups. Image Copies are full backups that contain a backup of every data block, whereas a full backup that is stored in a backup set may skip datafile blocks that are not in use. Full backups are the default, but RMAN can take incremental backups, where only those data blocks that have changed since a previous backup are copied.. A backup set is an RMAN-specific proprietary format, whereas an image copy is a bit-for-bit copy of a file. By default, RMAN creates backup sets.

RMAN has another backup process, called 'The Flashback Database' that is designed to provide fast recovery to a point in time backup. It appears to work by rolling back log data, rather than by using any hardware flashcopy feature. Flashback Database uses its own flashback logs, which are stored in a fast recovery area.
Flashback Database is controlled with RMAN commands or SQL statements, so it is not something a storage person would be directly involved in. However, its use is limited to logical errors, as it relies on the availability of the database files and the redo logs - in other words, it will not help if you get a physical disk failure. It could require quite a bit of extra storage, especially if DBAs want the ability to flash back for several days


RMAN and Spectrum Protect (TSM)

It is common practice for RMAN to hand over the management of physical storage to a backup and recovery product like Spectrum Protect (TSM) or NBU. RMAN calls this product a media manager and allocates 'channels' or paths to the storage using commands like this.

allocate channel t1 type 'sbt_tape'
parms 'ENV=(TDPO_OPTFILE=/u01/app/oracle/admin/Spectrum Protect (TSM)_rman/db1_tdpo.opt)';

In this case, RMAN is using Spectrum Protect (TSM) as the media manager. Note that the channel type is sbt_tape, but Spectrum Protect (TSM) can direct the backup to a disk storage pool. RMAN is looking for Spectrum Protect (TSM) information in a tdpo_opt file. Typical information in that file will include:

DSMI_DIR          /usr/tivoli/Spectrum Protect (TSM)/client/api/bin64
DSMI_ORC_CONFIG   /usr/tivoli/Spectrum Protect (TSM)/client/ba/bin/dsm.oracle.opt
TDPO_NODE        Spectrum Protect (TSM)_oracle_node

These three lines tell RMAN where to find the Spectrum Protect (TSM) code, the location of the Spectrum Protect (TSM) options file used for an oracle backup, and the name of the Spectrum Protect (TSM) client node for the oracle backup. Obviously, all of these file paths may be different in your installation.

Another essential piece of information is the link to the Spectrum Protect (TSM) library drives. Oracle expects to find this information in $ORACLE_HOME/lib/libobk.a and Spectrum Protect (TSM) usually holds it in /usr/Tivoli/Spectrum Protect (TSM)/client/oracle/libobk64.a so you need a symbolic link from the Oracle library to the Spectrum Protect (TSM) library. A missing link is the most common cause of errors like

RMAN-00571: =============================== ============================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ============================ ===============================
RMAN-03009: failure of allocate command on c1 channel at 11/30/2001 13:57:18
ORA-19554: error allocating device, device type: SBT_TAPE, device name:
ORA-27211: Failed to load Media Management Library
Additional information: 25

Controlling Backup Retentions

RMAN needs to control backup retentions, so it can ensure that the backup information that it holds in it's catalog matches the backups held externally. For Spectrum Protect (TSM), the common practice is to use a copy group that holds only one version of an active backup indefinitely, and no deleted backups. This works because every backup file has a unique name. Spectrum Protect (TSM) then lets RMAN delete the backups when they are not required. For this to happen, the 'Backup Delete Allowed' parameter on the client definition should be set to Yes - if you set it to 'NO', then your backups will be retained forever! Within RMAN a database backup retention of 21 days would be set with the command


and when the backup is older than 21 days, RMAN will signal Spectrum Protect (TSM) to delete the backup. If you have configured Spectrum Protect (TSM) correctly and old backups are still not being deleted, then check that your RMAN backup script contains commands like these to actually clean up old backups.


 run {
   crosscheck backupset;
   report obsolete;
   delete obsolete;

We often get requests for special oracle database backup retentions, but these are also controlled by RMAN. Special backups can be retain for longer than the default cycle using the RMAN command 'CHANGE BACKUPSET TAG ... KEEP UNTIL ...' , usually controlled and issued by your DBA.

Oracle Storage

Lascon latest major updates