(Republishing, or using this info in a commercial product/website, is prohibited without permission. All other uses are permitted. If in doubt, please ask.)
This latch class is when a thread is waiting for access to the structure within the Log Manager that deals with changing transaction log file size (usually growing the transaction log).
(Books Online description: “Internal use only.”)
Questions/comments on this latch class? Click here to send Paul an email, especially if you have any information to add to this topic.
Added in SQL Server version:
Removed in SQL Server version:
Extended Events latch_class value:
Maps to the LOG_MANAGER_SPACE map_value in sys.dm_xe_map_values.
The map_key value in sys.dm_xe_map_values is 61 in 2008 and 2008 R2, and 55 in 2012 and 2014 RTM. After 2014 RTM, you must check the DMV to get the latest value as some map_key values have changed in later builds.
Contention on this latch usually happens because a log file is set to have a small autogrowth and the log is growing quickly, with many concurrent operations generating log records and trying to grow the log. One thread gets the latch in EX mode and performs the grow, and a bunch of other threads are waiting to do the same thing. When they eventually get the latch, they find the log has already grown, so they’ve been waiting longer than they should, thus wasting time and lowering performance. This is almost exactly the same scenario as for contention on the FGCB_ADD_REMOVE latch (which is for data files).
Apart from making sure that log files have proper autogrowth set, check out all the information for the WRITELOG wait type and general log file and logging performance.
Known occurrences in SQL Server (list number matches call stack list):
- Generating a log record which forces a log growth (in this case, while logging a row insert from populating a new index during an index rebuild)
- Generating a log record which forces a log growth (in this case, while logging a change to a differential bitmap from allocating a page and thus modifying an extent). Note the PageRef::ModifyBitsNonTransactional, as differential bitmap changes cannot be rolled back so the log records are not linked into the list of log records for a transaction.
Abbreviated call stacks (list number matches known occurrences list):