Types of logging

In IBM MQ there are two ways of maintaining records of queue manager activities: circular logging and linear logging.

Circular logging

Use circular logging if all we want is restart recovery, using the log to roll back transactions that were in progress when the system stopped.

Circular logging keeps all restart data in a ring of log files. Logging fills the first file in the ring, then moves on to the next, and so on, until all the files are full. It then goes back to the first file in the ring and starts again. This continues as long as the product is in use, and has the advantage that you never run out of log files.

IBM MQ keeps the log entries required to restart the queue manager without loss of data until they are no longer required to ensure queue manager data recovery. The mechanism for releasing log files for reuse is described in Use checkpointing to ensure complete recovery.

Linear logging

Use linear logging if we want both restart recovery and media recovery (re-creating lost or damaged data by replaying the contents of the log). Linear logging keeps the log data in a continuous sequence of log files.

Log files can optionally be:

• Reused, but only when they are no longer needed for either restart recovery or media recovery.
• Manually archived for longer term storage and analysis.

The frequency of media images determines when linear log files can be reused, and is a major factor in how much disk space must be available for linear log files.

We can configure the queue manager to automatically take periodic media images, based either upon time or log usage, or we can schedule media images manually.

Your administrator decides what policy to implement, and the implications on disk space usage. Log files needed for restart recovery must always be available, whereas log files needed only for media recovery can be archived to longer term storage, for example, tape.

If your administrator enables automatic log management and automatic media images, linear logging behaves in a similar way to a very large circular log, but with the improved redundancy against media failure enabled by media recovery.

From IBM MQ Version 9.1.0 we can change an existing log type for a queue manager, from linear to circular, or from circular to linear using the migmqlog command.

Linear log extents that are not active

From IBM MQ Version 9.1.0, if we are using automatic log management, including archiving, the logger keeps track of linear log extents that are not active.Attention: If we are using automatic log management, without archiving, the use of a backup queue manager is not supported for this process.

When a log extent is no longer required for recovery and, if necessary, is archived, the logger will, at a convenient point, either delete the log extent or reuse it.

A reused log extent is renamed to be the next in the log sequence. Message AMQ7490 is periodically written, indicating how many extents have been created, deleted, or reused.

The logger chooses how many extents to keep ready for reuse and when to delete those extents.

Active log

There are a number of files that are said to be active in both linear and circular logging. The active log is the maximum amount of log space, whether we are using circular or linear logging, that might be referenced by restart recovery.

The number of active log files is usually less than the number of primary log files as defined in the configuration files. (See Calculating the size of the log for information about defining the number.)

Note, that the active log space does not include the space required for media recovery, and that the number of log files used with linear logging can be very large, depending on your message flow and the frequency of media images.

Inactive log

When a log file is no longer needed for restart recovery it becomes inactive. Log files that are not required for either restart recovery, or media recovery, can be considered as superfluous log files.

When using automatic log management, the queue manager controls the processing of these superfluous log files. If we have selected manual log management, it becomes the responsibility of your administrator to manage (for example, delete and archive) superfluous log files if they are no longer of interest to your operation.

Refer to Manage logs for further information about the disposition of log files.

Secondary log files

Although secondary log files are defined for linear logging, they are not used in normal operation. If a situation arises when, probably due to long-lived transactions, it is not possible to free a file from the active pool because it might still be required for a restart, secondary files are formatted and added to the active log file pool.

If the number of secondary files available is used up, requests for most further operations requiring log activity will be refused with an MQRC_RESOURCE_PROBLEM return code being returned to the application, and any long running transactions will be considered for asynchronous rollback.

Attention: All types of logging can cope with unexpected loss of power, assuming that there is no hardware failure. Parent topic: Logging: Making sure that messages are not lost