As a SQL Server DBA, many times we get a common complaint: “SQL Server is slow.” But before doing any tuning, we should understand where SQL Server is waiting. SQL Server wait stats help us to identify whether the issue is related to CPU, disk, memory, locking, parallelism, or network.
SELECT TOP 20
wait_type,
wait_time_ms / 1000.0 AS wait_time_seconds,
waiting_tasks_count,
signal_wait_time_ms / 1000.0 AS signal_wait_seconds,
(wait_time_ms - signal_wait_time_ms) / 1000.0 AS resource_wait_seconds
FROM sys.dm_os_wait_stats
WHERE wait_type NOT IN
(
'SLEEP_TASK',
'BROKER_TASK_STOP',
'BROKER_TO_FLUSH',
'SQLTRACE_BUFFER_FLUSH',
'CLR_AUTO_EVENT',
'CLR_MANUAL_EVENT',
'LAZYWRITER_SLEEP',
'SLEEP_SYSTEMTASK',
'SLEEP_BPOOL_FLUSH',
'BROKER_EVENTHANDLER',
'XE_TIMER_EVENT',
'XE_DISPATCHER_WAIT',
'FT_IFTSHC_MUTEX',
'CHECKPOINT_QUEUE',
'REQUEST_FOR_DEADLOCK_SEARCH',
'LOGMGR_QUEUE',
'ONDEMAND_TASK_QUEUE',
'BROKER_RECEIVE_WAITFOR',
'PREEMPTIVE_OS_GETPROCADDRESS',
'PREEMPTIVE_OS_AUTHENTICATIONOPS',
'WAITFOR',
'DISPATCHER_QUEUE_SEMAPHORE',
'HADR_FILESTREAM_IOMGR_IOCOMPLETION'
)
ORDER BY wait_time_ms DESC;
Explanation
- wait_type shows what SQL Server is waiting for.
- wait_time_seconds shows total wait time.
- waiting_tasks_count shows how many tasks waited on this wait type.
- signal_wait_seconds means the task got the resource but was waiting for CPU.
- resource_wait_seconds means the task was waiting for the actual resource like disk, lock, memory, or network.
- PAGEIOLATCH_SH usually points to disk read latency or missing indexes.
- CXPACKET and CXCONSUMER are related to parallelism.
- LCK_M_* wait types are related to blocking.
- WRITELOG can indicate transaction log write delay.
- ASYNC_NETWORK_IO may happen when application is slow to consume data.
Do not tune SQL Server only by seeing one wait type. Wait stats are cumulative from the last SQL Server restart or wait stats reset.
If you want fresh data, you can capture wait stats before and after the issue window and compare the difference.
Be careful before clearing wait stats in production.
Do not clear wait stats in production unless you have a proper troubleshooting reason.
DBCC SQLPERF('sys.dm_os_wait_stats', CLEAR)Use this only when you really need fresh wait stats for troubleshooting.
ConclusionWait stats are very useful for SQL Server performance troubleshooting. They help us understand where SQL Server is spending time. As a DBA, this should be one of the first checks during performance issues.
Related DBA Scrolls Posts
This post can link to your existing posts:
