Calculating the size of the log<

Calculating the size of the log

Overview

After deciding whether the queue manager should use circular or linear logging, you need to estimate the size of the log that the queue manager needs. The size of the log is determined by the following log configuration parameters:

LogFilePages

The size of each primary and secondary log file in units of 4K pages

LogPrimaryFiles

The number of preallocated primary log files

LogSecondaryFiles

The number of secondary log files that can be created for use when the primary log files are full

The table below shows the amount of data the queue manager logs for various operations. Most queue manager operations need a minimal amount of log space.
However, when a persistent message is put to a queue, all the message data must be written to the log to make it possible to recover the message. The size of the log depends, typically, on the number and size of the persistent messages the queue manager needs to handle.

Operation Size

Put persistent message 750 bytes + message length
If the message is large, it is divided into segments of 15700 bytes, each with a 300-byte overhead.

Get message 260 bytes

Syncpoint, commit 750 bytes

Syncpoint, rollback 1000 bytes + 12 bytes for each get or put to be rolled back

Create object 1500 bytes

Delete object 300 bytes

Alter attributes 1024 bytes

Record media image 800 bytes + image
The image is divided into segments of 260 000 bytes, each having a 300-byte overhead.

Checkpoint 750 bytes + 200 bytes for each active unit of work
Additional data might be logged for any uncommitted puts or gets that have been buffered for performance reasons.

Notes:

You can change the number of primary and secondary log files each time the queue manager starts.
You cannot change the log file size; determine it before creating the queue manager.
The number of primary log files and the log file size determine the amount of log space that is preallocated when the queue manager is created. Organize this space as a smaller number of larger log files rather than a larger number of small log files.
The total number of primary and secondary log files cannot exceed 63, which, in the presence of long-running transactions, limits the maximum amount of log space available to the queue manager for restart recovery. The amount of log space the queue manager might need for media recovery does not share this limit.
When circular logging is being used, the queue manager reuses primary log space. This means that the queue manager's log can be smaller than the amount of data you have estimated that the queue manager needs to log. The queue manager will, up to a limit, allocate a secondary log file when a log file becomes full, and the next primary log file in the sequence is not available.
Primary log files are made available for reuse during a checkpoint. The queue manager takes both the primary and secondary log space into consideration before taking a checkpoint because the amount of log space is running low.
If you do not define more primary log files than secondary log files, the queue manager might allocate secondary log files before a checkpoint is taken. This makes the primary log files available for reuse.

Operation	Size
Put persistent message	750 bytes + message length If the message is large, it is divided into segments of 15700 bytes, each with a 300-byte overhead.
Get message	260 bytes
Syncpoint, commit	750 bytes
Syncpoint, rollback	1000 bytes + 12 bytes for each get or put to be rolled back
Create object	1500 bytes
Delete object	300 bytes
Alter attributes	1024 bytes
Record media image	800 bytes + image The image is divided into segments of 260 000 bytes, each having a 300-byte overhead.
Checkpoint	750 bytes + 200 bytes for each active unit of work Additional data might be logged for any uncommitted puts or gets that have been buffered for performance reasons.