Show TOC

Recovery with OracleLocate this document in the navigation structure

Use

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:

    Phase

    Description

    Check

    Analyze the problem and determine the proper course of action.

    Restore

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

    Recovery

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

BRRECOVER and BRRESTORE automatically support 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 (that is, complete database recovery), to a point-in-time in the past, and resetting of the database (that is, restore of a complete 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
  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 useful 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 BRRECOVER and BRRESTORE 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 frequently 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 multiprocessor 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 extended.

Result

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