Recovery with Oracle


To minimize downtime with your Oracle database, you must make sure that you can quickly recover the database in the event of a failure with loss of production data. There are the following types of recovery with Oracle:

·        Instance recovery

This is required if structures on disk are not damaged, but the database instance has aborted.

·        Media recovery

This is required if structures on disk (that is, control file or files, online redo log files, data files) are damaged. It consists of the following steps:




Analyze the problem and determine the proper course of action.


Restore the appropriate files, for example, backed up data files and archived redo log files.


Recover the database as far as possible (that is, roll forward transactions from the logs). Open transactions are rolled back during database opening.

BRRESTORE or BRRECOVER automatically supports all the steps in media recovery. If backups are done using SAP’s BRBACKUP tool, BRRECOVER is able to select the backups needed, and restore the damaged files. BRRECOVER supports a variety of recovery possibilities, including recovery to the current point-in-time, to a point-in-time in the past, and resetting of the database (that is, restore of a full database backup only).

Instance recovery is done automatically when the database instance is restarted. This section only looks at media recovery, during which the database is unavailable.

Process Flow


       1.      Devise a recovery strategy and rehearse it in practice

SAP strongly recommends you to rehearse a disaster. You could, for example, use a test system to restore data files of some tablespaces (at least the system and rollback segment), control files, online and archived redo logs of a backup taken from the production system. Then perform the recovery, applying the redo log data.

This exercise is very valuable to give you some idea how long a recovery would take.

       2.      Repeat the recovery rehearsal often enough (for example, twice a year) to take account of the effects of database growth on recovery time.

       3.      Use BRRESTORE or BRRECOVER to perform the check, restore and recovery functions.

This automates the process so that it is faster and there are fewer errors.

       4.      Consider using fast devices for recovery and adjust the frequency of backups.

The downtime required for media recovery depends on the time spent for each of the three steps (check, restore, recover). This in turn depends largely on the devices used for restore and also on the backup scheme used. The less time you can afford to spend on recovery, the more often you must perform backups and the more important it is to use fast devices for backup and restore.

       5.      If available, use parallel recovery.

On multi-processor hardware, consider using parallel recovery. However, on a single-processor machine, use the standard serial recovery procedure.

       6.      Only restore and recover what is absolutely necessary.

Restore and recover only damaged files if a recovery to the current point in time is planned. Recovery is slower if more files than necessary are restored, because more processing has to be repeated.


You can restore your database as quickly and efficiently as possible, so avoiding downtime caused by a failure with loss of database data.

See also:

You can find more information on SAP Service Marketplace at: