REQUEST_FOR_DEADLOCK_SEARCH is recorded by the background deadlock monitor while it waits between deadlock searches. The default interval is five seconds, and it adapts: when deadlocks are being found the monitor searches more frequently, and it relaxes back toward five seconds when they stop.
So the wait is the deadlock detector’s resting heartbeat.
Is It a Problem?
No; Books Online says outright that lengthy total waiting time here does not indicate a problem, and it belongs on every benign filter list. Accumulating close to one wait per five seconds of uptime is simply the monitor running as designed.
There is one clever secondary use: because the interval contracts when deadlocks occur, a falling average wait time for this type hints the monitor has been busy. But you would not diagnose deadlocks that way when the system_health Extended Events session records every deadlock graph directly.
Common Causes
- Normal operation; the deadlock monitor always runs.
- Frequent deadlocks shortening the search interval (visible as more, shorter waits).
What To Do
- Filter it out of wait analysis; our
Get-WaitStatisticsscript does by default. - For actual deadlock investigation, pull the deadlock graphs from system_health (our deadlock summary script reads these) and fix the colliding access patterns.
- Do not tune anything through this wait; the monitor’s cadence manages itself.
How To See It
Rank waits with Get-WaitStatistics, where it is filtered. Deadlock evidence lives in the Extended Events traces, not here.
Part of the SQL Server Wait Types Library.
Related deep dive: LCK_M_X, LCK_M_S, and LCK_M_U Wait Types.
Leave a Reply