Managing Clean Log Size

A policy for managing clean logs on your system will depend on a number of factors including:

• Size of the clean log partition.

• Growth rate of each clean log.

• Number of databases on the system.

• Requirements for keeping old clean logs.

The following sections deal with each of these factors. By considering these factors together you can establish a clean log cycling policy.

Clean Log Partition Size

The size of the clean log partition on the log disk is the primary factor in limiting the maximum size and number of clean logs which can be maintained on your system. It is recommended that the log disk is dedicated to logging and there are only two partitions on it, raw log and clean log. On larger systems, the logs may occupy several disks to increase capacity and to improve performance.

Estimating Clean Log Growth Rate

The volume of data in the clean log is determined by the number of updates being performed and the number of transactions being issued. The volume for a single database in bytes per day is:

Vol = ((I + 130) * U) + (T * 250)

where,

I is the average size of an updated record in bytes. The figure of 130 is the average overhead allowed for the header of a clean log image.

U is the estimated number of updates on the database per working day.

T is an estimate of the average number of transactions per day on the database. About 250 bytes are stored on the log for each transaction generated.

The values you give to I, U and T will depend on the application software you are using, the types of transactions being performed and the way in which your system is used during the day. The result of these calculations will allow you to determine your site procedures for archiving of clean logs.

Archiving Clean Logs

Clean logs should be archived to tape to increase data security and release disk space. Database back-up and data security procedures will vary according to user requirements. Once a database has been backed up, the earlier clean log(s) are effectively redundant. However, some users may wish to keep clean logs for an extended time period to provide additional security or for auditing purposes. Larger systems may require clean logs to be archived during each working day to make space on the clean log partition. It is the responsibility of the site manager to establish a suitable security policy for logs.

Recovery from Clean Log Partition Full

If Reality detects that the clean log partition is 100% full, as reported on the tlmenu Logging Status screen, a flag is set which prevents any more data from being logged to the raw log. Hence, Reality user processes that attempt to perform updates will hang. At this point, attempting to interrupt the program by entering CTRL+C, will cause the following message to appear:

Clean log partition full.  A. Abort. C Continue. ?

Entering A  causes the user process to exit. Entering C causes the user process to wait for space in the clean log partition.

The database administrator can recover from this situation in two ways:

• Delete a clean log to make space on the partition.

or

• Switch to a new clean log, archive the old clean log and delete it to make space on the partition.

Switching the clean log clears the log inhibit flag automatically, enabling Reality processes to continue.

Once the clean log has been switched, logging is enabled immediately. If archiving the clean log takes a long time, this may result in a clean log partition full condition occurring at the UNIX or Windows level, leading to the raw log being filled up, and logging being suspended. This situation can be recovered by deleting the old clean log after it has been archived.

Notes:

• This feature reserves an area of the clean log partition that can normally be accessed, typically 10% of the partition.

  On UNIX, due to the way "partition full" is calculated, 10% reported by Reality on the Logging Status screen equates approximately to 5% as reported by df. Hence, typically, 100% full reported by Reality is only 95% full as reported by df.

• In order to be able to switch clean logs, an operator must be able to log on to the database without logging any images.

Multiple Databases

Where there are a number of databases on your system the growth of each clean log will contribute to the total rate of filling of the clean log partition. The clean log cycling policy for all databases on the systems should be defined so as to avoid filling up the clean log partition. It may be necessary to switch the clean logs more often on the databases with the largest growth rate to ensure that the total amount of clean log data on the system does not approach the size of the partition.