Several people have asked recently what the LogWriteIntegrity option does and what the implications are of the various settings. I spoke to Andy Hickson to get the fine details and decided to write a blog post about it.
MQ supports a LogWriteIntegrity option in the Log stanza in the qm.ini file.
This parameter is inherited from the corresponding LogWriteIntegrity option in the mqs.ini file.
The setting of this option determines the algorithm that is used by MQ's logger to write out log records to the recovery log. The default setting is TripleWrite and this setting is both safe and performant in almost every possible scenario.
This setting only has any effect at all when a partial log page is to be written. For a queue manager with a reasonable amount of concurrent activity this scenario rarely occurs.
DoubleWrite has been deprecated for well over 10 years and should no longer be used.
SingleWrite selects an algorithm which under very unusual circumstances can perform better than the default TripleWrite setting but is only safe if the underlying storage platform can absolutely guarantee under all circumstances that 4KB pages written synchronously to the MQ recovery log are atomically written. This setting should only be used if the file-system/device hosting the MQ recovery log explicitly guarantees the atomicity of 4KB writes (that is when a write of a 4KB page fails for ANY reason the only two possible states should be either the before image, or the after image and that no intermediate state should be possible), in all other cases TripleWrite should be used.
On a system with sufficient concurrency the queue manager will only write full pages of log data, and if a high percentage of full pages is achieved then there will be no significant performance difference between SingleWrite and TripleWrite.
On a system with little concurrency there could be a significant performance advantage to SingleWrite, however the preferred solution would typically be to increase concurrency rather than to use SingleWrite (it can be difficult to reliably determine the atomicity of 4KB writes, and changes to the underlying software or hardware might invalidate any such guarantee).
If you are in ANY doubt that your storage infrastructure makes the required guarantees now and in the future in all circumstances, you should use TripleWrite.