Reading SQL Server Wait Statistics Without Guessing
Updated
Wait statistics are one of the first things I check when a SQL Server instance "feels slow."
CPU and disk graphs can point in a direction, but sys.dm_os_wait_stats (or
sys.dm_exec_session_wait_stats for a single session) tells you what SQL Server itself has been
waiting on since the last restart or stats reset.
Compare a representative interval
Capture two snapshots of sys.dm_os_wait_stats and subtract the earlier counters from the later ones. Record collection time and instance startup time with each sample. Discard the interval if the instance restarted or counters decreased, which can indicate a manual reset.
Avoid clearing shared wait statistics during routine investigation: it removes the baseline used by other monitoring. Choose an interval that covers the workload being investigated, and compare wait counts, total wait time, and signal wait time together.
Group waits into categories, not raw wait types
Raw wait types are noisy - some are always present and not actionable (like SLEEP_TASK in idle
periods). I group waits into rough categories before drawing conclusions:
- CPU pressure:
SOS_SCHEDULER_YIELD, high signal wait time relative to resource wait time. - I/O pressure:
PAGEIOLATCH_*,WRITELOG. - Blocking:
LCK_M_*wait types. - Memory pressure:
RESOURCE_SEMAPHORE.
A basic architecture for ongoing monitoring
Why this matters
Wait statistics don't replace execution plan analysis or index review - they point you toward which of those to prioritize. Treating them as a triage step rather than a final answer has saved me from chasing the wrong fix more than once.