Transaction Logging

This topic provides an overview of Transaction Logging in a Reality environment, including a brief overview of database recovery after failure.

Overview

Transaction Logging is a software facility that saves changes made on the database to a dedicated log disk. If the database becomes corrupted by an application or system failure, the most recent version of the database can be recovered by restoring the most recent backup from tape then re-applying the logged changes to the database.

In the event of a failure, a Transaction Logging database can be recovered by restoring the most recent database backup tape and replaying on the database all changes logged since the backup. Note, however, that if the database is also enabled for Rapid Recovery, you can recover a valid database structure following a system failure and the logged updates are automatically replayed. In this case, there is no need to restore from a backup tape.

Transaction Logging saves both transactions, which are sets of related changes defined by the application software, and independent updates, which are individual changes to a database, not inside a transaction (all independent updates up to the last few seconds before failure, are logged; rollback is not necessary).

Each time a database with Transaction Logging active is changed, the Transaction Logging software writes the change to the raw log located on the log disk. The logging path is illustrated in Transaction Logging Path.

Before and After images

For each change to the database within transaction boundaries, the Transaction Logging software writes two records to the raw log, a 'Before' image and an 'After' image.  For an independent update, only an After image is written to the raw log  The Before image defines how the changed data is restored to its original value if a transaction needs to be rolled back.  The After image defines the new value of the data.

For example, if a Reality record is changed, the Before image will be a copy of the record as it was before it was changed and the After image will be the changed record itself.  Alternatively, if a brand new record is being created, then the After image will be the newly created record, but the Before image will comprise a 'delete record' command.  The Before image will always undo the change when replayed on the database.

For a committed transaction, 'transaction start' and 'transaction commit' boundary images are also written to the raw log.

Transaction Logging Path

The Raw log

The raw log is a raw partition on the log disk that acts as a central repository for all logged Before and After images of all active and recently committed transactions, and independent updates.  It has a cyclic queue structure that ensures efficient and secure storage of logged images.  One raw log partition is shared by all databases on a system.

The raw log carries out two main functions:

• It buffers the After images and stores them until they are written safely to a clean log.

• It stores the Before images to enable roll-back if a transaction is aborted. If a database is configured for Rapid Recovery it also stores Quick images that record structural changes to the database.

Clean logs

A clean log is a structured host system file located in a database's clean log sub-directory, which provides a permanent storage location for After images and transaction boundary images for a particular database, transferred from the raw log. Transaction images are written to the clean log once they are committed. All images relating to committed transactions and independent updates now in the clean log are cleared from the raw log.  Before images are discarded.

Before and After images are maintained in the raw log for about 2 minutes after being written to the clean log. This is the optimum time required to ensure that the system has transferred the images to the clean log.

Each database has one active clean log which receives and stores committed transactions and independent updates for its associated database.  When you use tlmenu, a clean log is created each time Transaction Logging is started on the database and each time you request to switch logging to a new clean log.  Transactions are written to it in the order in which they are committed.  Each independent update in the clean log consists of a single After image.  Each transaction in the clean log consists of a sequence of logged After images and 'transaction boundary' images for that transaction.  The contents of a clean log are used to restore changes to its associated database in the event of a system or application failure.

All clean logs on a system are stored on a dedicated log disk and in a specified clean log partition in which the clean log directory is created.  The clean log file system is created when Transaction Processing is installed on the system. See also Clean Log Administration.

All clean logs for a particular database are stored in a sub-directory within the clean log directory.  The clean log sub-directory for that database is defined during the configuration and setup procedure described in Configuring Transaction Logging.

Transaction Logging with multiple databases

The diagram below illustrates the logging paths for Transaction Handling/Logging on a system with multiple databases.  Note that not all databases on a system must support Transaction Handling/Logging.  In the example, only Databases 'A' and 'B' support Transaction Handling and Transaction Logging.  Database 'C' does not support either feature, and Database 'D' supports Transaction Handling only, so that only Before images are written to the raw log.

Transaction Handling/Logging Paths with Multiple Databases