LATCH_SH is the shared (read) counterpart to LATCH_EX. It is a wait for a shared latch on an internal SQL Server structure that is not a data or index page. Threads take a shared latch when they only need to read the structure, and they queue here when another thread holds it exclusively.
As with LATCH_EX, the name alone is not the story. The latch class is what points you at the actual subsystem.
Is It a Problem?
Low values are normal background activity. Sustained, high LATCH_SH means many readers are contending on one internal structure, which is worth chasing down. Note that sys.dm_os_latch_stats groups all the modes (NL, SH, UP, EX, DT) together per class, so once you pivot to the class view you are analysing the structure, not the mode, and that is the right altitude anyway.
Common Causes
ACCESS_METHODS_DATASET_PARENT: parallel scans coordinating through a shared parent dataset, the most common class behind bothLATCH_SHandLATCH_EXon reporting workloads.- Contention on internal metadata or allocation structures under a read-heavy, highly concurrent workload.
- Often appears alongside
LATCH_EXon the same latch class; readers and writers of one hot structure queue together.
What To Do
- Check
sys.dm_os_latch_statsfor the top latch class by wait time. - Address the subsystem that class belongs to, rather than the generic wait.
- If a parallel dataset class dominates, review parallelism settings (
cost threshold for parallelism, MAXDOP) and index the queries generating the large scans so they stop scanning.
How To See It
Rank it with Get-WaitStatistics, then split by class in sys.dm_os_latch_stats.
LATCH_SH is background noise on a healthy instance. If you are chasing a real problem, start with the waits that actually cost you time.
- The waits that usually matter, ranked, with what each one is telling you.
- Performance & Troubleshooting, the scripts and guides for this part of the stack.
Leave a Reply