Raw Log Configuration

This section contains the information needed to locate and size the raw log in a Transaction Logging System. In most cases the clean log will have been located and sized as part of the installation process.

Location of Raw Log

The raw log, as its name implies, is created in a raw partition, the location and size of which needs to be established. This topic describes how to do this.

Use of a Log Disk

Normally a disk, designated the 'log disk', is dedicated to the raw and clean logs. However, in small systems other user partitions with low utilisation may also be located on the log disk. Remember, though, that the accessing of non-logging related data/partitions on the log disk will impair the performance of Transaction Logging, particularly when using transaction boundaries. In large systems, the log may occupy several disks for both performance and capacity reasons.

Size of Raw Log

The raw log must be large enough to retain all roll-forward information ('after' and transaction boundary images) and all roll-back information ('before' images) until a transaction is ended or aborted, and any associated 'after' images and transaction boundary images are securely in the clean log.

Note also that if the raw log becomes excessively full (>85%), then the longest outstanding, transaction is forcibly aborted and the process logged off the database to allow logging to continue without interruption. This should be taken into account in the final specification of minimum raw log size.

If a database is configured for Rapid Recovery, the minimum raw log size calculated according to the procedure in this topic should be doubled.

The 2 Minute Factor

'After' images and transaction boundary images transferred to a clean log are maintained in the raw log for 2 minutes after being processed, to ensure that they have been flushed from the system buffer and have reached the clean log. Writing to a clean log is not synchronous.

To meet this requirement the raw log should be made large enough to hold all roll-forward and roll-back images generated during the period of the longest transaction expected to be on the system, plus 2 minutes.

Allowing for the Longest Transaction

The minimum partition size required for the raw log is determined by the longest outstanding transaction expected to be input to the raw log. This is because the raw log operates as a circular buffer and all buffer space between the transaction start and current update of an open transaction remains locked until the transaction is committed. Hence, although, shorter transactions and updates within the time span of a longer transaction may be successfully written to a clean log, the buffer space used by them is locked until the longest transaction is committed.

How Update Data is Stored

To calculate raw log size you need to appreciate how the update data is stored. For each item updated within a transaction, Transaction Logging generates two images; a 'before' image containing the update item before the update was made plus a header, and an 'after' image containing the update item after the update was made plus a header. An update outside a transaction only generates an 'after' image.

Size of the Image Header

The I.D.image header contains information about the update, for example, user, account, file, time of update, port, etc. On average there are about 100 bytes of information in the header.

Transaction Boundary Images

For each completed transaction, Transaction Logging generates transaction boundary images, 'start', 'precommit' and 'commit'. On average, transaction boundary images together occupy about 250 bytes on the raw log.

Factors Affecting Raw Log Size

To work out the minimum size of raw log, you need to estimate the following parameters during the peak work period of your databases:

U The maximum number of item updates per hour performed on your system.

I The average size of an updated item in bytes.

T The maximum number of transactions per hour.

t The estimated duration in minutes of the longest transaction.

These parameters are used to calculate the amount of disk space required for the raw log, as follows:

Maximum Number of Updates

Maximum number of updates (A) to be held on the raw log is:

A = (2 + t) × U/60

U is divided by 60 to calculate the number of updates per minute. Two minutes is added to the estimated duration of the longest transaction, as the transaction is maintained in the raw log for an additional 2 minutes after it is written to the clean log to ensure that the write is completed.

Bytes Per Update (B)

Number of bytes (B) created by a single update is:

B = 2 × (I+100)

The figure of 100 bytes is added to the average item size (I) to allow for the header of an image in the raw log. Two images, 'before' and 'after', are stored in the raw log for each update, hence the multiplication by two.

Bytes For Transaction Boundaries

Growth in bytes (C) due to transaction boundary images generated during the longest transaction anticipated is:

C = (2 + t) × (T × 250)/60

The number of transactions (T) is multiplied by 250 as the set of boundary images in a transaction is assumed to occupy about 250 bytes. This total is divided by 60 to calculate the number of bytes generated per minute and multiplied by (2 + t) to allocate space for the longest transaction anticipated.

Raw Log Size

Using the above calculations, the minimum number of bytes of disk space required for the raw log partition is:

R = (A × B) + C

Note that in this calculation we have assumed that all updates are made within transactions. If Transaction Handling is not used at all, the minimum raw log size can be half that of the above calculation, as only one image is logged for an independent transaction and there will be no transaction boundary images.

The size of raw log (R) calculated here should be considered as the absolute minimum. It is recommended that where possible, the raw log should be double the calculated value to allow for worst case conditions. In general, regardless of the above calculations, a minimum of 100 Mbytes should be allocated to the raw log. On systems where disk space is at a premium, a margin of at least 25% is strongly advised. Remember that automatic abortion of the longest transaction and log off of the process occurs when the raw log is more than 85% full.