WebSphere MQ Logs not at the capacity you need?
ValerieLampkin 27000182R2 Comments (2) Visits (6665)
Not sure how to increase your WebSphere MQ active logs when your application traffic increases? The ideal scenario would be to plan in advance for the message volume and size MQ logs accordingly at the time the queue manager is created. The total number of primary and secondary log files cannot exceed 511 on UNIX® systems, or 255 on Windows. The System Administration Guide has information for calculating the size of the log.
However, we often have clients who have had an increase in message traffic and need to then increase their log capacity after the queue manager (QMGR) has already been created and operating for a while. Often, they will receive the error message AMQ7469 for transactions rolled back to release log space.
The AMQ7469 message indicates that the log is becoming full and that the queue manager will roll back one or more transactions to release log space. This may be resolved by increasing the number of logs. A common practice is to double the number of logs to see if that resolves problem. One thing you must prevent is using up the file system by setting the number of logs to the point they will not fit on the file system.
If new application function has been added recently, then you may want to ensure that applications are not coded such that an unusual long-running unit of work (UOW) would occur requiring the UOW to span a large number of files. Until the work is committed, the logs can not be freed by the queue manager.
You should increase the primary to the amount that would be necessary for your QMGR during normal operations. The secondary log number would allow the QMGR to extend beyond that amount when necessary. The difference between secondary and primary logs is that after a period of time of not being used, the QMGR will delete the secondary log files. Once created, primary log files are not deleted. The increase in secondary log files would allow for unexpected needs for logging such as if a remote system were down and additional data needed to be stored locally for a short period of time.
There is some overhead associated with creating new logs. The QMGR needs to be sure it has space for checkpointing. Log files are created by the queue manager as needed so active logs will grow till 80% of the total (primary+secondary) allocation. The queue manager will take action to rollback the oldest active transaction that has written a log record when the active log reaches 80% of the configured capacity to leave enough space for the "checkpoint" process to complete. At the checkpoint a rollback will occur if a UOW spans the amount of files currently allocated. The queue manager will only use 80% of the logs before sending the AMQ7469 to reserve space for check points, see the technote entitled Checkpoints in WebSphere MQ logging.
You can get more information about the checkpointing process and how it ensures recovery by viewing the online System Administration Guide section Using checkpointing to ensure complete recovery.
When clients update their qm.ini file to increase the number of LogPrimaryFiles, they are often surprised to see that the number of primary logs is not immediately increased after the queue manager restart. As mentioned before, when a new queue manager is created it will allocate the total number of logs designated in the qm.ini at the time of creation. However, if you alter the qm.ini after the queue manager has already been created, then the logs are created as they are needed to store data. That is why you do not immediately see the total number of new logs; they will be created during processing of messages that require more space than can be accommodated by the existing logs.
If you increase your log allocation after initial queue manager creation and you need to verify the new parameter is in effect, you can utilize the dmpmqlog command. The dmpmqlog command should be run when the QMGR is down.
$ dmpmqlog -m TESTQMGR
As this output shows, my qm.ini has designated 31 primary and 21 secondary logs.