原文： How to Take Advantage of SQL Server 2000 Performance Tuning Tools
来源： SQL-Server-Performance.com
SQL Server 2000 includes several tools you may find useful when performance tuning your SQL Server applications. The include:
* Query Analyzer
* Profiler
* Index Wizard
* System (Performance) Monitor
......
如何使用 SQL Server 2000 性能调试工具 SQL Server 2000 的性能调试的工具包括：
* 查询分析器 (Query Analyzer )
* 事件探查器 (Profiler )
* 索引优化向导 (Index Wizard )
* 性能监视器 (System Performance Monitor )
下面我们就介绍如何利用这些工具来帮助优化我们的 SQL Server 端应用。
SQL Server 2000 查询分析器 (Query Analyzer )
SQL Server 2000 查询分析器不仅是一个开发和调试 Transact-SQL 代码的好工具，而且也是一个很不错的性能调试工具。本节我们就介绍查询分析器的功能，以及一些利用查询分析器来分析和解决性能问题的常用 方法。象很多 SQL Server 2000 的高级工具一样，你需要对 Transact-SQL 有一定的理解才能发挥这些工具的强大作用。下面我们来看一下查询分析器的几个用于性能调试的主要特性。
显示执行计划 (Show Execute Plan)
在查询分析器中输入查询语句后，通过运行就可以立刻得到结果。你可以通过它的显示来检查结果 是否正确，而且查询分析器还会告诉你运行的时间长度。但是这些信息对于性能调试来说，实在太少了。
在查询分析器中有一个强大的功能，叫做显示执行计划。这个选项能让显示 SQL Server 优化器在实际运行查询语句时候的情况。这个选项在查询管理器的查询菜单下，在运行查询的时候一定要先选取。当查询运行的时候，位于屏幕底部的查询结果窗口上会添加一个显示这个执行计划结果窗口的新标签。在这个标签下， 会以图形化的方式显示执行计划的信息。
执行计划的显示信息随着查询的复杂度而变化，如果查询很简单，信息就简单；如果查询很复杂，信息就复杂。执行计划会一步一步告诉你，查询优化器是如何执行该查询的。由于执行计划显示的信息最右边表示查询分析器首先执行的步骤，最左边表示最后执行的步骤，所以阅读的顺序应该是从右至左。
图形化显示的结果十分有趣，不过最有用和最强大的部分并不会直接显示出来。当你把鼠标移动到查询计划的 每一步上时，会显示一个显示详细信息的弹出窗口，这里面就包括了查询优化器在执行查询时的所有信息。
这些信息的含义有些是明确的，例如告诉你这是 “ 聚集索引扫描 ” ；但有些就不那么明确，例如 “ 子树消耗 ” 是 .0376 。 我们可以通过查找 SQL Server 的在线帮助来解释这些信息，但是还有一些信息是需要 SQL Server 性能调试的经验， 这已经超出了本文讨论的范围。
如果你的查询耗时比较多，而你又想知道查询的具体执行情况，你不必要每次都运行查询语句。查询分析器 有一个不实际运行语句而生成和显示查询计划的选项。这个选项在 “ 查询 ” － >“ 显示估计的查询计划 ” 菜单下。
当该选项选中时，查询优化器会创建和显示执行计划而并不真正运行。需要注意的是这只是一个估计的结果，因此也许会和实际执行的结果有所不同。但是它和实际运行的结果和接近，因此如果你的查询耗时较多时，这将是一个很有价值的工具。当你根据估计的结果做了查询优化后，就可以关掉这个选项。实际的运行一下， 看看确定的运行效率如何了。
显示服务器跟踪 (Show Server Trace)
显示服务器跟踪用于调试查询，存储过程和 T-SQL 脚本的性能。它显示查询管理器 ( 作为 SQL Server 客户端应用 ) 和 SQL Server 之间的通讯信息。显示的信息和在 SQL Server 2000 事件探查器中截取的一样，关于 SQL Server 2000 事件探查器我们后面 会谈到。这两者之间的主要差别是显示服务器跟踪仅仅显示在查询管理器中发送的查询和脚本有关的信息。
显示服务器跟踪选项在查询管理器的“查询”菜单下，使用方法是在查询执行前要选中该选项。当查询执行的时候，结果显示在一个新的标签窗口中。
结果以表单形式显示，每一行表示查询管理器和SQL Server之间的一个通讯，内容包括通讯的文本，例如T-SQL代码，表示通讯类型的事件类，通讯的持续时间，CPU时间消耗数，以及读取和写入的数量。这些信息对分析查询性能十分有用，例如我们可以通过比较两个完成相同功能的不同查询来比较哪个较优。
显示客户统计 (Show Client Statistics)
和显示服务器跟踪一样，显示客户统计对查询，存储过程和脚本的性能调试也很有用。无论你在查询管理器中执行什么查询，它都会提供应用程序，网络和时间的统计信息。
显示客户统计在查询管理器的“查询”菜单下，运行查询前选择该选项就行了。当查询执行时，结果显示在屏幕底部的新标签窗口中，以表格显示显示一些统计信息，例如：
* INSERT, UPDATE 和 DELETE 语句影响的数据行数
* SELECT 语句影响的数据行数
* 用户事件数
* 服务器往返次数
* 发送的字节数
* 客户端处理的累积时间
这些统计信息可以作为帮你分析性能相关问题的指导性信息。
管理索引 (Manage Indexes)
管理索引工具并不是帮你分析性能问题的工具，不过它使你可以方便的管理索引，以方便你利用上述的工具来调试性能。该选项在“工具”菜单下，你可以利用它来方便地添加，编辑和删除任何表上的索引。这样你就可以在同一个界面下来测试索引性能。
管理统计 (Manage Statistics)
SQL Server自动创建和维护数据表每行的内部统计信息，而不需要你手工去做。这些统计信息供查询优化器去选择较优的T-SQL执行计划。大多数情况下，SQL Server会很好地维护这些统计信息，查询优化器也因为这些充足的信息从而可以去完成优化。
但是有时候，SQL Server创建和维护的统计信息并非最优，而这正是管理统计工具所能弥补的。该工具在查询管理器的“工具” 菜单下，利用该工具可以设置SQL Server如何自动创建和维护统计信息的方式。我们可以添加，编辑和删除SQL Server维护的各种统计信息。因此你可以在查询管理器中配置管理统计工具，根据设置后的统计信息来观察查询优化器是如何受其影响的。
除非你是一个有丰富经验的SQL Server数据库管理员或者开发者，否则我不建议你使用该工具。选择统计属性是一件很复杂的任务，因此也许你花时间在别的性能优化工作上会更值得。
索引优化向导 (Index Tuning Wizard (for Individual Queries))
文章后面我们会介绍索引优化向导工具，该工具通常用于优化整个数据库的索引。不过现在在本节我们要知道，索引优化向导工具在查询管理器中也能找到，主要用于优化特定查询的索引。
例如，当你在评估一个特定查询的性能时，你无法确定查询中使用到的数据表上的索引是否在该查询中起作用，此时索引优化向导( 在查询管理器的“查询”菜单下 )就能满足该需求。索引优化向导评估查询，然后如果可能，会建议添加新索引以实现优化。这的确是一个有用的工具，不过同时也会带来一些危险。因为索引优化向导提出的建议是基于当前特定的查询的，并不考虑别的查询下的效果，或者在添加新索引后对INSERT，UPDATE或者DELETE数据表所带来的影响。
在很多时候，更好的办法是在整个数据库上使用索引优化向导，而不是仅仅针对单个查询。这样，它就能提供更有利于性能平衡的建议。
好好掌握查询管理器
SQL Server 2000查询管理器是一个拥有大量功能特性的强大工具，上面只是简要介绍查询管理器在优化T-SQL代码性能上的工具。因此需要我们自己花更多时间去研究查询管理器的使用。
SQL Server 2000事件探查器 (SQL Server 2000 Profiler)
SQL Server 2000 事件探查器能帮助我们排查SQL Server性能问题。不过，该工具对初学者来说可能不太容易使用。它捕获应用程序和SQL Server之间通讯信息。获取这些数据并不困难，难的是对于新手来说如何解释这些数据。
本节我们介绍事件探查器到底能做什么，并初步学习它是如何帮助我们确定和解决性能问题的。
事件探查器特性
SQL Server 2000事件探查器捕获SQL Server和应用程序之间的任何通讯信息。这些通讯信息以事件类分组的形式显示。每个事件类包括一个或多个特定的事件。例如，和执行计划和显示计划统计一样，事件类“性能”有八个事件。事件探查器提供了13种不同的事件类供选择。
每个事件包含了三个属性列。例如，NTUserName或ApplicationName属性。
在应用中，每秒钟激发的成千上万的事件会让你无法对其进行分析。为了让分析更容易，事件探查器可以删选你感兴趣的事件。例如，你可以选择只捕获特定用户和SQL Server，或者特定应用程序和SQL Server，或者特定数据库的读写事件。你还可以选择什么类型的事件，或者每个事件的哪些数据列。这些选择可以减少捕获的事件信息。因此用好事件探查器的关键就在于你要知道哪些事件或者哪些数据列是对你分析性能有帮助的，而哪些是没有用处的。
没了更容易使用，事件探查器可以创建跟踪模板。当你利用事件探查器进行一次性能分析后，可以保存成跟踪模板以便于下次重复利用，而不必每次都重新配置。
当你创建和保存了跟踪模板后，你可以在任何时候运行跟踪。跟踪的结果 (即你捕获的事件) 可以查看和删除，或者保存成文件形式或者SQL Server表形式。你需要手工保存这些信息以便于以后检查。
跟踪执行时，结果直接显示在事件探查器中。你可以一行一行地看到你要跟踪的事件和数据列。很多情况下，事件内会包含T-SQL代码，你可以直接剪切，粘贴到查询管理器中直接执行，以便于获取更详细的分析结果。
如果你对事件和数据列不熟悉的话，第一次创建跟踪会比较困难一点。不过最简单的方法是利用事件探查器的创建跟踪向导。这个工具包含多个基础模板，你可以自定义这些模板以满足自己的需求。例如，“查找最差的性能查询”模板可以帮你确定那些超出预想时间的查询事件，比如运行时间超过1秒。你可以浏览所有这些基础模板。
如何使用事件探查器进行性能调试
正如上面介绍的，事件探查器是一个确定和解决性能问题的强大工具，且经常在开发过程中会使用到。我认为事件探查器最有用的功能是可以发现应用系统中的性能疑难问题。我强烈建议在设计阶段就进行性能调试，但是这并不总是能做到。
例如，你接手了一个内部系统，或者你们公司购买了一个使用SQL Server的后端应用系统。你被受命解决应用方面的性能问题。摆在你面前第一道难关就是你并不知道这些系统是如何工作的。你需要利用事件探查器去监视应用系统是如何和SQL Server 进行通讯的，即使这样做会很单调乏味。你首先可以捕获所有应用和数据库之间的通讯事件。然后，你可以运行某些特定事件，仔细检查应用和数据库的通讯以发现两者到底在干什么。
解释这些通讯事件往往需要对T-SQL有深刻的认识，不过如果你了解你在做什么后，你就会了解应用是如何对数据库进行操作的。当你不需要分析所有的通讯事件后，你就可以几种在那些可能造成性能问题的应用事件上，例如特殊的报表，更新处理等。
一般来说，当你创建对不佳操作的跟踪后，你可以检查T-SQL代码，以确定问题所在。例如，我曾经对某个内部应用进行分析后，发现连接SQL Server数据的VB代码产生了游标，这个游标每次仅仅移动一行数据到应用系统。问题在于每次要发送到应用系统数百万行数据，而这个游标会大大降低执行速度。一旦我确定问题出在哪里后，我就可以对VB代码进行重写以便解决问题。
事件探查器的另一个特性是你可以创建应用行为，然后利用跟踪的信息，来运行索引优化向导。然后，索引优化向导分析该行为并提出聚集/非聚集索引应该添加/删除的建议，以便提升数据库性能。在下一节我将介绍更多的关于索引优化向导的知识。
正如我介绍的，事件探查器是每个SQL Server管理员和开发者都应该掌握和学习的强大工具。
索引优化向导 (Index Wizard)
SQL Server 2000 索引优化向导是一个你会马上喜欢上的工具。虽然并不完美，但是这个工具可以评估查询运行性能，并基于查询，提出数据表上是否该添加聚集/非聚集索引的建议。索引优化向导在SQL Server 2000 事件探查器的“工具”菜单下可以找到。
该工具可以在从开发初级阶段到最后产品使用阶段都使用。实际上，你应该在每次应用系统运行一段时间后，就运行一下索引优化向导。因为随着应用的运行，数据库也在不停变化，而最佳的索引取决于数据库是如何被使用的。
虽然索引优化向导是一个很不错的工具，但是你不应该将对数据库索引的优化完全依赖于它。虽然它很智能，但是无论如何是无法和有经验的数据库管理员手工进行索引优化工作相比的。索引优化向导最好的一个特性是它的优化是基于实际运行中真实的数据通讯基础上，而不是用模拟的方式。这也再次说明它提出的索引优化建议是取决于数据库到底是如何被使用的。
使用索引优化向导前，首先要创建工作负载。工作负载表示一个事件跟踪或者T-SQL脚本。在很多情况下，你应该选择使用事件跟踪，因为它反应了真实的数据库行为。
如果你希望索引优化向导产生有用的结果，工作负载的创建必须能体现一段时间内每天数据库使用的情况。这样，索引优化向导就可以基于这些实际运行的统计行为来提出有用的建议。
当工作负载创建后，索引优化向导就很跟踪它。索引优化向导所做的就是从工作负载中提取行为样本，然后利用查询优化器进行分析。
一旦索引优化向导分析完工作负载后(如果工作负载很大，这会运行几个小时那么长)，基于对工作负载的分析，提出最佳的聚集/非聚集索引建议。另外，如果数据库上已经有索引了，并且索引优化向导发现这些索引不是最佳的，那么会建议你移除。
当提出建议后，你可以选择是否让索引优化向导进行索引操作 (不建议在交付运行的应用上使用)，这些操作可以是一个计划操作或者保存为脚本。建议保存为脚本，这样你可以仔细检查这些建议。当你认为建议无误后，再运行；而如果你认为有些建议并不好，也可以十分方便地修改脚本。
性能监视器 (System (Performance) Monitor)
性能监视器是Windows 2000的一个工具，而并非SQL Server 2000拥有的。性能监视器可以同时监视Windows 2000和SQL Server 的性能表现，同样是一个很好的性能分析工具。运行性能监视器需要你拥有Windows管理员级别的权限，而仅仅拥有 SQL Server系统管理员权限是无法运行的。
系统监视器能监视几百个Windows 2000性能指标 (称作计数器)，关于SQL Server 2000的计数器有110个，对SQL Server性能的监视足够了。
虽然性能监视器提供了充足的计数器供你选择，不过在大多数情况下，你也只需要监视几个就够了，只有在特殊情况下，才需要选择其它的计数器来进一步进行监视。也许你会认为对于用SQL Server，只需要选择那些SQL Server 2000的计数器就行了，其实不是这样。在很多情况下，Windows 2000的计数器倒是应该选择得更多一些。这是因为SQL Server的性能极大地依赖于Windows 2000的性能情况。
选择哪些计数器? 正如前面提到的，对于常规监视，只需要选择几个Windows 2000和SQL Server 2000的计数器就行了。下面列出一些常用的计数器。
要标识CPU内核性能，Windows 2000系统提供了一个系统对象计数器：% Total Processor Time，该计数器评估CPU的平均使用情况这个计数器用来监视CPU使用情况。如果在一段连续时间(10分钟左右)，数值超出80%，就说明系统产生了CPU瓶颈，你需要采取一些必要的措施，例如降低SQL Server的工作负载，更换更快的CPU或者更多的CPU。
要标识系统内存内核性能，需要使用内存对象计数器：Pages/Sec，该计数器每秒钟的页面文件数，包括从内存移动到硬盘，或者从硬盘载入到内存的这两类页面文件。如果SQL Server是服务器上唯一运行的应用服务，正常情况下，该计数器除了在某些跳跃点处外，都应该差不多是0。如果在一段连续时间(10分钟左右)内，该数值大于0，说明有页面文件相关的问题。造成该异常计数器数值，有可能是因为服务器上还有其它的应用服务在运行，或者你关闭了SQL Server的动态内存设置。
要标识I/O性能，物理磁盘对象计数器：Avg.Disk Queue Length应该被监视。如果该计数器数值在一段连续时间(10分钟左右)内，超过2，说明磁盘阵列有I/O瓶颈。解决该瓶颈的方法有：如果可能，增加硬盘；更换更快的硬盘；如果可能，增加高速缓冲存储器(Cache)；更换RAID的模式；更换更快的控制器；或者降低SQL Server的工作负载。
要标识物理内存性能，需要选择SQL Server 2000的缓冲管理对象计数器：Buffer Cache Hit Ratio。该计数器标识SQL Server进入缓冲(不是硬盘)获取数据的频率。对于在线事务处理(OLTP)应用，该计数器数值应该大于90%。如果不是这样，需要添加更多的内存提高性能，或者降低SQL Server的工作负载。
上面几个计数器是你最常需要使用的，能监视最基本的SQL Server活动情况。如何最佳利用性能监视器
一般而言，性能监视器提供两种主要的方式来分析Windows 2000和SQL Server 2000的计数器。一种是实时地显示图形化数据；另一种是将数据收集到日志文件，需要分析的时候再图形化显示出来。
如果你需要立刻分析并得到结果，实时化监视方式比较好。特别是你要立刻处理一些特定的性能问题的时候，该方式也很方便。实时方式缺省以一秒为单位收集数据，可以同时收集不同的计数器。这在分析计数器之间性能相关性的时候，特别有用。
虽然实时化方式很方便，不过要分析一段时间内的性能，用日志文件方式更有用一点。你可以选择那些计数器数据需要收集，收集的频率是多少。例如，你可以在24小时内，每隔一分钟，收集20个计数器的数据；或者也可以选择收集30天内，每隔10分钟， 50个计数器的数据。数据被收集后，性能监视器可以以图表的形式显示便于分析，或者你也可以将数据导入到数据库或者电子表格中进行更详细的分析。
如果你很关注SQL Server的性能情况，强烈建议总是监视那些关键的计数器，并进行趋势分析(可以利用Microsoft Excel为工具)。例如，利用收集的数据进行趋势分析，有助于预测SQL Server对硬件的需求，如是否需要更多的CPU，更快的I/O设备或更多内存。趋势分析保留了历史数据，你可以利用其来向你的上司说明你为什么需要对现有硬件配置进行升级或更换。
性能监视器是一个十分有用的工具，值得我们花时间去掌握。你会发现，可以方便的利用它来发现性能问题，帮助你评估将来的硬件需求.
2858
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
