I am trying to understand the active expensive queries and recent expensive queries in Activity Monitor. What is expensive means here? Does it means expensive in term of cpu, block, memory, reads?
2 Answers
It depends on what column you sort by. To dig deeper, I suggest you read the source code that these are on. I blogged about AM a while ago, here is a part from that blog post:
The “Recent Expensive Queries” pane:
This shows the most expensive queries, based on what column you sort on, executed since the last snapshot. If you have, say, a 10 second snapshot interval, you will only see the queries executed during these 10 seconds. AM uses a procedure named #am_get_querystats to collect the information. There are a few things going on inside this procedure, but at the most basic level, it uses sys.dm_exec_query_stats and sys.dm_exec_requests to get queries from cache and currently executing queries. It then does some processing and store the result in temp tables so we later can sort on different columns depending on what metric we are interested in. I suggest that you spend some time with the source code if you want to dig deeper.
The “Active Expensive Queries” pane:
This is very straight forward. It executes a query which uses sys.dm_exec_requests joined to a few other DMVs.
Here's a link to my blog post: http://sqlblog.karaszi.com/explaining-activity-monitor/
-
I thought activity monitor is build using native code rather than SQL Commented Nov 17, 2020 at 7:53
-
What do you mean by "native code"? The information has to come from somewhere, and that somewhere is SQL server and the only interface to SQL Server is SQL. Then of course the client app uses an API and is written in some language, but the interface to SQL Server is SQL. Commented Nov 17, 2020 at 8:05
-
Actually SQL Server is built with C/C++ en.wikipedia.org/wiki/Microsoft_SQL_Server. I thought they built the same with C/C++ Commented Nov 17, 2020 at 8:12
-
1YEs, I said in my earlier comment that the client app is written in some language (C++ in this case). But the point is that the information is coming from somewhere, and that is from a number of SQL queries submitted to SQL Server. See my blog post, it is all in there, if you don't believe me. :-) Commented Nov 17, 2020 at 9:40
-
I have a feeling that you wonder in the end if the computations are done in T-SQL or C++. From the trace, it seems that they (at least the majority of them) are done in T-SQL. If they were done in C++, we would have to rely 100% on what was documented on this by MS - nothing in this case. Thanks to it being T-SQL, we can reverse-engineer based on a trace and the T-SQL code. Commented Nov 17, 2020 at 10:49
Useful Query here
SELECT TOP(50) qs.execution_count AS [Execution Count],
(qs.total_logical_reads)*8/1024.0 AS [Total Logical Reads (MB)],
(qs.total_logical_reads/qs.execution_count)*8/1024.0 AS [Avg Logical Reads (MB)],
(qs.total_worker_time)/1000.0 AS [Total Worker Time (ms)],
(qs.total_worker_time/qs.execution_count)/1000.0 AS [Avg Worker Time (ms)],
(qs.total_elapsed_time)/1000.0 AS [Total Elapsed Time (ms)],
(qs.total_elapsed_time/qs.execution_count)/1000.0 AS [Avg Elapsed Time (ms)],
qs.creation_time AS [Creation Time]
,t.text AS [Complete Query Text], qp.query_plan AS [Query Plan]
FROM sys.dm_exec_query_stats AS qs WITH (NOLOCK)
CROSS APPLY sys.dm_exec_sql_text(plan_handle) AS t
CROSS APPLY sys.dm_exec_query_plan(plan_handle) AS qp
WHERE t.dbid = DB_ID()
ORDER BY qs.execution_count DESC OPTION (RECOMPILE);-- frequently ran query
-- ORDER BY [Total Logical Reads (MB)] DESC OPTION (RECOMPILE);
-- High Disk Reading query
-- ORDER BY [Avg Worker Time (ms)] DESC OPTION (RECOMPILE);-- High CPU query
-- ORDER BY [Avg Elapsed Time (ms)] DESC OPTION (RECOMPILE);-- Long Running query