Wait Stats Basics: How Waits Work in SQL Server

Wait stats basics start with one simple idea: a query in SQL Server is always either working or waiting. SQL Server writes down every wait, by type and by time. Read that list, and it tells you where your server’s time goes.

This post is part of my wait stats series, told as one story at the Clipboard Diner. Every post is listed in the series guide.

Night 1 at the Clipboard Diner

The first night after the critic’s postcard, Casey didn’t fix anything. Casey watched. At 6:40 PM a trucker ordered the Garden Hash: potatoes, peppers and onions. Casey clicked the stopwatch the moment the ticket hit the rail.

The ticket hung there for two minutes. All four burners were busy, so it waited its turn. Then Ace grabbed it, reached for the potatoes, and stopped. The potato bin on the prep counter was empty. The ticket went on the spike to wait while the dishwasher ran down to the basement cooler.

Six minutes later a fresh sack of potatoes came up the stairs. By then the burners were full again, so the ticket went back on the rail for one more minute. Ace finally cooked it. The hash needed four minutes of cooking. It reached the table thirteen minutes after the order.

Casey looked at the stopwatch for a long time. Then Casey picked up the new clipboard and wrote the first line of the month: Cooking: 4 minutes. Waiting: 9. Nobody in the kitchen had been lazy. Every one of those nine minutes had a reason, and none of them showed up on the bill.

Running, Runnable and Suspended

That plate of hash is every query on your server. While a request works, each of its tasks moves between three main states. A parallel request has several tasks, so some can run while others wait. Learn these three words and the rest of this series gets easier.

Running means the request is on a CPU right now. That’s Ace at the burner. SQL Server gives each logical CPU a scheduler, and only one task runs on a scheduler at a time.

Suspended means the request needs something it doesn’t have yet. It can need a data page from disk, a lock another session holds, a memory grant, or a log write. That’s the ticket on the spike while the potatoes come up. SQL Server records this as a resource wait, and it names the wait type, such as PAGEIOLATCH_SH or LCK_M_X.

Runnable means the resource has arrived, and the request is ready to go. It’s waiting in line for a CPU. That’s the ticket back on the rail with its potatoes. SQL Server calls this time the signal wait.

A busy query goes around this loop thousands of times. Each trip through Suspended adds to a wait type. SQL Server keeps a running total for every wait type since the last restart, in a view called sys.dm_os_wait_stats. That view is Casey’s clipboard, and the sys.dm_os_wait_stats post reads it line by line.

One detail trips people up. The total wait time for a wait type already includes its signal wait time. So the resource part is the total minus the signal part. Tomorrow’s post is all about that split.

Why I Start With Waits

In my performance health checks, waits are the first thing I look at. CPU percent and disk counters tell me how busy a server is. Waits tell me what the queries themselves were stuck on. That’s a different question, and it’s usually the one the business cares about.

You could say a good monitoring tool already shows all of this. Fair point, and many do. But the tools read the same views you’ll learn here. When a chart looks strange, you’ll know what’s under it.

It’s tempting to tune the query that looks slowest and stop there. Then the server doesn’t get faster. The real culprit can be a tiny query that runs a million times, waiting on the log each time. The wait list shows that on the first morning.

Normal or a Problem?

See It on Your Server

This first query shows what user requests are doing right now. Run it while your server is busy. The status column shows the three states from the diner, plus sleeping and background. For a parallel request, the row shows the coordinator’s wait only.

-- What each user request is doing right now
SELECT r.session_id,
       r.status,
       r.wait_type,
       r.wait_time AS wait_ms,
       r.last_wait_type,
       r.cpu_time AS cpu_ms,
       r.total_elapsed_time AS elapsed_ms
FROM sys.dm_exec_requests AS r
JOIN sys.dm_exec_sessions AS s
    ON s.session_id = r.session_id
WHERE s.is_user_process = 1
ORDER BY r.total_elapsed_time DESC;

Compare cpu_ms with elapsed_ms for a long request. When elapsed time is far bigger than CPU time, the request spent most of its life waiting. The wait_type column says what it’s waiting on at this moment.

The second query is a first look at the clipboard. It splits each wait type into its resource part and its signal part.

-- Which 10 waits used the most time since the last restart, and how does each one split?
-- waited_ms = resource_part_ms + signal_part_ms
SELECT TOP (10)
       wait_type,
       wait_time_ms AS waited_ms,
       wait_time_ms - signal_wait_time_ms AS resource_part_ms,
       signal_wait_time_ms AS signal_part_ms,
       waiting_tasks_count AS times_waited
FROM sys.dm_os_wait_stats
WHERE waiting_tasks_count > 0
ORDER BY waited_ms DESC;

Don’t panic at the top rows. On most servers they’re background tasks that sleep on purpose. The next posts give you a filter that removes them, so the real waits rise to the top.

Fix It

This first lesson has nothing to fix yet. It gives you a habit instead. Here’s the order I follow on every server.

1. Look at wait time, not wait counts. A million tiny waits can matter less than ten long ones.
2. Filter out the harmless background waits before you read anything.
3. Measure a busy time window, not the totals since the last restart (Wait Stats Over Time).
4. Take the top real wait and read its post in this series.
5. Change one thing, then measure the same window again.

New in SQL Server 2022 and 2025

The three states and the meaning of a wait haven’t changed. What changed is how much SQL Server records for you. Since SQL Server 2022, Query Store is on by default for new databases. It keeps waits per query, grouped into categories, so you can see which query waited and on what.

SQL Server 2025 also turns on DOP feedback by default, in Enterprise and Enterprise Developer editions. It needs compatibility level 160 or higher and Query Store in READ_WRITE mode. That changes the mix of parallel waits on many servers, and Parallelism Wait Stats covers it. New databases on SQL Server 2025 start at compatibility level 170.

Related Reading

• Query Store Wait Stats: Why a Query Was Slow, Not Just That It Was
• Reading the Top Five Wait Types on Your Server

A slow query is not a mystery, it is a list of waits you haven’t read yet.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.