Calculating the size of the log
Estimating the size of log a queue manager needs.
- 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
Table 1 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 261844 bytes, each segment adding an extra 300 bytes. |
Get message | 260 bytes |
Sync point, commit | 750 bytes |
Sync point, 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 segment adding an extra 300 bytes. |
Checkpoint | 750 bytes + 200 bytes for each active unit of
work + 380 bytes for each cluster-sender channel, if you are using
multiple cluster transmission queues per queue manager. Additional data might be logged for any uncommitted puts or gets that are buffered for performance reasons. If you have cluster-sender channels, then at each checkpoint an extra 380 bytes is written to the log per cluster-sender channel. |
- You can change the number of primary and secondary log files each time the queue manager starts.
- You cannot change the log file size; you must 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.
- The total number of primary and secondary log files cannot exceed 511 on UNIX and Linux® systems, or 255 on Windows, 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 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 in
to 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.