What happens if I make my log too large?

Points you need to consider when estimating the maximum size of the log.

If you make your log too large:
  • You might increase the time taken for an emergency restart, although this is unlikely.
  • You are using unnecessary disk space.
  • Very long running transactions are tolerated.
Important: No matter how inaccurately you estimate the size of your log, data integrity is maintained.

[V9.1.0 Jul 2018]To help you estimate the maximum size of the log, you can use the log utilization statistics. For further information, see Deciding how to set IMGLOGLN and IMGINTVL and ALTER QMGR.

See Using checkpointing to ensure complete recovery for a description of how the queue manager reads the log on restart. The queue manager replays the log from the last checkpoint, and then resolves all transactions that were active when the queue manager ended.

To resolve a transaction, the queue manager reads back all the log records associated with that transaction. These log records might predate the last checkpoint.

By allocating the queue manager a very large log, you are giving the queue manager permission to read every log record in the log on restart, although usually the queue manager does not have to do this. Potentially, in the unlikely event that this happens, that process could take a long time.

If checkpointing had unexpectedly stopped before the queue manager ended, that dramatically increases the restart time for a queue manager with a large log. Limiting the size of the log limits the emergency restart time.

To avoid these problems you should ensure that:
  • Your workload can comfortably fit into a log that is not excessively large.
  • You avoid long running transactions.