初涉SQL Server性能问题(4/4):列出最耗资源的会话

原文:初涉SQL Server性能问题(4/4):列出最耗资源的会话

在上3篇文章里,我们讨论了列出反映服务器当前状态的不同查询。

这篇文章我们看下从计划缓存里列出执行状态。

 1 /*****************************************************************************************
 2 List heavy query based on CPU/IO. Change the order by clause appropriately
 3 ******************************************************************************************/
 4 SELECT TOP 20
 5 DB_NAME(qt.dbid) AS DatabaseName
 6 ,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.0 AS DECIMAL(28,2)) [Total Elapsed Time(s)]
10 ,CAST((qs.total_elapsed_time ) / 1000000.0/ qs.execution_count AS DECIMAL(28, 2)) AS [Average Execution time(s)]
11 ,CAST((qs.total_worker_time) / 1000000.0 AS DECIMAL(28,2)) AS [Total CPU time (s)]
12 ,CAST(qs.total_worker_time * 100.0 / qs.total_elapsed_time AS DECIMAL(28,2)) AS [% CPU]
13 ,CAST((qs.total_elapsed_time - qs.total_worker_time)* 100.0 /qs.total_elapsed_time AS DECIMAL(28, 2)) AS [% Waiting]
14 ,CAST((qs.total_worker_time) / 1000000.0/ qs.execution_count AS DECIMAL(28, 2)) AS [CPU time average (s)]
15 ,CAST((qs.total_physical_reads) / qs.execution_count AS DECIMAL(28, 2)) AS [Avg Physical Read]
16 ,CAST((qs.total_logical_reads) / qs.execution_count AS DECIMAL(28, 2))  AS [Avg Logical Reads]
17 ,CAST((qs.total_logical_writes) / qs.execution_count AS DECIMAL(28, 2)) AS [Avg Logical Writes]
18 ,max_physical_reads
19 ,max_logical_reads
20 ,max_logical_writes
21 , SUBSTRING (qt.TEXT,(qs.statement_start_offset/2) + 1,((CASE WHEN qs.statement_end_offset = -1
22    THEN LEN(CONVERT(NVARCHAR(MAX), qt.TEXT)) * 2
23    ELSE qs.statement_end_offset
24    END - qs.statement_start_offset)/2) + 1) AS [Individual Query]
25 , qt.TEXT AS [Batch Statement]
26 , qp.query_plan
27 FROM SYS.DM_EXEC_QUERY_STATS qs
28 CROSS APPLY SYS.DM_EXEC_SQL_TEXT(qs.sql_handle) AS qt
29 CROSS APPLY SYS.DM_EXEC_QUERY_PLAN(qs.plan_handle) qp
30 WHERE qs.total_elapsed_time > 0
31 ORDER BY
32 [Total CPU time (s)]
33 --[Avg Physical Read]
34 --[Avg Logical Reads]
35 --[Avg Logical Writes]
36 --[Total Elapsed Time(s)]
37 --[Total Execution Count]
38 DESC 

输出结果的每列说明介绍如下:

  • DatabaseName 执行计划的数据库环境(数据库名)。
  • Age of the Plan(Minutes) 计划缓存里计划的生存期,单位为分钟。
  • Last Execution Time 这个计划的上次执行日期和时间。
  • Total Execution Count   自上次编译后,总执行次数;在执行计划生存期内[Age of the Plan(Minutes)],总执行次数(自上次编译后)。
  • Total Elapsed Time(s)   执行这个计划总执行次数后[Total Execution Count]的总占用时间,单位为秒。
  • Average Execution time(s) 这个计划每次执行的平均时间,单位为秒。
  • Total CPU time (s)  执行这个计划总执行次数后[Total Execution Count]的总CPU时间,单位为秒。
  • % CPU 与Total Elapsed Time(s)相比,CPU占用时间比。
  • % Waiting  与Total Elapsed Time(s)相比,等待资源占用时间比。
  • CPU time average (s) 每次执行的平均CPU时间,单位为秒。
  • Avg Physical Read 每次执行的平均物理读数。
  • Avg Logical Reads 每次执行的平均逻辑读数。
  • Avg Logical Writes 每次执行的平均逻辑写数。
  • max_physical_reads 每次执行的时候,出新最大物理读数。
  • max_logical_reads 每次执行的时候,出新最大逻辑读数。
  • max_logical_writes 每次执行的时候,出新最大逻辑写数。
  • Individual Query  批处理语句的部分信息。
  • Batch Statement  批处理查询。
  • query_plan XML格式的执行计划,点击后我们可以看图示执行计划。

一般我们可以分析前5条记录(通过修改排序规则)的具体语句信息。大多数情况,我们会发现问题出现在临时表的滥用,distinct语句,游标,不合适的表连接条件,不合适的索引等等。其他经常发生的问题是,存储过程对数据库的大量调用(CPU消耗和执行时间都很小)。这个需要和开发人员反馈,修改下具体的实现方式。如果数据经常被调用,可以在程序里使用缓存方法避免与服务器的多次交互。有些对数据库的调用只是检查结果数据是否有改变。有些对数据库的调用是为检查数据库表里是否有新记录,且必须马上处理的。为了完成这些操作,程序会在1秒内多次查询表来找出未处理的记录。这个可以通过程序的异步调用来往表里插入数据来解决,或可以使用.net框架里的sqlDependency来解决。(sqlDependency提供了这样一种能力:当被监测的数据库中的数据发生变化时,SqlDependency会自动触发OnChange事件来通知应用程序,从而达到让系统自动更新数据(或缓存)的目的。)

时间: 2024-11-08 19:14:55

初涉SQL Server性能问题(4/4):列出最耗资源的会话的相关文章

初涉SQL Server性能问题(2/4):列出等待资源的会话

原文:初涉SQL Server性能问题(2/4):列出等待资源的会话 在初涉SQL Server性能问题(1/4)里,我们知道了如何快速检查服务器实例上正运行的任务数和IO等待的任务数.这个是轻量级的脚本,不会给服务器造成任何压力,即使服务器在高负荷下,也可以正常获得结果. 问题检测的第2步是获取在进行任何资源等待的会话.下面的脚本会帮助我们获得这些信息.这个查询需要预建立一个函数,如果会话是由SQL Server代理启动的话,会显示具体的作业名. 1 /********************

初涉SQL Server性能问题(3/4):列出阻塞的会话

原文:初涉SQL Server性能问题(3/4):列出阻塞的会话 在 初涉SQL Server性能问题(2/4)里,我们讨论了列出等待资源或正运行的会话脚本.这篇文章我们会看看如何列出包含具体信息的话阻塞会话清单. 1 /******************************************************************************************/ 2 CREATE FUNCTION [dbo].dba_GetStatementForSpid

初涉SQL Server性能问题(1/4):服务器概况

原文:初涉SQL Server性能问题(1/4):服务器概况 当你作为DBA时,很多人会向你抱怨:"这个程序数据加载和蜗牛一样,你看看是不是服务器出问题了?"造成这个问题的原因有很多.可能是程序应用服务器问题,网络问题,程序实现方式问题,数据库服务器负荷过重.不管是哪个问题,数据库总是第一个被抱怨的.我们DBA的职责就是找出问题所在,并解决它们. 问题解决第一步,诊断分析: 1 SELECT 2 parent_node_id AS Node_Id, 3 COUNT(*) AS [No.

怎么整理 SQL Server性能调整清单

我需要做什么?太多了,我从哪里开始?我下一步该做什么?哇,我的SQL Server起来了!如果你从一开始就不知道要到哪里去,并且异常中断了SQL Server的运行,那么你做到了.看看这篇如何获得高性能SQL Server的性能调整清单吧. SQL Server性能调整清单 准备 当你开始解决一个现有的性能调整问题或者从一个新的系统开始,非常期望得到高性能,那么花些时间在计划和分析如何达到项目目标吧.确保整个团队都理解了SQL Server现在正在做什么,它将会作什么,以及它以后应该如何做. 有

SQL Server 性能优化之——系统化方法提高性能

原文http://www.cnblogs.com/BoyceYang/archive/2013/06/15/3138142.html 阅读导航 1. 概述 2. 规范逻辑数据库设计 3. 使用高效索引设计 4. 使用高效的查询设计 5. 使用技术分析低性能 6. 总结   1. 概述 在比较大的范围内找出能够大幅提高性能的区域,并且专注于分析这个区域,这是最有效的优化SQL Server性能的方式.否则,大量的时间和精力可能被浪费在不能提高很大性能的区域.在这里并没有讨论关于多用户并发所带来的性

SQL Server性能的改进得益于逻辑数据库设计

索引设计和查询设计方面.反过来说,最大的性能问题常常是由其中这些相同方面中的不足引起的.其实SQL优化的实质就是在结果正确的前提下,用优化器可以识别的语句,充份利用索引,减少表扫描的I/O次数,尽量避免表搜索的发生.其实SQL的性能优化是一个复杂的过程,以上这些只是在应用层次的一种体现,深入研究还会涉及数据库层的资源配置.网络层的流量控制以及操作系统层的总体设计. SQL语句优化的原则: ◆1.使用索引来更快地遍历表 缺省情况下建立的索引是非群集索引,但有时它并不是最佳的.在非群集索引下,数据在

清单:负载测试——SQL Server性能调整的魔法棒

没有什么事情比这更糟了,采纳一个新的应用程序,而它的性能是如此的糟糕,导致业务在一片惊叫声中暂停.这并不是新出现的现象:这就是事实,我经常遇到这样的事实.我打赌你也曾经经历过.那么如何防止这些性能问题,有什么解决方案? 在这些应用程序"在惊叫声中暂停"的情况中,应用程序通常都已经在按照功能性分配的短暂的测试时间内进行过适当的测试了.但是充分吗?由于竞争和全球经济的原因,迅速应用于业务意味着只进行了最小化的测试.同样,最小化的测试也成为按时将应用程序发布给用户群体的可接受的风险之一.另一

如何优化Windows OS使SQL Server性能最优化

1.问题提出   这些天菜鸟又遇到麻烦事儿了.Server Team交给菜鸟的这批服务器跑起SQL Server来老是不顺畅.菜鸟情不至尽的想起了老鸟,于是,敲开了老鸟办公室的门:   "鸟哥,到底我们要如何定制化或者说如何优化我们的Windows Server OS来使得我们的SQL Server达到最大程度的性能优化呢?".老鸟还没有反应过来,菜鸟劈头盖脸的问道.   老鸟顿了两秒,自信的回答道:"菜鸟,有进步啊,开始学会思考问题了.我们可以按照如下方法来优化我们的操作系

MSSQL · 实现分析 · Extend Event实现审计日志对SQL Server性能影响

背景 在上一篇月报分享中,我们介绍了SQL Server实现审计日志功能的四种方法,最终的结论是使用Extend Event(中文叫扩展事件)实现审计日志方法是最优选择,详情参见MSSQL · 实现分析 · SQL Server实现审计日志的方案探索.那么,使用Extend Event实现审计日志的方案会面对如下疑问: Extend Event是否满足可靠性要求 Extend Event是否满足吞吐量要求 Extend Event对SQL Server本身语句查询性能影响到底有多大 这篇文章就是