Resilience Options

Transaction Handling

A transaction is a set of related updates made to a database which are logically grouped together by Transaction Handling 'start', 'end' and 'abort' boundary commands. Each update is a single change made to the database, from DataBasic, Proc, TCL or ALL, by creating, altering or deleting an item. Individual updates not grouped into a transaction are defined as being 'independent'.

The relationship between updates belonging to a transaction and logically grouped by transaction start and end boundary commands may be defined as follows:

If one update within the transaction is applied to the database, then all of the remaining updates within the transaction must be applied in order to maintain a consistent database.

Transaction Handling ensures that the updates defined as belonging within a transaction are maintained together as a set. If a transaction is not completed, the updates made since the start of the transaction are deleted from the database and the pre-updated items are restored. This maintains the database in the predictable and consistent state which existed before the transaction started.

Transaction Logging

Transaction Logging provides a basic level of resilience by logging all database changes to a dedicated log disk. In the event of a database being corrupted by an application or system failure, the logged changes can be re-applied to the database so as to recover the most recent consistent version of the database with minimum data loss.

Recovery is carried out by restoring the most recent backup copy of the database from tape and replaying all logged updates made since the last backup onto the restored database.

Transaction Logging runs in conjunction with Transaction Handling.

Rapid Recovery

Rapid Recovery records recent database structural changes to disk, so that in the event of a system failure, recent changes can be rolled back and the database can be restored to a valid structure within minutes. There is no need to restore from a tape backup.

Rapid Recovery is normally used together with Transaction Logging to ensure that both the database structure and the users' data are restored during recovery. However, for purposes of efficiency, it is possible to configure a database (or individual files) to a lower level of resilience, but still maintain recovery of the database structure. More detailed information on the options available can be found in Introduction to Rapid Recovery and Configuring for Rapid Recovery.

Rapid Recovery is not available on filestore databases.

Shadow Database

Shadow Database provides a greater level of resilience by maintaining a copy of the 'live' database on separate disks, or disk partitions. The copy is called the ?Shadow? database and is updated each night with the day's changes. Transaction Logging runs on the live database.

Database recovery is achieved by replaying logged updates onto the Shadow database, then making it the live one.

Shadow database can be used in conjunction with Rapid Recovery. If, on a database configured for Rapid Recovery, database recovery is unsuccessful — for example because of a hardware problem on that disk — users could then be switched to a Shadow database.

FailSafe

The FailSafe option provides the greatest level of resilience by maintaining two identical databases on different systems, one operating as the live database, called the primary, and the other as the standby, called the secondary. Transaction Logging runs on the primary database and records updates to logs on both the primary and secondary systems. While users work on the primary database, all complete transactions and independent updates are automatically applied to the secondary.

Database recovery is achieved by reconfiguring the secondary database as the new primary, allowing user operations to continue on the new primary with only a short break in service. The failed system can then be recovered using procedures similar to those for Transaction Logging, before re-establishing the FailSafe link and re-synchronising the databases.

Rapid Recovery can be used in conjunction with FailSafe in order to speed up the recovery of the failed system and minimise the time when FailSafe operation is not available.

Disaster Recovery

The Reality Disaster Recovery (Reality DR) feature further increases the resilience of Reality Failsafe systems by providing a second backup system, which can be off site. It can also be used in other ways; for example, to provide offsite replication of a standalone system.