How large should I make my log filesystem?

Estimating the size of log filesystem a queue manager needs.

It is important that you make your log filesystem large enough, so that your queue manager has plenty of space to write its log. If the queue manager fills the log filesystem completely, it will write FFDCs, rollback transactions, and might terminate the queue manager abruptly.

The amount of disk space you reserve for the log must be at least as large as the active log. Exactly how much larger depends on:

• Your choice of log type (linear or circular)
• The size of the active log (primary files, secondary files, log file pages)
• Your choice of log management (manual, automatic, or archive)
• Your contingency plans in the case of a damaged object.

If you choose a circular log then your log filesystem should be

LogFilesystemSize >= (PrimaryFiles + SecondaryFiles + 1) * LogFileSize

This allows the queue manager to write to all the primary and secondary files. In exceptional circumstances, the queue manager might write an extra extent beyond the number of secondaries. The preceding algorithm takes that into account.

If you choose a linear log, the log filesystem should be significantly larger than the active log.

If you choose manual log management, the queue manager continues to write to new log extents as it needs them, and it is your responsibility to delete them (and archive them) when they are no longer required.

How much larger the log filesystem needs to be depends largely on your strategy for deleting superfluous or inactive extents.

We might decide to archive and delete extents as soon as they become inactive (not needed for restart recovery) or you might decide to archive and delete only superfluous extents (not needed for media or restart recovery).

If we are archiving and deleting only superfluous extents, and if you have a damaged object, MEDIALOG will not move forward, so no more extents will become superfluous. You will stop archiving and deleting extents until you resolve the problem, perhaps by recovering the object.

Unless you stop the workload, how much time you have to resolve the problem depends on the size of our log filesystem. Hence, it is best practice to have a generous log filesystem when using linear logging.

If you choose a linear log and automatic or archive log management, the queue manager reuses log extents.

Log extents that are available to be reused are prefixed with the letter R. When a media image is recorded, as superfluous extents are archived, the queue manager can then reuse those extents.

So the reuse extents are less than the data length written to the log between media images:

ReuseExtents <= LogDataLengthBetweenMediaImages

When recording media images automatically and setting IMGLOGLN, LogDataLengthBetweenMediaImages can be as much as twice IMGLOGLN because IMGLOGLN is a target not a fixed maximum.

When manually recording media images, or recording them automatically by interval, LogDataLengthBetweenMediaImages depends on your workload and the interval between taking images.

In addition to active extents and reuse extents, there are inactive extents (needed for media recovery only) and superfluous extents (not needed for restart or media recovery).

When using automatic or archive log management, the queue manager does not reuse extents that are needed for media recovery. So, the number of inactive extents depends on how frequently we are taking media images, and whether we are taking them manually or automatically.

IMGINTVL and IMGLOGLN are targets, not a fixed minimum or maximum between media images. However when estimating the maximum size of log filesystem you might need, it is unlikely that automatic media images would be recorded more than twice IMGINTVL or IMGLOGLN apart.

When sizing your log filesystem using automatic or archive log management, we should also consider what might happen if a queue or other object is damaged. In that case, the queue manager is not able to take a media image of the damaged object, and MEDIALOG will not move forward.

If your workload continues, your inactive log will grow unrestrained as the oldest extent needed for media recovery is still needed and cannot be reused. If your workload continues, we will have until your log filesystem fills completely to fix the problem, before the queue manager starts rolling back transactions and might even end abruptly.

Hence for automatic and archive log management:

LogFilesystemSize > (PrimaryFiles + SecondaryFiles + 
(((TimeBetweenMediaImages *2) + TimeNeededToResolveDamagedObject) * ExtentsUsedPerHour))
* LogFilePages

Note: The preceding algorithm assumes that SET LOG ARCHIVED is called for each extent, as soon as it is no longer needed for media recovery, for archive log management. Parent topic: Calculating the size of the log