SQL SERVER – Getting to understand SQL Server Activity Monitor in SSMS

This site is flooded with blog posts around SQL Server Management Studio’s Activity Monitor capability. In fact, we have written few special case scenarios on how to use the same. In this blog post, I might not want to rehash the same, but take a stance on how I explained using Activity monitor with one of my DBA friends in a recent community event. I felt it was important to capture the notes and have it here as a reference for future use. I am sure you will also find it useful and share your experience.

So what are some of the lesser used building blocks within Activity Monitor?

Resource Waits

This section provides a summary of what types of waits are accruing at the fastest rate. Each wait type is categorized into a wait category. At each refresh interval the tool saves the current total wait count and time (sys.dm_os_wait_stats) and any pending waits (sys.dm_exec_requests) into a temporary table #am_wait_stats. At the next refresh, the difference in number of waits and amount of wait time between the current and previous snapshot is calculated and displayed in this grid.

The fact that this includes waiting requests allows you to see “in-progress” waits rather than seeing spikes only after the wait completes. If you have a situation where one spid is blocked waiting on a lock for the entire refresh interval time you will see a wait rate of 1000 ms/sec on the Lock wait category. If two spids are blocked you’ll see a rate of 2000 ms/sec and so forth.

Note that query which encounter a lot of waits may not rank high enough to show up in the “Recent Expensive Queries”. Since these queries are waiting they do not consume CPU and may not perform logical reads/writes at a fast enough rate to fall into the Top N queries reported in that grid. Using the blocking scenario described above, the query will be consuming no CPU or any reads/writes and almost never shows up as an expensive query while it was running.

If you have a short refresh interval (e.g., 1 second) and a wait that is short the wait time column will show a brief spike in wait time which will drop back to zero on the next refresh.

IMPORTANT: This section shows CPU as a wait, but it only includes SOS_SCHEDULER_YIELD and signal wait time. It does not include consumed CPU like the CPU wait category in the management data warehouse reports.

Data File I/O

This section shows which database and files are responsible for the most physical IO. You can see the databases with the most physical reads or writes (in megabytes per second), and average response time per IO during the interval. The underlying data for this section comes from sys.dm_os_virtual_file_stats and thus includes both data and log files.

The underlying DMV clears its data when a database is taken offline. Since this section shows IO rates (vs total IO) you should still be able to compare metrics so long as the database isn’t taken offline/online at the same kind of interval as the Activity Monitor refresh interval. With a long refresh interval and autoclose databases you may see rates that are inaccurate – so be careful with this scenario.

Recent Expensive Queries

This section of the report shows queries that are currently running or have run in the last four hours which have significant resource consumption. The chart displays the top N (currently N=20) queries by any of the following metrics: CPU consumption rate, physical reads rate, logical writes rate, logical reads rate, and average duration.

This collector takes the delta in values (CPU consumption, reads, writes, …) between the current collection and a previous collection of data X seconds ago and divides this difference by the refresh interval to compute a rate of resource consumption. To find the queries that are using the most CPU you order by CPU ms/sec; the queries doing the most IO you order by reads/sec, etc.

The underlying queries from the DMVs are grouped by query_hash and query_plan_hash (query and plan fingerprints). Grouping on these columns allows Activity Monitor to find similar, non-parameterized queries that collectively consumed significant resources.

Hope this gives a reentry to understanding Activity monitor better again. Do let me know your thoughts on how you used the same in your environments.

Reference: Pinal Dave (http://blog.sqlauthority.com)