Initial SQL Server performance issues (4/4): List the most resource-intensive sessions

In the last 3 articles, we discussed a list of different queries that reflect the current state of the server.

• Initial SQL Server performance issues (1/4): Server overview
• Initial SQL Server performance issues (2/4): List the sessions waiting for resources
• Initial SQL Server performance issues (3/4): List blocked sessions

In this article we look at the list of execution states from the plan cache.

1 /*****************************************************************************************2 List Heavy query based on Cpu/io. Change the ORDER BY clause appropriately3 ******************************************************************************************/4SELECT TOP -5 db_name (qt.dbid) as DatabaseName6 , DATEDIFF (Mi,creation_time,getdate ()) as [age of the Plan (Minutes)]7 , last_execution_time as [last execution time]8 , qs.execution_count as [total execution count]9, CAST ((qs.total_elapsed_time)/1000000.0As DECIMAL ( -,2)) [Total Elapsed time (s)]Ten, CAST ((qs.total_elapsed_time)/1000000.0/Qs.execution_count as DECIMAL ( -,2) as [Average execution time (s)] One, CAST ((qs.total_worker_time)/1000000.0As DECIMAL ( -,2) ) As [total CPU time (s)] A, CAST (Qs.total_worker_time *100.0/Qs.total_elapsed_time as DECIMAL ( -,2) As [%CPU] -, CAST ((qs.total_elapsed_time-qs.total_worker_time) *100.0/qs.total_elapsed_time as DECIMAL ( -,2) As [%Waiting] -, CAST ((qs.total_worker_time)/1000000.0/Qs.execution_count as DECIMAL ( -,2) as [CPU time average (s)] the, CAST ((qs.total_physical_reads)/Qs.execution_count as DECIMAL ( -,2) as [AVG physical Read] -, CAST ((qs.total_logical_reads)/Qs.execution_count as DECIMAL ( -,2) as [Avg Logical Reads] -, CAST ((qs.total_logical_writes)/Qs.execution_count as DECIMAL ( -,2) as [Avg Logical writes] - , Max_physical_reads + , Max_logical_reads - , Max_logical_writes +, SUBSTRING (QT. TEXT, (qs.statement_start_offset/2) +1, (case when qs.statement_end_offset =-1 AThen LEN (CONVERT NVARCHAR (MAX), Qt. TEXT)) *2 at ELSE Qs.statement_end_offset -End-qs.statement_start_offset)/2) +1) as [individual Query] - , Qt. TEXT as [Batch Statement] - , Qp.query_plan - From SYS. Dm_exec_query_stats QS - Cross APPLY SYS. Dm_exec_sql_text (Qs.sql_handle) as Qt in Cross APPLY SYS. Dm_exec_query_plan (qs.plan_handle) QP -WHERE qs.total_elapsed_time >0 to ORDER by + [Total CPU time (s)] ---[AVG physical Read] the--[Avg Logical Reads] *--[Avg Logical writes] $--[Total Elapsed time (s)]Panax Notoginseng--[Total execution Count] -DESC

View Code

each column of output results is described below:

• DatabaseName the database environment (database name) of the execution plan.
• The age of the Plan (Minutes) program caches the planned lifetime in minutes.
• Last execution the date and time of this plan's execution.
• Total execution count number of executions since the last compilation, the total number of executions (since the last compilation) in the execution plan lifetime [age of the Plan (Minutes)].
• Total Elapsed time (s) after the total number of executions of this plan, in seconds.
• Average execution Time (s) the average duration of each execution of the plan, in seconds.
• Total CPU time (s) after the total execution of this plan has been performed, in seconds.
• The% CPU is more CPU-intensive than total Elapsed time (s).
• % waiting is waiting for the resource to take longer than the total Elapsed time (s).
• The average CPU time, in seconds, that is executed per CPU for time average (s).
• Avg Physical read average physical readings per execution.
• Avg Logical Reads The average logical reading of each execution.
• Avg Logical writes the average number of logical writes per execution.
• Max_physical_reads a new maximum physical reading every time the execution is performed.
• Max_logical_reads a new maximum logical reading each time the execution is performed.
• Max_logical_writes a new maximum number of logical writes per execution.
• Individual some of the information in the query batch statement.
• Batch Statement batches query.
• Query_plan the execution plan in XML format, we can look at the diagram execution plan after clicking.

In general, we can analyze the specific statement information of the first 5 records (by modifying the collation). In most cases, we will find that problems occur in temporary table abuses, distinct statements, cursors, inappropriate table join conditions, inappropriate indexes, and so on. The other recurring problem is that the stored procedure has a large number of calls to the database (both CPU consumption and execution time are small). This need and developer feedback, modify the implementation of the specific way. If the data is often called, you can use the caching method in your program to avoid multiple interactions with the server. Some calls to the database simply check for changes to the resulting data. Some calls to the database are checked for new records in the database table and must be processed immediately. To do this, the program queries the table multiple times within 1 seconds to find the unhandled record. This can be resolved by inserting data from the program's asynchronous calls to and from the table, or by using the SqlDependency in the. NET Framework. (SqlDependency provides the ability to automatically update the data (or cache) by SqlDependency triggering an onchange event to notify the application when the data in the monitored database changes. ）

Initial SQL Server performance issues (4/4): List the most resource-intensive sessions