(Republishing, or using this info in a commercial product/website, is prohibited without permission. All other uses are permitted. If in doubt, please ask.)
Description:
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:
pre-2005/2005
Removed in SQL Server version:
N/A
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.
Other information:
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):
- XeSqlPkg::latch_suspend_end::Publish+138
LatchBase::Suspend+16b8
SQLServerLogMgr::GrowAFile+184
SQLServerLogMgr::ReserveAndAppend+292
XdesRMReadWrite::GenerateLogRec+615
PageRef::InsertRows+2594
IndexPageRef::Insert+502
InsertRecordOnPage+61b
IndexDataSetSession::InsertSmallRecord+10ca
IndexDataSetSession::InsertRowInternal+2de1
IndexDataSetSession::InsertRowFromOIBInternal+39
DatasetSession::InsertRowFromOIB+177
RowsetNewSS::InsertRowFromOIB+29
CValRowCrtIdx::SetDataX+13a
sqlevn70.rll!0x000007FEF1C31437
CQScanOnlineIndexNew::NonOptimizedGetAndInsertRows+12d
CQScanOnlineIndexNew::GetRow+4b
CQScanXProducerNew::GetRowHelper+53
CQScanXProducerNew::GetRow+15
FnProducerOpen+57
FnProducerThread+8c3
SubprocEntrypoint+a7f - XeSqlPkg::latch_suspend_end::Publish+138
LatchBase::Suspend+16b8
SQLServerLogMgr::GrowAFile+184
SQLServerLogMgr::ReserveAndAppend+292
XDES::GenerateNonXactLogRec+f8
PageRef::ModifyBitsNonTransactional+35b
PageRef::SetDiffMapChangeBit+1b6
PageRef::FormatFull+58
CBulkAllocator::FinishCurrentBuf+97
CBulkAllocator::AllocateLinkedAndFormattedLeafPage+f2
CHeapBuild::AllocateNextHeapPage+1f
CHeapBuild::InsertRow+14f
RowsetBulk::InsertRow+2e5f
CValRow::SetDataX+5b
sqlTsEs.dll!CEsExec::GeneralEval+1a9
CQScanUpdateNew::GetRow+43d
CQScanXProducerNew::GetRowHelper+366
CQScanXProducerNew::GetRow+15
FnProducerOpen+57
FnProducerThread+8c3
SubprocEntrypoint+a7f
SOS_Task::Param::Execute+21e
SOS_Scheduler::RunTask+a8