Rapid Recovery

This topic provides an overview of Reality's Rapid Recovery option. This feature is only available on partition databases.

Overview

What is Rapid Recovery?

Rapid Recovery is a software facility that enables quick restoration of a database to a valid structure following a system failure. Structural changes to a database are saved to a dedicated log disk so that, if the database becomes corrupted, recent changes can be rolled back until the database is in a consistent state. The images of structural changes are known as Quick images.

When the database is restored to a valid structure, application updates made during the five minutes before failure are lost. For files that are Recoverable or Logged, logged updates are automatically replayed, but there will be application data missing from files that are Not Logged.

How Rapid Recovery Works

Each time a structural change is made to a database that has Rapid Recovery enabled, the Rapid Recovery software writes the change to the raw log.

The Raw Log is a raw partition on the log disk. It acts as a central repository for the Before and After images saved by the Transaction Logging software and for the Quick images logged by the Rapid Recovery software. One raw log partition is shared by all databases on a system.

Rapid Recovery software will save After images of changes to any file that is defined as Recoverable. These images are written to the raw log, as described in Introduction to Transaction Logging, but are tagged as 'phantom' to indicate that they should not be copied to the clean log. (If the database is not configured for Transaction Logging, there will be no clean log available.) After images are available on the raw log during automatic database recovery to restore the file's data.

The logging status of files on a Rapid Recovery database can be:

Logged Before and After images are written to the raw log as well as the Quick images. The After images are then stored in the clean log as an audit trail and for disaster recovery. (This status is only available if the database is also configured for Transaction Logging.)

Recoverable Before and After images are written to the raw log as well as the Quick images, but the After images are tagged as phantom and are not written to the clean log. This mode may be useful for application level indexes for example.

Not Logged Only Quick images are written to the raw log. Following automatic recovery, the database will have a consistent structure but there may be data missing from these files. This mode is suitable for scratch files.

Database Recovery

When the system restarts following a failure, you can use the realrecover command to initiate recovery of databases that are configured for Rapid Recovery and have become corrupt.

When the Q images are replayed, to return the database to a consistent structure, application updates made during the five minutes before failure are lost. For Recoverable or Logged files, the recovery process then automatically restores independent updates and complete transactions logged after that time, and rolls back all incomplete transactions. The net effect, if Rapid Recovery completes successfully, is to restore the data to as consistent a state as if there had been a complete restore followed by a re-run of all logged updates.

Implications for Performance

Configuring a database for Rapid Recovery will lead to some reduction in performance during normal operation.