Oracle Recovery Manager (RMAN & Recovery Catalog)

IT professionals should strive to check and answer the following

IT professionals should strive to check and answer the following :

• If access to a database server is lost, what would the cost to a company be (monetary and reputation) ?

• What is the maximum duration that a loss of access can be tolerated ?

• If server X crashes, how long would it take to fully recover ? (Business continuity planning, working out the time to recover by carrying out a recovery procedure)

• Are backups being taken and checked regularly ?

• Verifying that the backups are working and are periodically tested

• If the RAC1 server is offline, how quickly can it be put back online ?

• What to do in a situation where RAC2 goes offline while RAC1 is offline ?

• How soon can a RACx server be put back online ?

• It is strongly advised to keep a step-by-step recovery guide ready, taking precautions is considered vital.

(For example: Is there backup media ready and waiting to be removed immediately if there was a disaster such as a fire at a workplace ?)

• Prepare documents that are easy to understand and could guide anyone to restore backups, in case of an emergency where you are unavailable and people couldn’t contact you.


In this article we try to explain the subject of Oracle backups and in a separate article we will discuss restoring/recovery.


RMAN (Recovery Manager)

This a built-in tool that comes with Oracle. It can be used to take backups of a database while it is open and can perform incremental backups.

In addition to being able to perform block media recoveries, RMAN has many other features.



Target Database: The db to be backed up and restored.

RMAN Repository: The metadata collection about dbs used for backup, maintenance and recovery. This information is stored in control file records.

Recovery Catalog schema: The schema that holds the backup metadata, held in the recovery catalog database.

RMAN Client: A command line program used by client computers to connect to a database server, using specific connections and requires authentication, like SQL*Plus.

Backup Piece: The physical files that together form RMAN backup sets. Each piece file is in a proprietary binary RMAN format.

Backup Set: A number of files, including control files, datafiles, archived redo log files. There are one or more binary files per backup set.

Image Copy: An identical copy of single datafiles, archived redo log files or control files. They can be used to perform recovery without needing any modification.

RMAN backup information can be stored in 2 locations:

1. In a controlfile

2. In a recovery catalog

If there are 1 or 2 Oracle servers in your company then you can use a controlfile. In scenarios where you have numerous databases, it would be better to store all their backup information in separate locations from a recovery standpoint, rather than in a single recovery catalog.

A recovery catalog itself is an RMAN set of tables and views where repository data about one or more databases are kept.

Additionally the catalog can store more metadata history information than a control file. RMAN scripts can also be kept in a recovery catalog that can be used to automate RMAN tasks.

Perhaps the best feature of recovery catalogs are that it is possible to use them even if control files are damaged (using CONFIGURE CONTROLFILE AUTOBACKUP ON), however the recovery process takes longer using a recovery catalog instead of a control file. This becomes more apparent in the recovery/restore scenario articles.

NOTE: After every backup of target databases, a copy should be made of recovery catalog databases as they would contain the latest data.

Some Recovery Catalog recommendations:

The RC server should be in archive mode and the backup copies in a seperate location.

A retention policy of higher than 1.

Activating automatic backup of the control file.

Not changing CONTROL_FILE_RECORD_KEEP_TIME values so that they are higher than the default values.

To take online or hot backups using RMAN, the database needs to be in archive mode.

Archivelog Mode: Redo logs are stored as archives in order to return the database to a certain time. This is similar to a Windows restore point.

For example: If a full backup was made on a Sunday and the system failed on a Wednesday. The database is first restored to its state as it was on Sunday, using a full backup, and archivelogs are then used to restore the database to its state between Sunday and Wednesday.

Please refer to the article on placing a database into ArchiveLog Mode.

NoArchiveLog Mode: Redo logs can’t be archived in this mode.

You can restore back to the point where a full backup was taken, which was Sunday in the example above, however it isn’t possible to access the data from then on until system failure.

Logical Backups: Backups made using the exp/imp and exdp/imdp tools. (Questions about logical backups appear in Oracle Certified Professional exams (version 9i)).

Physical Backups: A backup of the physical files, including data files, archive logs and control files.

Having the target database and recovery catalog in separate instances/servers is strongly recommended.

Levels of backup

• Backup of all database files (data file, control file, archivelog)

• Backups made at the tablespace level (all of the datafiles in the tablespace)

• A backup of the tablespace’s datafile can be made if the database is in archivelog mode.


The configuration of the machines running the examples in this articles are as follows:

Machine A Machine B
Oracle 10G Oracle 10G
RHEL 5.5 Oracle Solaris 10
i386 CPU, 1284MB RAM
5 disk
Disk 1: OS
Disks 2,3,4,5: Included in the data and recovery asm (automatic storage management) group


Creating a Recovery Catalog

1. Creating a tablespace

2. Creating a user and granting privileges

Procedures to run on the server where the Recovery Catalog is to be stored. (Backup information will be stored on a catalog server)

As this is a test environment the recovery catalog server and the server where backup information is stored are the same.

However in a production environment it is recommended having both sets of data on separate servers.

The previous syntax shows that RMAN backups will now be stored in the recovery catalog.
Connecting with RMAN:

It is now possible to connect to the target database.

To connect to the remote machine the rman client needs to be compatible with the server. If they are not compatible:

Connecting to the target database and catalog:

Connecting to the target database without a recovery catalog:

Running the parameter file (RMAN commands can be run after entering them into a parameter file)

Connecting to the target db, creating a log and trace

Connecting to the target db, creating a log

Backup information can be queried from the tables and views in the CAT schema.

Example Scenario: The Oracle database is not connected to the recovery catalog. If backups taken using RMAN were later saved on the recovery catalog, they might later need to be manually synchronized.

The BACKUP and COPY commands to be used on the target database get automatically synchronized with the recovery catalog. A situations where changes made to the physical structure and there a high number of log switches might also need to be manually synchronized.


RMAN scripts can be copied to the recovery catalog or a text file.

If using a Recovery Catalog, you could run a RC script directly.

If you’re not using a recovery catalog then use the RMAN by entering this command: @/path/rman.txt

Running the scripts

Checking the scripts

Saving the script to a text file

The file should be in the same directory where RMAN was run.

By creating global scripts it will be possible to use them in all databases that were saved to the recovery catalog.

To view the contents of the global scripts

Listing the scripts


Deleting the scripts

Running scripts on RMAN startup

Configuring the backup channel and tool

The device selected by default can be changed for a pending backup

Tagging the backups

Copying the RMAN backups

The syntax below shows how backups can be taken from an operating system to a separate location, the catalog command could be included in RMAN when required. There is an example scenario where this is shown.

Copying a backup to a different disk or tape

Backup commands

Incremental Backup

Differential Incremental: The differences or changes since the last backup.

Incremental level 0 = Full Backup (a backup of every used block, this is the base of the incremental backup)

Listed below is an example of a weekly plan backup plan:

Sunday level 0 « Take a full backup

Monday incremental level 2 « No previous level 2 backup, so a backup of the difference since level 0

Tuesday incremental level 2 « A previous level 2 backup, so the differences since the level 2 backup

Wednesday incremental level 2 « A previous level 2 backup, so the differences since the level 2 backup

Thursday incremental level 1 « No previous level 1 backup, if there was, a backup would have been made of the difference. Instead a backup is made from 0, this is a difference from a full backup from the middle of the week.

Checking to see if any backups were made at the current level or at a more base level, if backups were made at a more base level (lower number) then a backup is made of the difference.

A full backup is taken on Sunday

On Monday, the difference since Sunday is what gets taken as a backup.

On Tuesday, a backup is made of the difference in the database state since Monday.

On Wednesday, has a backup been made at the same level ? If not, a backup is made since the last closest level of backup, in this case a level 2 which was on Sunday.

Logically it would be quicker to take a daily incremental backup after the full backup but taking a backup in this way is suprisingly slow, at least until the “block_change_tracking” feature has been activate.

First backup example


The ALLOCATE CHANNEL and SWITCH parameters need to be placed in curly bracket. <>.

Deleting backups

If RMAN suggests deleting backups from the operating system, even though there is a solution for dealing with deleted backups it is recommended to not delete them.

Deleting backups that aren’t required (in accordance with the retention policy, more details ahead).

Crosschecking whether Rman backups have been deleted by the operating system. Backups that can’t be found are marked as expired and erased using “delete expired”.

Deleting backups that have been marked as expired.

Occasionally Rman scripts stops responding and without being able to control a script the archive logs start to get filled up. This could be followed by running out of diskspace and losing access. The only remaining option is to regain access at a local level.

To create space as quickly as possible, in this situation, the oldest of the archive logs should be moved to another location or in the worst case should be deleted, however this is not recommended as it could cause problems.

If the archive logs have been deleted by the operating system or moved to another disk, at this point it is possible to access the system by entering commands.

Report commands

report obsolete ; « Lists the backups marked as obsolete (unused or unnecessary) according to the database’s retention policy. These backups can be deleted using the “delete obsolete” command. If the flash recovery area is used as the backup path, as long as there is available space in the path obsolete backups would continue being stored there, otherwise they get deleted. If backups are stored in a different area then they would need to be deleted manually (Scripts generally get deleted by writing into them, examples such as these will be shown in the scenario section inshALLAH)

Backup files that are unknown to Rman (not in its records) are used to inform Rman after the following has taken place:

• The process of restoring the control file

• Re-creating the control file

• Changes to the db_recovery_file_dest parameters

• Needing to restore backup files from a disk, separate to the one where the backups have been taken.

If there are inconsistencies between the physical backups on the disk and the backup records in Rman, they may get deleted. (There should be a backup of the backup before any deletion takes place. If there are any problems you could get support from Oracle and do a restore.)

Listing the backups

Checking the usability of the backups.

RMAN settings

The “# default” at the end of a sentence indicates that the values haven’t been changed at that they are still at their default settings.