This blog post is primarily a response to a question raised at the IBM Technical Conference last week. It seemed like the full answer would be of interest to a wider audience hence this follow up.
With MQ 9.0.2 (now 9.1 LTS) we introduced a number of improvements around the management of linear logs in MQ. These are well covered in depth by this blog post by Mark Whitlock from that time.
For full details, Iâ€™d encourage you to review that post and the knowledge center documentation, but in a nutshell you can now:
- Automate media imaging (and have it occur at the â€˜bestâ€˜ time from a queue manager performance point of view)
- Automate the reuse of logs which are no longer required for recovery (because they have been made redundant by a newer media image).
- Get substantially Improved performance (because log reuse is faster than creation and formatting of new log extents.)
With those improvements in mind, the question we were asked was â€˜why would I ever use circular loggingâ€™ and as a follow on â€˜why doesnâ€™t IBM merge these two options and/or make linear managed logging the defaultâ€™.
Two aspects of the system are of interest in answering this question
- Performance â€“ total data throughput requirements of your applications.
- Storage usage â€“ how much storage is available to the queue manager (or to put it another way â€“ the total cost to you of increasing this storage allocation).
With circular logging, storage usage is kept to an absolute minimum since as soon as all transactions touched in a given log file have been committed, that log is available for reuse. This means that on a well configured system, new (secondary) log files are very rarely required, and primary log files may be rotated through many times a second, keeping all disk usage in a small and tightly defined space. This can have further benefits, for example if all disk access can stay within the cache of your storage system for even greater throughput.
With linear logging â€“ even with all of the new options available â€“ performance and storage usage will still be gated on the frequency of media imaging. Log extents cannot be reused until all updates to queues held in that file have been committed to a more recent media recovery image â€“ and even with low queue depths and high frequency of media imaging, this is likely to be in the order of minutes or hours. On a system which regularly holds deep queues (which are costly to snapshot) these snapshots are likely to be fewer and further between â€“ meaning significantly more log space is required.
Because of these differences, there will still be significant real world advantages and disadvantages to the two approaches, and it comes down to the expected load on the system and performance and storage requirements. For this reason we are not likely to remove the option to use circular logging or modify the default for queue managers – at least any time soon.