Rapid Database Recovery

This topic describes the recovery of databases configured for Rapid Recovery after a system or application has crashed.

Recovery Procedure

When Reality restarts following a system or application failure, any Rapid Recovery database that has become corrupted is marked as 'Waiting for Recovery'. If a user tries to log on to one of these databases, the message Awaiting Rapid Recovery  is displayed and the logon will fail.

Once you are satisfied that the underlying operating system is stable, execute the command

realrecover

to recover the database(s).

The Rapid Recovery process is not repeatable. If a second system crash occurs while recovery is in process, the database will not be recoverable. This leads to problems if, for example, the system enters a power cycling mode. It is therefore recommended that you do not execute the realrecover command until you are confident that the system is stable. However, if you would like database recovery to be automatic when the system restarts after a failure, you can achieve this by adding the line REALRAPIDRECOVERY=1  to the file REALROOT To use an environment variable: On UNIX, $variableName; On Windows, %variableName%. /files/realityrc.

There is no need to restore a database from a backup tape. The Rapid Recovery Process will restore the database to a consistent state within minutes.

If a user tries to log on to a databases while the recovery is in progress, the message Rapid Recovery in Progress is displayed and the logon will fail. When recovery is complete, the database is unlocked and users can log on.

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. (Refer to the topics TL-SET-LOG-STATUS Command and Recoverable Files for information on the logging status of files.)

If the recovery process fails, the corrupted database remains locked. If anyone attempts to log on to the database, the message This database needs checking  is displayed and the logon fails. It will then be necessary to restore the database from the most recent backup tape and, if the database is configured for Transaction Logging, to restore updates from the clean log. Refer to Transaction Logging Database Recovery for a full description of this manual recovery procedure.

Shadow Databases

If you have any shadow databases configured, the realrecover script will attempt to check and mount the base file system for each of these databases. Various messages are displayed as this process takes place.

If the mount of the file systems fails, the following message is displayed:

File system <mount_point> needs to be checked.
Please check and mount the above filing systems and then rerun this script.
Alternatively rerun this script with the -f switch and the above
databases will not be recovered.

If you are unable to recover a shadow database via realrecover, you must follow the procedure described in Shadow Database Recovery.

Actions Following Rapid Recovery

If any of the operations listed in the following table were in progress at the time of the system failure, you should take the appropriate action once the Rapid Recovery process has completed.

Operation in Progress	Action Following Rapid Recovery
Resize file	Restart the resize operation using RESIZE-FILE filename (R
Create index	Delete the index and recreate it.
Account restore	Delete any incomplete accounts and restore them again. Note Account restore of a complete database is normally carried out before the database is enabled for logging. In this case the database cannot be recovered using Rapid Recovery: you should remake the database and restart the account restore.
MOVE-FILE	Check that there is no duplicate D-pointer. If there is a D-pointer in both the old location and the new location, use EDELETE to delete the old D-pointer.