PAGEIOLATCH_DT is a wait for a Destroy (DT) mode latch on a buffer page that is currently part of an I/O request. Destroy mode is used when a buffer is being removed, and this wait type exists largely for completeness, so that every latch mode has a matching PAGEIOLATCH_* wait. Real workloads acquire pages for reading and writing (SH, EX, UP); destroying a buffer mid-I/O is a rare internal path.
Expect to see this at zero or near zero on virtually every server.
Is It a Problem?
Practically never. There is no workload pattern that drives PAGEIOLATCH_DT specifically, and no tuning lever aimed at it. If it ever records long waits, the meaning is the same as for the whole PAGEIOLATCH family: pages stuck in I/O requests for a long time, which is a disk subsystem symptom, not a latch symptom.
In that situation PAGEIOLATCH_SH and PAGEIOLATCH_EX will dwarf it and carry the actual signal.
Common Causes
- Internal buffer teardown coinciding with an in-flight I/O, a rare timing overlap.
- A genuinely struggling I/O subsystem inflating every I/O-latch wait across the board, this one included.
What To Do
- Ignore it in isolation. Check whether the rest of the
PAGEIOLATCHfamily is elevated. - If the family is elevated, measure storage:
sys.dm_io_virtual_file_statsread and write stalls per operation, and take the investigation down the standard slow-storage path. - Spend no time on
PAGEIOLATCH_DTspecifically; there is nothing to tune at the destroy-mode level.
How To See It
Rank it against everything else with Get-WaitStatistics. Its only diagnostic value is as a confirming symptom when the whole I/O-latch family is slow.
Part of the SQL Server Wait Types Library.
Related deep dive: PAGEIOLATCH_SH Wait Type.
Leave a Reply