(Republishing, or using this info in a commercial product/website, is prohibited without permission. All other uses are permitted. If in doubt, please ask.)

LOG_MANAGER

(Back to main page…)

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):

  1. 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)
  2. 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):

  1. 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
  2. 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