当SQL Server的性能变差时,最可能发生的是以下两件事:

  • 首先,某些查询产生了系统资源上很大的压力。这些查询影响整个系统的性能,因为服务器无法足够快速地服务其他SQL查询。
  • 另外,开销较大的查询阻塞了其他请求相同数据库资源的查询,进一步降低了这些查询的性能。优化开销较大的查询不仅改进它们本身的性能,而且减少数据库阻塞和SQL Server资源压力从而提高了其他查询的性能。

识别开销较大的查询

  SQL Server的目标是在最短时间内将结果集返回给用户。为此,SQL Server查询优化器生成一个成本效益高的查询执行计划。查询优化器计算许多因素的权重,包括执行查询所需要的CPU、内存以及磁盘I/O的使用情况-这些均来自于由索引维护或过程中生成的统计。通常开销最低的计划有最少的I/O,因为I/O操作代价昂贵。

  逻辑读提供指出了查询产生的内存压力。它还提供了磁盘压力指标,因为内存页面必须在操作查询中被备份,在第一次数据访问期间写入,并且在内存瓶颈时被移到磁盘上。查询的逻辑读数量越大,磁盘压力的可能性就越大。过多的逻辑页面也增加了CPU用于管理这些页面的负载。

  导致大量逻辑读的查询通常在相应的大数据集上得到锁。即使读也需要在所有数据上的共享锁。这些查询阻塞了其他请求修改这些数据的查询,但是不阻塞读取数据的查询。因为这些查询固有的开销并且需要长时间执行,他们持续地阻塞其他查询。被阻塞的查询进一步阻塞查询,引入了数据中的阻塞链。

  识别开销较大的查询并优化它们有如下意义:

  •   增进开销较大的查询本身的性能;
  •   降低系统资源上的总体压力;
  •   较少数据库阻塞;

  其中开销较大的查询可以被分为如下两类:

  •   单词执行:查询的一次单独执行开销较大;
  •   多次执行:查询本身开销并不大,但是该查询的重复执行导致系统资源上的压力;

  1、单次执行开销较大的查询

  可以分析SQL Profiler跟踪输出文件来识别开销较大的查询。比如,如果对识别执行大量的逻辑读的查询感兴趣,应该在跟踪输出的Reads数据列上排序。

  •   捕捉表示典型工作负载的Profiler跟踪;
  •   将跟踪输出保存到一个跟踪文件;
  •   打开跟踪文件进行分析;
  •   通过事件选择选项卡,单击组织列按钮,在Reads列上分组跟踪输出。

  

  跟踪输出如下:

  

  在某些情况下,可能从系统监视器输出中识别CPU上的大压力。CPU上的压力可能是因为大量CPU密集型操作,如存储过程重编译、总计函数、数据排序、哈希连接等。在这种情况下,应该在CPU列上排序Profiler跟踪输出以识别使用大量处理器周期的查询。

  2、多次执行开销较大的查询

  有时候一个查询可能本身开销并不大,但是同一查询多次执行的累积效应可能造成系统资源的压力。在Reads列上排序对识别这种类型的查询没有帮助。如果希望知道查询的多次执行进行的总读取数,不幸的是Profiler在这里不能直接提供帮助,但是仍然可以用以下方法得到这一信息。

  •   在Profiler中跟踪输出的以下列上分组:EventClass、TextData和Reads。对于相同EventClass和TextData的分组,手工计算所有对应的Reads的总和。
  •   在Profiler中选择文件=》另存为=》跟踪表将输出到一个跟踪表。也可以使用内建函数fn_trace_gettable和Profiler的跟踪文件输出导入到一个跟踪表。
  •   访问sys.dm_exec_query_stats DMV从生产服务器上检索信息。这假设打算处理一个即时的问题并且不关注历史问题。

  在将跟踪输入保存到文件以后,先将跟踪数据导入到一张表:

SELECT * INTO TraceTable
FROM ::fn_trace_gettable('D:\123.trc',default)

  然后执行以下语句:

SELECT COUNT(*) AS TotalExecutions,EventClass,
CAST(TextData AS NVARCHAR(MAX)) TextData,
SUM(Duration) AS Duration_Total,
SUM(CPU) AS CPU_Total, SUM(Reads) AS Reads_Total,
SUM(Writes) AS Writes_Total
FROM TraceTable
GROUP BY EventClass,CAST(TextData AS NVARCHAR(MAX))
ORDER BY Reads_Total DESC

  脚本中的TotalExecutions列指出了查询被执行的次数,Reads_Total列指出了该查询多次执行所进行的读操作的总数。注意NTEXT不支持GROUP BY,因此要转换一下类型。

  这个方法识别出来的开销较大的查询比Profiler识别出的单次执行的开销较大查询更好地指出了负载。例如,一个需要50个读操作的查询可能执行1000次。这个查询本身被认为足够经济了,但是执行的读操作总是是5万,这不能被认为是经济的。优化这个查询降低读操作数,即使每次执行减少10次,读操作数也将降低1万次。这比优化一个5千次读操作的查询更有利。

  从sys.dm_exec_query_stats视图中得到相同的信息只需要一个查询:

SELECT ss.sum_execution_count
,t.TEXT
,ss.sum_total_elapsed_time
,ss.sum_total_worker_time
,ss.sum_total_logical_reads
,ss.sum_total_logical_writes
FROM (SELECT s.plan_handle
,SUM(s.execution_count) sum_execution_count
,SUM(s.total_elapsed_time) sum_total_elapsed_time
,SUM(s.total_worker_time) sum_total_worker_time
,SUM(s.total_logical_reads) sum_total_logical_reads
,SUM(s.total_logical_writes) sum_total_logical_writes
FROM sys.dm_exec_query_stats s
GROUP BY s.plan_handle
)AS ss
CROSS APPLY sys.dm_exec_sql_text(ss.plan_handle) t
ORDER BY sum_total_logical_reads DESC

  这比所有收集跟踪数据所需要的工作要容易得多,那么为什么还要使用跟踪数据?使用跟踪的主要原因是精确性。sys.dm_exec_query_stats视图是给定计划已经存在于内存中时的流动总计,时间点并不精确。另一方面,跟踪是运行的任何时间段的历史记录。甚至可以在数据库中加入跟踪,并且拥有一系列可以比依靠给定的瞬间更精确地生成总计的数据。但是对定位性能问题的理解关注是查询运行缓慢的时点,这是sys.dm_exec_query_stats不可替代的场合。

  3、识别运行缓慢的查询

  如果运行缓慢的查询的响应时间变得不可接受,那么应该分析性能下降的原因。但是不是所有运行缓慢的查询都是由于资源问题造成的,其他需要关心的因素如阻塞也可能导致缓慢的查询。

  为了发现运行缓慢的查询,在Duration列上分组跟踪输出。

  

  跟踪输出如下:

  

  对于运行缓慢的系统,应该注意优化过程前后运行缓慢的持续查询时间。应用优化技术之后,应该计算在系统上的总体性能。优化步骤可能负面地影响其他查询,使其变慢。

利用SQL Profiler处理开销较大的查询的更多相关文章

  1. 利用SQL Profiler 追踪数据库操作

    SQL Server 事件探查器 是一个界面,用于创建和管理跟踪并分析和重播跟踪结果. 这些事件保存在一个跟踪文件中,稍后试图诊断问题时,可以对该文件进行分析或用它来重播一系列特定的步骤. SQL S ...

  2. SQL记录-小表join大表查询例子

  3. SQL Profiler工具简介

    一.SQL Profiler工具简介 SQL Profiler是一个图形界面和一组系统存储过程,其作用如下: 图形化监视SQL Server查询: 在后台收集查询信息: 分析性能: 诊断像死锁之类的问 ...

  4. SqlServer查看表、存储过程、耗时查询、当前进程、开销较大的语句

    --查看数据库中表的语句 SELECT s2.dbid , DB_NAME(s2.dbid) AS [数据库名] , --s1.sql_handle , ( SELECT TOP 1 SUBSTRIN ...

  5. SQLServer数据库之SqlServer查看表、存储过程、耗时查询、当前进程、开销较大的语句

    --查看数据库中表的语句 SELECT s2.dbid , DB_NAME(s2.dbid) AS [数据库名] , --s1.sql_handle , ( , ( ( THEN ( LEN(CONV ...

  6. SQL命令语句进行大数据查询如何进行优化

    SQL 大数据查询如何进行优化? 1.对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索 2.应尽量避免在 where 子句中对字段进行 null 值 ...

  7. 【性能诊断】二、单功能场景的性能分析(fiddler、SQL Profiler)

    Fiddler fiddler是最强大最好用的Web调试工具之一,它能记录所有客户端和服务器的http和https请求,允许你监视,设置断点,甚至修改输入输出数据. 使用Fiddler无论对开发还是测 ...

  8. 利用SQL注入漏洞登录后台

    所谓SQL注入,就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串,最终达到欺骗服务器执行恶意的SQL命令,比如先前的很多影视网站泄露VIP会员密码大多就是通过WEB表单递交查询 ...

  9. Key Lookup开销过大导致聚集索引扫描

    以前总结过一篇文章SQL SERVER中什么情况会导致索引查找变成索引扫描 介绍了几种索引查找(Index Seek)变成索引扫描(Index Scan)的情形.昨天写一篇文章的时候,也遇到了一个让人 ...

随机推荐

  1. 10个工具让你的 shell 脚本更强大

    10个工具让你的 shell 脚本更强大 很多人误以为shell脚本只能在命令行下使用.其实shell也可以调用一些GUI组件,例如菜单,警告框,进度条等等.你可以控制最终的输出,光标位 置还有各种输 ...

  2. 初识lucene

    lucene的介绍网上有好多,再写一遍可能有点多余了. 使用lucene之前,有一系列的疑问 为什么lucene就比数据库快? 倒排索引是什么,他是怎么做到的 lucene的数据结构是什么样的,cpu ...

  3. linux下strace命令详解

    简介 strace常用来跟踪进程执行时的系统调用和所接收的信号. 在Linux世界,进程不能直接访问硬件设备,当进程需要访问硬件设备(比如读取磁盘文件,接收网络数据等等)时,必须由用户态模式切换至内核 ...

  4. Hdu3072-Intelligence System(强连通求最小值)

    After a day, ALPCs finally complete their ultimate intelligence system, the purpose of it is of cour ...

  5. Linux Security模块

    一.Linux Security Modules Linux Security Modules (LSM) 是一种 Linux 内核子系统,旨在将内核以模块形式集成到各种安全模块中.在 2001 年的 ...

  6. Handsontable 新增一行 默认值

    效果图:

  7. Linux查看系统信息

    系统 # uname -a # 查看内核/操作系统/CPU信息 # head -n 1 /etc/issue # 查看操作系统版本 # cat /proc/cpuinfo # 查看CPU信息 # ho ...

  8. UVA247- Calling Circles(有向图的强连通分量)

    题目链接 题意: 给定一张有向图.找出全部强连通分量,并输出. 思路:有向图的强连通分量用Tarjan算法,然后用map映射,便于输出,注意输出格式. 代码: #include <iostrea ...

  9. extjs tree check 级联选择

    extjs4 tree check 级联选择 实现效果: 关键代码: function changeAllNode(node, isCheck) { allChild(node, isCheck); ...

  10. [HDU 1535]Invitation Cards[SPFA反向思维]

    题意: (欧洲人自己写的题面就是不一样啊...各种吐槽...果断还是看晕了) 有向图, 有个源叫CCS, 求从CCS到其他所有点的最短路之和, 以及从其他所有点到CCS的最短路之和. 思路: 返回的时 ...