PAGELATCH_DT is a wait for a Destroy (DT) mode latch on a data file page that is in memory and not part of an I/O request. Destroy mode is taken when a buffer is being removed from the buffer pool, and the wait type exists mostly so every latch mode has a PAGELATCH_* entry. Workloads compete for pages in shared, update, and exclusive modes; destroying buffers rarely collides with anyone.
Expect zero or near zero on every server.
Is It a Problem?
Practically never. Buffer teardown happens constantly (lazy writer, cache trims) without measurable waits, because the engine avoids destroying pages anyone is using. If page latching is genuinely hurting your system, the story lives in PAGELATCH_SH, PAGELATCH_UP, and PAGELATCH_EX, with tempdb allocation contention the usual headline.
There is no tuning path that targets destroy-mode page latches.
Common Causes
- Momentary collisions between buffer teardown and page access, vanishingly rare.
- Severe buffer churn environments raising the odds fractionally.
What To Do
- Ignore it in isolation.
- For real page latch work, use
sys.dm_os_waiting_tasksto find the contended pages under theSH/UP/EXmodes and follow the tempdb or hot-page playbooks.
How To See It
Rank waits with Get-WaitStatistics; the actionable page latch modes will always dwarf this one.
PAGELATCH_DT 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.
- PAGELATCH_EX Wait Type, the closest wait worth investigating when this one is high.
- Performance & Troubleshooting, the scripts and guides for this part of the stack.
Leave a Reply