(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 that controls a filegroup (FGCB = File Group Control Block). It’s accessed in in EX mode to grow/shrink/add/remove files in the filegroup and in SH mode to prevent file changes while finding the next file to allocate from.
(Books Online description: “Use to synchronize access to filegroups for ADD and DROP file operations.”)
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 FGCB_ADDREMOVE map_value in sys.dm_xe_map_values.
The map_key value in sys.dm_xe_map_values is 54 in 2008 and 2008 R2, and 48 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 data file is set to have a small autogrowth and the file is growing quickly, with many concurrent operations allocating extents and trying to grow the file. 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 file 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 LOG_MANAGER latch (which is for log files).
To investigate this, you can use Extended Events to watch for contention on this latch and correlate with data file growth. There’s a video demo of me doing that here, and the associated demo code is here. You can also just look through all the databases on your server, looking for data files with very small (or maybe the default 1MB) autogrowth.
There’s also a long blog post I wrote about this latch here.
Known occurrences in SQL Server (list number matches call stack list):
- Getting the next file to allocate from (in this case, while allocating extents for a bulk load operation)
- Growing a file (in this case, while allocating extents for a bulk load operation)
And many more similar stacks involving allocating extents.
Abbreviated call stacks (list number matches known occurrences list):
- XeSqlPkg::latch_suspend_end::Publish+138
LatchBase::Suspend+16b8
LatchBase::AcquireInternal+415
FGCB::GetAllocFCB+7a
AllocationReq::AllocatePages+174c
AllocationReq::Allocate+f3
ExtentAllocator::PreAllocateExtents+435
ExtentAllocatorSingleAlloc::PreAllocate+72
ExtentAllocatorSingleAlloc::AllocateExtents+25c
CBulkAllocator::AllocateExtent+24d
CBulkAllocator::AllocatePageId+bc
CBulkAllocator::AllocateLinkedAndFormattedLeafPage+c2
CHeapBuild::Init+300
RowsetBulk::Init+782
RowsetBulk::WakeUp+153
CQScanRowsetNew::WakeUpRowset+329
CQScanUpdateNew::Open+2bf
CQScanNew::OpenHelper+41
CQScanXProducerNew::Open+c8
FnProducerOpen+44
FnProducerThread+8c3
SubprocEntrypoint+a7f
SOS_Task::Param::Execute+21e
SOS_Scheduler::RunTask+a8 - XeSqlPkg::latch_suspend_end::Publish+138
LatchBase::Suspend+16b8
FGCB::GrowAFile+29a
MakeSpaceInFileGroup+4a
AllocationReq::AllocatePages+2504
AllocationReq::Allocate+f3
ExtentAllocator::PreAllocateExtents+435
ExtentAllocatorSingleAlloc::PreAllocate+72
ExtentAllocatorSingleAlloc::AllocateExtents+25c
CBulkAllocator::AllocateExtent+24d
CBulkAllocator::AllocatePageId+bc
CBulkAllocator::AllocateLinkedAndFormattedLeafPage+c2
CHeapBuild::Init+300
RowsetBulk::Init+782
RowsetBulk::WakeUp+153
CQScanRowsetNew::WakeUpRowset+329
CQScanUpdateNew::Open+2bf
CQScanNew::OpenHelper+41
CQScanXProducerNew::Open+c8
FnProducerOpen+44
FnProducerThread+8c3
SubprocEntrypoint+a7f
SOS_Task::Param::Execute+21e
SOS_Scheduler::RunTask+a8