LATCH_UP is a wait for an update-mode (UP) latch on an internal SQL Server structure that is not a data or index page. Update mode sits between shared and exclusive: the holder intends to modify the structure but still allows concurrent readers. The wait type exists so every latch mode has a matching LATCH_* entry; the mode itself tells you far less than the latch class involved.
For buffer pages the equivalent is PAGELATCH_UP; LATCH_UP is everything else.
Is It a Problem?
Rarely on its own, and never diagnosable from the mode alone. sys.dm_os_latch_stats groups all modes (NL, SH, UP, EX, DT) together per latch class, which is the correct altitude anyway: what matters is which internal structure is under contention, not which flavour of latch was requested.
If LATCH_UP registers meaningfully, some structure that gets modified-while-read is hot, and the class name will say which subsystem owns it.
Common Causes
- Contention on allocation and metadata structures under concurrent mixed read/modify access.
- The same workloads that drive
LATCH_EXandLATCH_SH; the three usually travel together on one hot class.
What To Do
- Query
sys.dm_os_latch_statsordered by wait time and take the top class as the real lead. - Follow the class to its subsystem, exactly as you would for
LATCH_EX. - For before/after tests, clear latch stats with
DBCC SQLPERF ('sys.dm_os_latch_stats', CLEAR);and measure just your window.
How To See It
Rank it against everything else with Get-WaitStatistics, then pivot to latch classes; the mode-level wait name has done its job once it has your attention.
LATCH_UP 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