如果你的数据库应用系统中存茬有大量表，视图索引，触发器函数，存储过程sql语句等等，又性能低下而苦逼的你又要对其优化，那么你该怎么办哥教你，首先你要知道问题出在哪里如果想知道问题出在哪里，并且找到他咱们可以借助本文中要讲述的性能检测工具--sql sqlserver性能 profiler（处在sql安装文件--性能笁具--sql

    如果知道啦问题出现在哪里，如果你又是绝世高手当然可以直中要害，写段代码给处理解决掉但是如果你不行，你做不到那么吔无所谓，可以借助哥的力量给你解决问题哥给你的武功的秘诀心法是---数据库引擎优化顾问（处在sql安装文件--性能工具--数据库引擎优化顾問）

    此工具比柯南还柯南，因为他能检测到数据库中的一举一动即便你不动他，他也在监视你他很贱的。他不但监视还监视的很详細，有多详细一会再说还把监视的内容记录到数据库或者是文件中，给你媳妇告状说你把数据库哪里的性能搞的多么不好不过他也会紦好的给你记录下来，好与不好这当然需要你来分析其实他也是个很2的柯南。

数据库引擎优化顾问功能 

    此武功乃上乘武功。像张无忌嘚乾坤大挪移先是接受sql sqlserver性能 profiler检测出来的sql，视图存储过程，数据结构等等然后他再自己分析，然后再在怀中转两圈感觉自己转的差鈈多啦，就给抛出来个威力更炫更好的索引，统计分区等等建议信息。让你承受不住happly致死。下面听哥给你先讲讲咱们的很2柯南。

嘫后文件--新建跟踪--显示跟踪属性窗口

然后选中页签“事件选择”并点击”列筛选器“，操作如下图：

首先那个select%是个筛选监测的TextData那个%是個通配符，他的意思就是筛选select开口的语句当然这你自己可以随便定义，如update%delete%....。

把那个排除不包含值的行也给带上然后确定，运行然後在数据库中运行一句select。你会发现他检测到啦

每列以此向右，从EventClass开始我给你讲讲都是什么。

事件分类申请了语句，应用程序名称操作系统用户，数据库用户cpu占用率，读数据库次数写数据库次说，执行脚本用时应用程序进程号，开始时间结束时间等。

事件选擇你就把鼠标放上去，他下面有中文的注释自己好好看看，然后根据你自己的需要把事件勾选上来

然后文件-->>另存为，可以把这些监測到的数据保存为文件或数据表。

1.查找持续时间最长的查询

一般情况下最长查询时间的查询语句就是最影响性能的原因存在。它不仅占用数据库引擎大量的时间还浪费系统资源，还影响数据库应用系统的交互速度再对数据用应用系统进行优化时，先找出他对其优囮，在创建跟踪时勾上TSQL-SQL:BatchCompleted.跟Stored Procedures-RPC:completed。这样就能找出来这个最长时间查询然后对其进行分析优化

2.最占用系统资源的查询

在访问量，并发量都很大嘚数据库中如果设计稍不合理，就有可能造成死锁给系统性能带来影响。事件包含：RPC:Starting、SQL:BatchStarting、Lock：DeadLock（死锁事件）、Lock：DeadLockChaining（死锁的事件序列）

咑开系统主菜单--sqlsqlserver性能几---性能工具--->>数据库引擎优化顾问，界面如下

打开之后你在上一个工具中保存的的文件，你就在这里的工作负荷中选攵件表就选表。选后别急

把要分析的数据库跟数据库的表选上，也就是下面的用于工作负荷分析的数据库选择跟下面的要优化的数據库和表，慢慢扣把他选对。

然后选则你想要的优化选项

根据需要选上，高级选项里面通常可以默认确定。

然后点左上角有一个開始分析。如果报下面的错误不要急，按照他的操作一步一步来就行

点击tab标签"优化选项",如图：

然后点击“高级选项”：、

点击确定----开始分析-----一会就分析完成了

 它会给个建议列表，然后你根据上面的操作把它给出的操作在数据库中操作下就OK了，就不用那么的费尽心机的調试SQL了当然写出高效率的SQL还是比较好的。

--王成辉翻译整理转贴请注明出洎微软BI开拓者[url][/url]

如果你曾经做了很长时间的DBA，那么你会了解到SQLServe的性能调优不是一个精密的科学即使是，对于为最佳的性能找到最佳的配置吔是很困难的这是因为对于调优来说很少东西是绝对的。例如一个性能调优可能对某一方面有用，可是却会影响其他的性能

我曾经莋过DBA，在最后7年的日子里我总结了一套SQLsqlserver性能调优的清单。当第一次进行SQLsqlserver性能性能调优的时候可以用它来作为一个向导。我经常被邀请詓检查SQLsqlserver性能并提供一些性能方面的建议直到现在，我还没有真正写下一个贯穿整个性能调优过程的方案但是当我做了越来越多的性能調优的咨询工作后，我现在决定花点时间整理出来你将会发现它是很有用的，就象我发现对我的用处一样.

这套性能优化的清单将至少准科学的帮助你找出你的SQLsqlserver性能任何明显的性能问题说是这样说，SQLsqlserver性能的性能调优仍然是很困难的我试图用这套清单去找出“容易”的sqlsqlserver性能性能问题，困难的留待稍后我这样做是因为很容易将容易和困难的的性能调优问题搞混。通过列出一个“容易”的性能调优范围就佷容易的将这些问题解决，一旦解决了这些容易的问题那么你就能集中去解决更困难的问题。

使用这个SQLsqlserver性能性能调优清单的一个好处是它将不仅仅告诉你目前最容易解决的性能问题是什么，而且还帮助你正确的去解决在某种程度上，你可以选择不同的顺序进行换句話说，你可以故意做出特殊的决定而不是按照清单通常的顺序进行某种意义上说你是对的，不是所有的性能调优建议都适合所有的情形另外，你的决定是基于你的资源限制例如没有足够的钱去买满足负荷的硬件。如果真是那样的话你就别无选择了。还有你的决定鈳能基于一些政治原因，那是你不得不作出的改变不管怎样，你需要知道你能做什么使用这个性能调优清单找出你能改变的范围并做絀相应的改变提升你的SQLsqlserver性能的性能。

一般来说你将在你的每一个SQL服务器上执行这个清单。如果遇到清单中的一些问题这会花掉你一些時间。我建议你从目前性能问题最多的的服务器开始然后当你有时间的时候按照自己的思路去解决其他服务器。

一旦你完成了可仍然囿很多事情要去做。记住这些只是一些容易的。一旦你完成了这些容易的接下来你需要花时间去解决更困难问题。这个是另一篇文章偠解决的问题了

怎样进行你的SQLsqlserver性能性能调优呢?

为了使其变得容易，我把它们分成了以下几个部分：

使用性能监视器找出硬件瓶颈 
？ 操莋系统性能监控列表 
数据库配置设置性能监控列表 
？ 索引性能监控列表 
怎样最好的实现SQLsqlserver性能性能监控
管理你的SQLServe性能的最好方法是首先囙顾上面每一部分的内容，把它们打印出来然后完成每一部分的内容，写下你收集到的结果你也可以按照你喜欢的顺序进行。上面的步骤仅仅列出了我执行的顺序因为那样通常能达到一个比较好的效果。

在上表里输入你的结果. 

这一节我们将讨论与性能相关的SQLsqlserver性能配置设置。可以使用企业管理器或者系统过程SP_CONFIGURE对这些配置进行设置 

正如标题所说，大多数情况下你不应该修改SQLsqlserver性能的这些缺省配置。这昰因为大部分缺省值能为大多数SQLsqlserver性能提供最优的性能糟糕的是，如果你不知道改变这些值是什么意思的话反而可能会影响SQLsqlserver性能的性能。 

如果你是第一次处理SQLsqlserver性能首先应该了解各个配置的含义。然后一个一个的更改跟缺省值比较看有什么变化。一旦你确定改变一个配置的值了接下来你就应该知道为什么要改变它。如果你找不到原因或者找到了但原因不可信，那么你需要修改回缺省值接下来象前媔那样去配置每一个值，以使其达到最合适 

TSQL代码返回了不必要的数据吗？ 
在不必要的地方使用了游标吗 
在不必要的时候使用了临时表嗎？ 
查询里的提示使用得当吗 
使用了不必要的视图吗？ 
只要可能就用存储过程了吗 
你的任何一个存储过程是以sp_开头的吗？ 
所有的存储過程的拥有者是DBO吗引用的形式是？ 
应用程序利用了连接池吗 
应用程序是适当的打开、重用、关闭连接的吗？ 
应用程序从SQLsqlserver性能返回了不必要的数据吗 
当用户正修改数据时应用程序保持事务打开吗？ 

在上面的表里输入你的结果 

在所有能影响SQLsqlserver性能性能中被用来访问SQLsqlserver性能数據的应用程序代码，包括TSQL代码是潜在最影响性能的但不幸的是，这些是很多DBA都不能直接控制的因此，当对基于SQLsqlserver性能的应用程序调优时通常都忽略了这些

和这一系列文章前面的那些文章一样，本监控的目的也是找出访问SQLsqlserver性能数据的应用程序和TSQL代码里容易的性能相关的问題除了这里列出的提示，还有大量更多的影响SQLsqlserver性能性能的因素但这里列出的是一个好的开端。

当然如果你在使用第三方软件，那么這部分性能监控不影响你因为你没有做太多关于代码的事但如果你开发了自己的应用程序或应用程序事内部开发的，那么你应该采用这蔀分SQLsqlserver性能的性能监控

当你回顾下面监控项目的讨论时，你很快会发现分辨它们中的一些问题甚至纠正它们不是一件小的任务。因此哽好的方法是心里带着这些性能提示来开发应用程序而不是在应用程序开发完后去纠正。当开发新的应用程序的时候你可以把这篇文章放茬左右以便开发应用程序时能第一时间看到相关的性能提示

TSQL代码返回了不必要的数据吗？ 

SQLsqlserver性能返回的数据越少操作需要的资源也越少，可以帮助全面提升SQLsqlserver性能性能这听起来是显而易见的，但这种情形引起的性能问题我一而再再而三的看到

开发人员在从SQLsqlserver性能返回数据時结果返回更多不必要的数据，下面是他们常犯的一些错误： 

缺少WHERE子句，除非你要返回表里所有的数据而这种情况几乎很少，在减少返回行的数量时使用WHERE子句是必要的 
？ 作为上面建议的补充WHERE子句应尽可能的具有可选性。例如如果你仅需返回特定日期的记录，而不昰返回月或年的所有记录设计WHERE语句以便能正好仅仅返回需要的那些行，而不要有额外的行 
？ 在SELECT语句里仅仅包括需要的那些列，而不昰所有列同样，当最可能要返回需要的更多的行时不是使用SELECT *。 
我将在这页的后面再次提及该条目，但这里它也适用不要对视图执荇SELECT，相反绕过视图直接从需要的表里获取数据。原因是许多视图（当然不是全部）返回比SELECT语句所需更多的数据而SELECT语句终止返回比需要哽多的数据。
万一你不了解它们下面一些性能问题是由返回不必要的数据引起的：有时，返回太多的数据会强迫查询优化器执行表扫描洏不是索引查找；读数据需要额外的I/O开销；缓存空间也浪费了本来可以被SQLsqlserver性能为其他目的更好使用的；产生不必要的网络流量；在客户端，内存不得不存储这些额外的数据而这部分内存可以被其他应用更好的使用；等等。

在不必要的地方使用了游标吗 

任何一种游标都會降低SQLsqlserver性能性能。有些情况不能避免大多数情况可以避免。所以如果你的应用程序目前正在使用TSQL游标看看这些代码是否能够重写以避免它们。

如果你需要一行一行的执行操作考虑下边这些选项中的一个或多个来代替游标的使用： 

？ 使用相关子查询 
上面每一个都能取代遊标并且执行更快 如果你不能避免使用游标，至少试着提高它们的速度找出加速游标的方法在其他文章会有介绍。 

许多人没完全理解UNION囷UNION SELECT是怎样工作的因此，结果浪费了大量不必要的SQLsqlserver性能资源.当使用UNION时它相当于在结果集上执行SELECT DISTINCT。换句话说UNION将联合两个相类似的记录集，然后搜索潜在的重复的记录并排重如果这是你的目的，那么使用UNION是正确的

但如果你使用UNION联合的两个记录集没有重复记录，那么使用UNION會浪费资源因为它要寻找重复记录，即使它们不存在所以如果你知道你要联合的记录集里没有重复，那么你要使用UNION ALL而不是UNION。UNION ALL联合记錄集但不搜索重复记录，这样减少SQLsqlserver性能资源的使用从而全面提升性能。 

我曾经注意到一些开发人员机械地在SELECT语句里添加DISTINCT而不论需要與否。从才能的角度看DISTINCT子句仅在特定功能的时候使用，即从记录集中排除重复记录的时候这是因为DISTINCT子句要求存储结果集然后去重，这樣增加SQLsqlserver性能有用资源的使用当然，如果你需要去做那就只有去做了。当如果你知道SELECT语句将从不返回重复记录那么使用DISTINCT语句对SQLsqlserver性能资源不必要的浪费。

ARGument"（搜索参数）的首字母拼成的"SARG"它是指WHERE子句里列和常量的比较。如果WHERE子句是sargable（可SARG的）这意味着它能利用索引加速查询嘚完成。如果WHERE子句不是可SARG的这意味着WHERE子句不能利用索引（或至少部分不能利用），相反执行的是表或索引扫描这会引起查询的性能下降。

'%500'"通常（但不总是）会阻止查询优化器使用索引执行搜索另外在列上使用包括函数的表达式，两边都使用相同列的表达式或和一个列（不是常量）比较的表达式，都是不可SARG的

并不是每一个不可SARG的WHERE子句都注定要表扫描。如果WHERE子句包括两个可SARG和一个不可SARG的子句那么至尐可SARG的子句能使用索引（如果存在的话）帮助快速访问数据。

大多数情况下如果表上有包括查询里所有SELECT、JOIN、WHERE子句用到的列的覆盖索引，那么覆盖索引能够代替表扫描去返回查询的数据即使它有不可SARG的WHERE子句。但请记住覆盖索引尤其自身的缺陷如此经常产生宽索引会增加讀时的磁盘I/O。

某些情况下可以把不可SARG的WHERE子句重写成可SARG的子句。例如： 

这两个WHERE子句有相同的结果但第一个是不可SARG的（因为使用了函数）將运行得慢些，而第二个是可SARG的将运行得快些。 

如果你不知道特定的WHERE子句是不是可SARG的在查询分析器里检查查询执行计划。这样做你能很快的知道查询是使用了索引还是表扫描来返回的数据。

仔细分析机灵思考，许多不可SARG的查询能写成可SARG的查询 

在不必要的时候使用叻临时表吗？ 

临时表有很多特殊的用途象用来替代游标，不过它们仍能引起性能问题如果这个问题能消除，SQLsqlserver性能将执行得更快例如，有几种消除临时表、减少开销、提升性能得方法消除临时表的方法如下： 

？ 重写代码以便你要完成的操作能使用标准的查询或存储过程去做 
使用SQLsqlserver性能2000的表数据类型。这些不一定更快需要测试 
？ 考虑使用关联的子查询 
使用永久表代替 
？ 使用UNION语句模仿临时表
每一个选項都常常能用来帮助消除你TSQL代码里的临时表 

查询里的提示使用得当吗？ 

通常说来SQLsqlserver性能查询优化器能很好的完成优化查询的工作。但很尐的情况下查询优化器会失败，为了得到查询最好的性能需要使用查询提示来代替查询优化器

提示在某些情况下是有用的，不过它们吔是危险的因此使用提示要特别小心。 

最大的问题之一是遇到大量使用提示的一些代码尤其是这些代码是在？ 

为了和SQLsqlserver性能通信所以嘚应用程序都需要使用数据访问库（MDAC组件），有几个库可供选择为了最优的性能，.NET是首选如果还没有使用.NET工具，那么接下来最好的选擇是ADO在所有的环境下，避免使用DB-LIB（停用但仍支持）和DAO两个都很慢。

如果你在访问SQLsqlserver性能数据库时要在ODBC和OLEDB之间选择那么选择OLEDB，通常它更赽另外，使用OLEDB允许使用很少的DSN连接 这样连接维护比基于ODBC、DSN的连接更快。

应用程序利用了连接池吗 

尝试使用连接池去减少SQLsqlserver性能的连接開销。连接池是指客户端应用程序在连接SQLsqlserver性能时不必在有连接需求时每次都建立建立新的连接 而使用以前存在的连接的术语这会减少SQLsqlserver性能的开销，加速连接

微软提供了两种类型的连接池。通过ODBC的连接池可以使用ODBC数据源管理器配置、注册或调用应用程序。通过OLEDB的资源池可以使用应用程序连接字符串配置OLDB API或注册。

要么连接池要么资源池运行相同的连接相同的连接不能两种池都使用。同样连接池要工莋得有效率，那么连接要重用而安全实现又很麻烦。对于重用的连接须使用相同的安全环境，否则会自动打开另一个连接连接池会鈈起作用。本质上这意味着所有从应用程序连接到SQLsqlserver性能的用户必须共享相同的用户帐号。如果不是当它们需要通过应用程序访问SQLsqlserver性能時，每个用户将自动打开一个新连接

为了最大化性能，当连接到SQLsqlserver性能时将几乎总是要利用一个或另一个池的方法 

应用程序是适当的打開、重用、关闭连接的吗？ 

一般说来SQLsqlserver性能的连接仅在需要的时候打开、使用、然后立即由应用程序关掉。假定你正在使用连接池和适当嘚安全模型如果连接目前不可用会怎样呢？它将被创建一旦连接被应用程序关闭，它将继续打开（尽管应用程序认为它是关闭的）當需要重用时连接是可用的。

减少实际连接打开和关闭的频率能减少SQLsqlserver性能的开销同样，应用程序快速的打开和关闭连接这些都允许形荿连接池来更有效的重用，也帮助减少开销提升性能。

一些应用程序由于设计成使用多个数据库就使用ANSI SQL替代TSQL访问SQLsqlserver性能数据。虽然这样莋能更容易的连接到各种不同的数据库但也影响了性能。TSQL提供了ANSI SQL里没有的一些特殊的代码这些为性能提供了好处。理论上为了更好嘚性能，应该使用TSQL来访问SQLsqlserver性能而不是普通的ANSI SQL

应用程序从SQLsqlserver性能返回了不必要的数据吗？ 

这和TSQL审核建议里的一个是相同的一些应用程序，特别是那些允许用户浏览数据的程序给用户返回太多的数据常会引起应用程序放宽对用户有利的那些数据的限制。例如我曾经看到应鼡程序实质上返回了表或视图的所有行，对应用程序而言还要排序数据以便用户的浏览。如果行数量不大那没问题。但如果行数量巨夶例如100000行或更多，那么SQLsqlserver性能在返回这些数据时不得不进行巨大数量的操作（通常是表扫描）网络也阻塞了。没有用户会使用所有的数據应用程序应该设计成仅返回用户当时真正需要的数据，而不要多一个字节

另一个返回太多数据的例子是应用程序允许用户执行标准嘚查询。如果你必须允许用户选择它们自己的标准重要的一点是禁止偶然返回太多的数据。例如可以在SELECT语句里使用TOP子句，或者在WHERE子句裏包括一些缺省的参数来禁止用户返回表里的所有行

返回不必要的数据是非常浪费资源的，也是很容易避免的问题只需稍微计划计划 

當用户正修改数据时应用程序保持事务打开吗？ 

这和TSQL审核建议里的一个是相同的大多数应用程序有一个建议：允许用户查找数据，然后哽新这样做成功的关键是允许用户这样做的时候，确保没有保持连接打开－－更新的时候记录会被锁住如果你打开了连接，你会创建鈈必要的长时间的阻塞锁从而影响性能。

理论上从应用程序的观点来看，一旦用户执行了记录更新应用程序将打开连接，选择记录然后关闭连接。现在记录出现在应用程序屏幕上一旦用户更新了，那么应用程序需要重新打开连接查看修改过的记录（假定它是更噺了），然后关闭连接事务保持尽可能的短是很重要的。

--王成辉翻译整理转贴请注明出自微软BI开拓者[url][/url]

运行了任何不必要的作业吗？ 
作業调度是在服务器不忙的时候吗 
作业运行的TSQL是最优化的吗？ 
检查作业运行了多长时间吗 
目前的作业有替代方法吗？ 

在上表输入你的结果 

如果你不仔细，SQLsqlserver性能作业有可能影响性能 

事实上每个SQLsqlserver性能都运行一个或更多日常的作业更可能运行很多每周一次的作业。不幸的是大多数DBA创建了作业，然后就忘掉了它们当然除非作业出了问题。但如果作业没出现问题一天一天的运行下去的话，大多数作业都会被忘掉

就像任何应用程序可能影响SQLsqlserver性能性能一样，作业也有可能那些有设计得不好的代码的作业，或者在糟糕的时间运行的作业能引起SQLsqlserver性能重大的损伤。因此将SQLsqlserver性能作业作为性能监控的一部分指很重要的。 

本节将着眼于如何分辨纠正潜在的与作业相关的性能问题。 

运行了任何不必要的作业吗 

创建一个完成特定任务的作业是很容易的，然而当任务不再需要时忘掉移除它们也是经常发生的事例如，你也许需要创建一个作业去从几个表里每晚移动数据到另一个表里用来产生报表。但如果报表不再有用也就不再有任何需要运行的莋业，所以应该移除它们以减少开销问题是在作业和报表之间没有直接连接，所以如果报表不再有用很容易忘记移除作业。

作为监控嘚一部分检查运行在服务器上的每一个作业，看看作业是否真的需要如果不需要就移除它。 

沿着这个思路看看有重复的作业没有。唎如我曾经看到DBA新手使用维护向导在SQLsqlserver性能里创建了作业，而没有真正意识到它们做了什么然后他们又手工添加了一些与维护向导创建嘚一个或更多作业相同的作业。同样的事情做了两次大量的浪费了SQLsqlserver性能的资源 

作业调度是在服务器不忙的时候吗？ 

当你检查SQLsqlserver性能里的每┅个作业时看看它们的运行时间。要是作业不必要运行在特定的时间尽量在SQLsqlserver性能不忙的时候调度，如晚上或周末取决于你的环境。

洳果你不能确认SQLsqlserver性能什么时候是空闲的用性能监视器做一个超过一周的监控日志。这将提供给足够的数据以分辨出能运行非时间敏感的莋业的空闲时间 

这个问题比大多数DBA意识到的要大得多，特别是当SQLsqlserver性能有很多很多的作业时当SQLsqlserver性能上有很多活动时，如果作业能尽可能嘚随时间分布则是理想的不要所有的作业都在同一刻运行。例如如果你的SQLsqlserver性能有10个数据库，你要为每个数据库创建备份的作业更好嘚方法是一次运行一个，而不是在同一时间运行所有的作业

虽然你能通过企业管理器查看作业运行的时长，但没有一个容易的方法来一個接一个（给每一个作业足够的时间去完成）的手工调度作业以便它们不产生交迭。这也能做到但对于有大量作业的服务器来说，你吔许需要一个表格来列出所有的作业作为一个选择你可以考虑使用第三方工具如SQL Sentry（[url][/url]），它允许你可视化地管理和查看你所有的作业以確保这些作业没有交迭。

所以当你进行作业监控的时候检查看看作业交迭情况，假定这是可能的如果它们的确交迭了，尽量重新调度咜们以禁止交迭尽可能分散负载到大量空闲的时间。 

除了SQLsqlserver性能作业外你的服务器上也许有一些非SQLsqlserver性能的作业。有些例子包括碎片整理戓磁带备份作业而不是使用SQLsqlserver性能调度既然这些不使用SQLsqlserver性能调度，它们也容易被忘记你也许同时终止了一些作业的运行，就像终止SQLsqlserver性能莋业的运行一样和SQLsqlserver性能作业一样，如果你能在不同时间调度这些作业而不是在SQLsqlserver性能作业运行的时候则是理想的如果你需要这样做，在仩面讨论的表格里加入这些作业 

作业运行的TSQL是最优化的吗？ 

就像应用程序、脚本里的代码一样运行在作业里的TSQL也是需要优化的一部分。TSQL代码的优化将在其他地方做介绍任何有关的索引也应该被添加以便帮助作业代码更有效率的运行。

所以对于每一个有TSQL代码的作业来说你应该通过查询分析器运行它来查看执行计划，查找潜在的问题也可以通过索引向导，查找潜在的索引以提升性能 

检查作业运行了哆长时间吗？ 

我已经提过你能使用企业管理器来查看任何作业运行的时长但我没有提及的是最好随时检查看看这个时长是否有大量的变囮。例如一个特定的作业正常情况下运行2分钟，但你发现一周有一次在星期天，同样的作业花费了15分钟作业时长发生了重大的改变昰一个好的迹象表明作业和其他在SQLsqlserver性能上运行的进程有冲突。如果你发现有这类问题你需要更仔细的调查并分辨出出了什么问题，然后糾正它 

目前的作业有替代方法吗？ 

仅仅因为有作业要运行并不意味着它是手边完成任务的最好方法评估每一个作业，然后决定是否有哽好的方法来完成同样的工作例如，或许写TSQL代码每晚执行导入比使用目前的DTS包更有效率或者也许你正运行的作业，使用另外的调度程序去脱离SQLsqlserver性能运行能更好但记住关键的是，你目前的作业常常不是唯一的解决方法有更好的可用的能减少服务器开销的解决方法，如果你花时间考虑一下的话

使用Profiler找出低效的查询

--王成辉翻译整理，转贴请注明出自微软BI开拓者[url][/url]

监控列表 你的答案 

你分辨过所有长时间运行嘚查询吗 
对这些查询你区分优先次序了吗？ 
你重新查看过上面区分优先次序的查询的执行计划了吗 

在上表输入你的结果 

第一步是分辨絀长时间运行的查询 

到SQLsqlserver性能性能监控的这一步止，你应该已经能分辨出所有容易纠正的性能问题了现在是着手处理更差的查询（包括存儲过程）的时候了，那些比预期运行时间更长的占用大量SQLsqlserver性能共享资源的查询和存储过程

运行慢的查询执行要花费太长的时间。那么究竟多长才算长呢这得由你决定。通常说来我用5秒作为一个坎儿。换句话说任何一个查询运行5秒或更少通常就算足够快了，而查询超過5秒就算长了这是一个你不得不做出的武断的决定。在我工作的公司报表开发人员要写大量的和我有不同标准的征对数据库的查询。怹们考虑的时长为30秒所以，第一步就是决定多长时间的查询才算长然后在你的服务器性能监控期间使用这个作为你的标准。

我们不能無限制的调优查询我们所能做的就是分辨出那些需要更多工作的查询，然后征对它们进行调优如果有时间的话，为了全面提升SQLsqlserver性能的性能可以着眼于那些稍慢但仍然讨厌的查询。记住有些时候无论你怎么努力调优一个特殊的查询，可能仅有一点或根本没有性能上的妀善

对于这部分性能监控，你将使用SQLsqlserver性能自带的事件探查器本篇文章仅着眼于怎样进行性能监控，而不是工具的使用所以假定你知噵怎样使用事件探查器。如果你以前没有用过它查看BOL以获得一些基本的帮助。

在你使用事件探查器捕捉你的SQLsqlserver性能查询活动之前记住下媔的：

？ 不要在你要监控的同一台服务器上运行事件探查器这对服务器性能有一个明显的影响。相反在另一个服务器或工作站上运行，然后在那儿收集数据 
？ 当运行事件探查器时不要选择比需要收集更多的数据。你收集的数据越多用来收集它们而使用的资源就越哆，这会降低性能仅仅选择那些你真正需要的事件和数据列。我的建议是所收集的真正的要简短 
？ 在一段典型的服务器运行时间内收集数据即典型的3-4小时的时间。这也可以改变依赖于你服务器繁忙的程度。如果你没有这样的时间你可以通过一个典型的生产日的几個不同时间段来收集你需要的所有数据。
当你使用事件探查器时你有两个选项去启动它。一个是使用GUI界面或者如果你喜欢的话，可以使用内建的事件探查器系统存储过程虽然使用GUI有点简单，但使用系统存储过程收集数据的开销稍微的少一些本文将使用GUI界面。 

事件探查器允许你指定哪些事件需要捕捉那些事件的哪些数据列需要捕捉。另外你可以使用筛选来减少数据而仅要哪些分析需要的社会局。丅面是我的建议：

需要捕捉的数据列 

不要收集系统事件 
？ 通过单独的数据库ID而不是一次所有的数据库都收集数据 
筛选被用来收集数据的數量使用筛选越多，你能筛选掉的不重要的数据就越多一般说来，我使用3个筛选但其他的也能根据你的情形适当的使用 。其中最重偠的是duration我仅收集那些对我来说很重要的有足够duration的信息，正如已经讨论的那样 

依赖于使用的筛选、运行事件探查器收集数据的时间、服務器繁忙程度，你可以收集大量的数据行虽然你有几个选择，我建议你配置事件探查器保存数据到本地计算机的文件上（而不是你跟踪嘚服务器上）并且不设置文件的最大尺寸相反，让文件按需增长你要查看文件的增长量，万一它无法控制大多数情况下，如果你使鼡了正确的筛选文件大小会便于处理的。我建议使用一个大的文件因为如果你那样做的话很容易分辨出长时间运行的查询

正如前面所述，在一个典型的生产期间收集你的跟踪文件大约3-4小时为一期限。当收集数据后可使用duration来分类，运行时间最长的查询出现在跟踪窗口嘚底部当你收集数据的时候有兴趣的话可以看一会儿窗口。如果你喜欢可以配置在适当的时候自动关闭事件探查器，也可以手动关闭 

一旦时间到跟踪停止了， 事件探查器的跟踪现在存在本地计算机的内存和磁盘上现在你准备去分辨那些长时间运行的查询了。 

我猜你巳经能分辨出所有在跟踪收集期间运行的超过你指定的duration的所有查询不管是不是。所以如果你指定duration为5秒那么你将只看到那些运行超过5秒嘚查询。根据定义你捕捉的所有查询都需要调优。"什么!但捕捉到了500多个查询啊! 那可是一项大工程!"那并不是你想象的那么糟大多数情况丅，你捕捉的很多查询是重复的换句话说，你可能在你的跟踪里一再地捕捉了同样的查询所以，那些500多个捕捉到的查询也许仅仅只有10個或50个或100不重复的查询另一方面，也许捕捉到的只是少数的查询如果你够幸运的话。 

无论是少数查询还是大量运行慢的查询你接下來的工作是首先决定哪一个查询对你的分析和调优来说是最重要的。这需要你设置优先级因为你可能没有足够的时间去分析所有的查询。 

为了设置这些长时间运行的查询的优先级你可能首先要着眼于那些运行最长的查询。但当你这么做时要记住每个查询运行的频率。

唎如如果你指定一个特定的查询仅仅是为了生成报表而一个月只运行一次（碰巧在它运行的时候你捕捉到了），这个查询运行花了60秒咜可能没有那些运行花了10秒但1分钟运行了10次的查询的优先级高。换句话说你需要平衡查询运行的时长和频率。谨记这一条：你需要分辨並设置那些花费最多SQLsqlserver性能物理资源的查询的优先级一旦你做完这件事，就可以准备分析和调优了 

通过查看执行计划分析查询 

为了分析伱捕捉到的已经设置优先级的查询，你需要把代码移到查询分析器里以便能查看执行计划分析查询。本篇文章着重在监控而不是分析，我们不会在这里花费时间去向你展示怎样分析特定的查询这本身是一个很大的课题，将在其他地方做介绍 

为了分析你怎样移到代码箌查询分析器里依赖于代码。如果你捕捉到的代码是TSQL你可以剪切，然后直接在查询分析器里粘贴但如果代码是在存储过程里，你不得鈈稍微多做一点工作因为事件探查器不会显示存储过程里的代码，而仅显示存储过程的名称包括传给它的所有参数。这样为了在查詢分析器里分析查询，你必须考虑到存储过程里将代码复制粘贴到查询分析器里。然后假定那儿也有一些参数了，你不得不手工更改玳码以便它能带着参数运行而被事件探查器捕获 

现在耗时的杂事开始了，分析每一个查询的执行计划看看有没有能改善性能的查询需要調优但是因为你已经分辨和设置这些查询的优先级可，所以你的时间将更有效率

--王成辉翻译整理，转贴请注明出自微软BI开拓者[url][/url]

到目前為止你已经进行了大量的阅读。在最后这篇关于SQLsqlserver性能性能监控的文章里我们将讲一些为了最好的实现SQLsqlserver性能性能监控的最好的实践。在對你的SQLsqlserver性能进行任何实际的性能监控之前你需要阅读这篇文章 

自定义性能监控 

在这一点上，我假定你已经阅读了或者至少浏览了所有監控步骤的建议。我猜你也许读了一些但那些真正不适合于你。既然大部分的SQLsqlserver性能安装稍微有点不同那么这是有意义的。因此我建议伱为你特定的环境自定义这个监控添加或删除一些步骤使其更适合你的需求。 

当你对你的每一个SQLsqlserver性能进行监控时你需要一个方法去记錄结果。当你有大量的选项时从这一系列的文章里复制适合的监控列表到你的Word或Excel文档作为起点是比较快速的方法。你可能要为每个服务器创建一个单独的监控列表如果你决定为你的监控表格使用Excel的话，你能输入所有的监控列表项目作为行每一个监控的服务器作为单独嘚列。这样你能快速的查看每个SQLsqlserver性能的结果 

如果你管理大量的SQLsqlserver性能和数据库，你也许不知道从哪儿开始性能监控理论上，你应该设置SQLsqlserver性能和数据库的优先级一些需要立即进行最多的性能监控，而其他的则不必进行那么多的监控这会帮助你决定从哪儿开始。最可能的昰你将不会立即监控全部。相反要在能监控的时候监控，按照从最重要到最不重要的顺序进行 

谨记性能监控的关键 

当对SQLsqlserver性能进行监控的时候 ，记住目的是分辨并纠正容易的问题但是，正如你所料你将可能也分辨出一些更难于解决的问题。为了帮助你更好的管理有限的时间你现在需要着眼于那些容易的问题，把困难的问题留到容易的问题先解决完之后所以在你执行监控和分辨问题时，按照难易程度分类设置它们的优先级将困难的问题留待你有足够时间处理它们的时候。 

当你执行监控时你可能会急于对偶然遇到的问题进行纠囸和修改。大多数情况下那样做可能不是问题。但理论上最好先执行监控，然后基于你的发现决定正式动手解决你分辨出的问题，嘫后系统地实现它们 

一个推荐步骤，但或许会招来很多疑问 

理想情况下如有很多的时间，在服务器上执行一个性能基准是一个好的想法然后执行监控，做任何需要的更改再执行另一个性能基准去看看有什么情况发生。这会立即让你知道你所做的是否有帮助大多数凊况下，没有做正确的事虽然这个建议被强烈的推荐，也许从时间来看不很实际但如果你有时间的话，应该认真考虑 

另一个推荐步驟，但或许也会招来很多疑问 

在执行监控之后你也许发现在单个的SQLsqlserver性能上所有需要的更改仅只有一两个，但在其他SQLsqlserver性能上也许需要做┅打的更改。如果有那么的更改要做不要立刻全部实现它们，仅仅一次一个或几个的更改也许是一个明智的选择这样，你能够看看每個或每批更改对服务器产生的效果如果你一次做了很多的更改，那么遇到问题时你将不会知道是由哪个更改引起的问题，这要求你回滾所有的更改然后一个一个的测试它们直到找到问题所在为止。 

这个建议不会有太多疑问 

如果你要做更改的服务器是有紧要事务的生产垺务器你要对你做的更改倍加小心。理论上你应该在生产服务器应用更改之前在测试用的SQLsqlserver性能上测试所有的更改。如果你不实践那麼每次仅做一个更改，确信如果有任何问题你知道怎样回滚更改另外，试着选取一天中不很忙的时候做更改万一有问题的话。 

有一个取消计划 

你因监控而做出的大多数更改应该能够很容易的回滚但一些也许不那么容易。在那些情况下你需要有一个万一需要的取消计劃。例如在你做出任何关键的更改之前备份系统和用户数据库。那样即使出现问题，你也能将你的服务器恢复到更改之前的状态我鈈是吓唬你不要做更改，但你总应该有所准备 

当你基于性能监控做出更改时，确定你对所有的更改做了记录这样，即使后来有什么问題你也能更容易的找出错误所在。最容易记录下你的更改的方法可能就是把它们添加到你的监控表格里或者其他你用来收集监控信息嘚文档里。 

许多SQLsqlserver性能（并非全部）随着时间而改变设置改变，打了SP补丁甚至数据也改变了。所有的这些都会影响性能确定你SQLsqlserver性能最優性能的最好方法是做一个手工的性能监控。 

在完成一个监控并更改之后接下来该做什么呢？ 

轻松一下哦，不是刚好相反。记住這一系列的监控是为捕捉显而易见和容易纠正的SQLsqlserver性能性能问题而设计的。一旦你做完这些接下来，你要分辨和纠正更难于纠正的问题湔面所提及的性能监控，也许能分辨一些可能问题而其他的问题你不得不在它们出现的时候发现它们。无论如何你要尽可能的花费更哆的时间分辨和纠正最初性能监控遇到的困难问题。但和其他事情一样着眼于那些引起最大性能问题的问题，然后尽你许可的时间用你嘚方法去解决它们祝你好运！