RMAN

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

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 21 DAYS;

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
 Oracle Files
 Oracle RMAN
 Oracle RAC
 Dataguard
 Oracle ASM

Lascon updTES
I retired 2 years ago, and so I'm out of touch with the latest in the data storage world. The Lascon site has
not been updated since July 2021, and probably will not get updated very much again. The site hosting is
paid up until early 2023 when it will almost certainly disappear.
Lascon Storage was conceived in 2000, and technology has changed massively over those 22 years. It's
been fun, but I guess it's time to call it a day. Thanks to all my readers in that time. I hope you managed
to find something useful in there.
All the best
DISCLAIMER - By entering and using this site, you accept the conditions and limitations of use
Click here to see the Full Site Index       Click here to see the Cookie Policy       Click here to see
the Privacy Policy                             ©2019 and later, A.J.Armstrong