数据库管理员的主要责任之一是持续监视SQL Server性能。之所以要进行监视，原因 有多种，包括性能、存储状态、安全性和标准符合程度等。虽然很多此类监视可以自动完
成，但在大多数情况下，数据库管理员必须以系统的方法说明监视的结果并对其采取行动。
监视工作需要持续进行，它可能变得非常复杂。知道监视什么、什么时候监视以及什么是
可接受的和不可接受的行为，这些都可能成为一项全职性工作的内容。使事情变得更困难
的是，每个SQL Server安装都是不同的，所以很难给出一个关于可接受和不可接受性能的 指标的通用性建议。
本章介绍了各种用来监视SQL Server的工具，并就如何使用这些工具标识潜在安全问 题和可优化部分提供指导。监视SQL Server是一个充满挑战的过程。SQL Server与每个操 作系统子系统都有大量交互。一些应用程序非常依赖RA M ,而另一些则是CPU密集或磁
盘密集型。SQL Server可能同时符合这三种情况。SQL Server也可能是网络密集型的，尤 其是分布式应用程序、复制或数据库镜像这些部分。许多数据库管理员觉得整个监视和优
化的过程是神秘而模糊不清的。不过，它并没有那么神秘。很好地理解工具并熟悉要监视
的不同对象，可以使监视任务变得不那么令人生畏。
许多书都讨论监视的主题，还有一些网站专门讨论它。本书不会介绍有关监视SQL
Server的一切内容，但是会解释-些基本知识，这是最好的起始点。
1 0 .1 性能监视
SQL Server 2008监视本质上可以分为5 个基本区域：
• 系统资源
• SQL Server 自身
• 数据库
• 数据库应用程序
• 网络
在开始探讨性能监视的具体方面之前，了解监视方法是很重要的。为了监视而监视是没
有意义的。监测硬件和SQL Server实现方案是为了预测和预防性能问题。为此，必须有某种 计划，即一种可使您投入适当的时间量和资源量来维护和改善SQL Server的性能的策略。
10.1.1 性能监视策略
监视和优化SQL Server的策略是相当简单的，由以下几步组成： (1) 创建一个性能基准一 如果数据库服务器没有一个基准，那么在改动服务器平台
时，很难确信更改会达到期望的性能改进。基准包含之前提到过的所有系统(系统资源、SQL
Server、数据库、数据库应用程序和网络)的度量。具体的计数器和度量将在本章稍后论述。 当评估基准时，可以确定保证即时优化的区域。如果做了更改，则必须创建一个新的基准。
(2) 完成定期性能审核一 在创建基准之后，执行定期性能审核确保在基准创建之后
性能没有降低。这一步通常会由被动的审核补充或取代，执行被动审核的目的是为了回应
对服务器性能低下的抱怨。我倾向于主动安排这些审核，但有时还是会因为发生不可预料
的性能问题而进行被动审核。
(3) 做出改动并评估它们的影响一 在执行审核之后，可能会发现需要修改的区域。
在做出这些改动时，需要相当小心。一般来说，不应该一次进行多个改动，而是应该先执
行一两个改动，然后评估提示您进行更改的度量。这样更加容易找到哪些更改对于性能的
影响最大。第 11章将更详细地介绍在性能审核标识出问题区域时，可以执行的用于优化
SQL Server的具体更改。
(4) 重设基准—— 完成所有修改之后，可以创建另一个基准来度量未来性能趋势。
Mad Clicker
我曾经与一位被众人亲切地称为“Mad Clicker(疯狂敲击者)”的同事共事.当服务器 房间里出现问题时，他总是会投入其中并开始不停敲击键盘，对配置设置做彻底的更改以
期能够解决问题。他通常都会成功，但以后想要重复他的操作几乎是不可能的，因为甚至
他自己都不清楚自己改动的每一个内容。因此，不要成为一位“Mad Clicker”。每完成一 项改动之后，要度量并归档结果。这样重复操作就很简单，而且如果这个改动导致了性能
降低而不是提升，还可以轻松地回滚。
1 0 .1 .2 创建一个性能基准
在创建基准时，监视典型活动是很重要的。在每月一次的导入中监视性能可能会带来
一些有趣的数据，但是它对评估和提髙整体的系统性能没什么帮助。创建基准的方式有多
种。大多数数据库管理员对于搜集和比较性能数据有自己的偏好。他们还有自己喜欢的计
数器和系统视图，认为这些计数器和系统视图可以让他们更好地了解数据库的性能。其实
SQL Server性能监视和优化与其说是一种科学，不如说是一种艺术。 关于搜集哪些“系统监视器”计数器和监视哪些SQL Server所特定的活动，我曾经看 到过很多种建议。所有建议都是各不相同的。有些数据库管理员建议监视所有内容，而另
一些则建议有选择地监视一小部分进程。我支持后者，原因有两点。第一个原因是“信息太
多”这样的情况肯定会出现。如果收集了所有的性能数据，那么很可能会导致“只见树木，
不见森林”，因为有太多的数据需要详细审査。第二个(可能也是更重要的)原因是性能因素。
搜集性能信息不是没有代价的。搜集得越多，性能损耗就越大。这就出现了一个有趣
的悖论。要想充分地监视性能，必须把性能降级操作引入到数据库中。这所导致的窘境就
是，您无法肯定自己的监视行为与不可接受的性能之间一点关系都没有。
限制检索的数据可以减少这一不确定性，但是要记住，不应当孤立地看待任何一个特
定的计数器。例如，繁重的磁盘活动可能是由内存限制引起的，而 CPU性能低下可能是因
为编写的查询较差或索引丢失造成的。任何子系统都不是处于真空中的。
那么，基准中应包含什么呢？根据多年的经验，我总结出了一个为基准和性能审核而
监视的对象和进程的列表。下面将介绍这些计数器。
创建性能基准的主要工具是性能监视器。不过，我们也使用动态管理视图(Dynamic Management View, DMV)来给基准提供更多的上下文。在解释完用于基准和性能审核的计 数器之后，本章会深入介绍SQL Server特有的工具，并探讨如何识别不正常的进程。
1 .性能计数器
下面的一些计数器在进行性能审核时都很有用。这里的讨论并不包括所有的计数器，
所涉及到的都是我和一些同事所依赖的从宏观上了解SQL Server性能的一些计数器。除此 以外，还有很多计数器可以用来诊断性能问题和深入研究SQL Server活动。但是这里介绍 的计数器更有可能提供快速评估服务器状态所需的信息。
处理器计数器
处理器计数器(Processor Counter)和其他计数器一起使用，用来监视和评估CPU性能并 辨别CPU瓶颈。
• Processor： % Processor Time-----Processor： % Processor Time 计数器显示了处
理非闲置线程所用时间的总百分比。在一个多处理器的机器上，可以独立监视每
一个单独的处理器。如果定制了 CPU关联设置，那么您可能想要监视一个特定的
CPU。除了这种情况之外，我一般使用_total实例标识符来査看组合的处理器使用。 CPU活动是SQL Server CPU活动的一个很好的指示器，也是一个识别潜在的CPU 瓶颈的关键方法。对于这种计数器应该是怎么样的，不同的人有不同的建议。一
般来说，如果总的％ Processor Time —直大于70%，那么可能就出现了一个 CPU 瓶颈，此时应当考虑优化当前应用程序进程，或升级CPU ,或两者都做。应当把
这个计数器和Processor Queue Length计数器一起使用来确定CPU瓶颈。
• Process处理： % Processor Time 处理器时间(sqlservr)----- 当设置为监视来自于 SQL Server 进程
的信息时，Process： % Processor Time计数器可以用来确定总处理时间中有多少由
SQL Server 占用。
• System: Processor Queue Length-----Processor Queue Length 计数器显示等待由
CPU处理的线程的数量。如果平均队列长度一直大于处理器数量的两倍，那么可
能出现一个CPU瓶颈，因为处理器来不及处理请求。
可以同时使用Processor Queue Length和％ Processor Time计数器来确定是否存在CPU
瓶颈。如果两者都处于可接受的范围之外，那么一定存在CPU瓶颈。
如 果 Processor Queue Length不在可接受的范围之内，但％ Processor Time在可接受范
围之内，那么可能没有出现CPU瓶颈，而只是存在配置问题。需要确保对于系统来说，没
有将最大工作线程数(max worker threads)服务器设置的值设得过髙。最大工作线程数的默
认设置是0 ,这会使SQL Server自动将最大工作线程数设置为和表10-1中的值相一致。不 过，除了 0 之外，还可以配置128〜 32 767之间的任意值。SQL Server联机从书给出的可 接受范围是32〜 32 767,这是错误的。图形化界面会接受0〜 32 767之间的任意值，但 1〜
127之间的任何值都会被设置为128。
磁盘计数器
有一些磁盘计数器可以返冋每个物理磁盘或所有磁盘的磁盘读写性能信息和数据传
输信息。和内存统计信息组合在一起时，物理磁盘统计信息有助于精确了解服务器上的总
IO性能。
• PhysicalDisk: Avg. Disk Queue Length-----作为现代计算机系统中最后一个机械
组件，磁盘天生就是最慢的，即使其拥有所有磁盘控制器都有的内置缓存也是如
此。Avg. Disk Queue Length计数器返回等待访问一个独立磁盘或所宵磁盘的读写 操作的平均数量。将请求排队是因为磁盘过于繁忙，而控制器的板载内存没有空
间临时存储读写请求。此计数器的值应小于物理磁盘数乘以2 得到的结果。例如，
如果数据库位于一个10个磁盘的阵列上，计数器应当低于20。
如果此计数器一直大于理想值，那么鉍有可能的原因是磁盘子系统性能不足，或
者服务器上没有足够的内存。缺少内存会导致磁盘子系统由于SQL Server无法长 时间在内存中缓存数据而超负荷工作，从而造成更多的物理磁盘读取。把数据库
分布在多个磁盘和多个控制器上可能会提髙性能。如有可能，把内存添加到磁盘
控制器上，这也可以减轻磁盘瓶颈。
• PhysicalDisk: % Disk Time—— 该计数器测量一个物理磁盘或硬件磁盘阵列的繁
忙程度。% Disk Time计数器不应当一直超过60%。如果是这样，需要检査％ Disk Read和％ Disk Write计数器以确定该磁盘主要在执行什么样的活动。如果数据库 使用了一个以上的阵列，那么可以使用此计数器来确定磁盘工作负荷是否平分到
所有阵列中。
内存计数器
如前所述，数据库管理员使用内存计数器(和磁盘计数器)获取数据库I/O的总体情况。
缺少内存会直接影响磁盘活动。在优化-个服务器吋，总是应该考虑添加内存。SQLServer 会使用大量内存，并根据最小化数据库操作所需的磁盘访问量来有效地分配它们。如果您
在寻找一个解决SQL Server性能问题的万能药，那么添加内存是最接近的选择。 • Memory: Pages/Sec-----Pages/Sec计数器测量每秒从内存中分页到磁盘或从磁盘 分页到内存的页数。官方建议此计数器不应一直大于0。但是很有可能它会有规律
地超过0 , 然后返冋到近似于0 , 然后再次升高，如图10-1所示。这是很正常的，
但如果计数器一直大于0 , 这表明可能存在内存瓶颈。解决方法当然是添加内存。
但是，如果服务器上有很多内存，那么原因也可能是最人服务器内存设置得过低。
Available Bytes内存计数器会显示系统还有多少内存可用。
导致有规律地进行内存分页的另-个可能原因是除了 SQL Server之外，服务器上 还运行着另外一个应用程序。理想状态下，SQL Server应当是服务器唯一支持的 应用程序。虽然有些时候这是不可能的，但它仍然是理想的配置。
• Memory: Available Bytes-----Available Bytes计数器指示有多少内存可供进程使 用。官方建议至少要有5MB的可用内存，但这是一个相当低的数字，实际上应当
设为至少50MB。
• Process:Working Set (sqlservr)-----Working Set 计数器显示 SQL Server 使用了多
少内存。如果该数字总是低于最小服务器内存设置或者显著低于最大服务器内存
设置，那么SQL Server很有可能被配置为使用过多内存。只要不干扰其他服务器 进程，这并不一定是坏事。
• SQL Server: Buffer Manager: Buffer Cache Hit Ratio-----Buffer Cache Hit Ratio 计
数器测量在缓冲区中找到数据，而不用再去读磁盘的时间百分比。此计数器的值
应当相当髙，最好是90%或更髙。当低于90%时，磁 盘 I/O会变得很髙，给磁盘
子系统造成额外的负担。
• SQL Server: Buffer Manager: Page Life Expectancy-----Page Life Expectancy 计
数器返回一个单位为秒的时间值，显示数据页在缓冲区中停留而不会被数据操作
引用的时间。此计数器的最小值大约是300秒。此计数器和Buffer Cache Hit Ratio
计数器可能是SQL Server内存状况的最佳指示器。这两个计数器的数值越髙越好。
网络计数器
大多数网络计数器都没有规定必须査看什么。能够给出的唯一的指导意见就是要确保
服务器上生成的网络流量处于网络连接的容量之内。不过，网络计数器是测量一段时间内
的网络流量的一个很好的方式，它可以评估网络流量趋势，从而确定是否需要某种类型的
扩展或负载平衡。
• Network Interface: Bytes Total/Sec-----Bytes Total/Sec 计数器测量在服务器和网
络之间来回发送的总字节数。如果服务器被配置为SQL Server独享，那么几乎所 有的流量都属于SQL Server。如前所述，该计数器对于分析网络流量趋势很有帮 助。这些信息也可以用于规划向外扩展和升级要求。
SQL Server计数器
在安装SQL Server之后，有人量的SQL Server性能对象和计数器被配置为协助SQL
Server的性能监视和优化。99%的数据库管理员都不会査看其中大多数的计数器。不过， 有一些计数器是管理员需要完全依赖的。在创建基准和并将活动与基准对比以确定SQL
Server的性能状况时，以下SQL Server特有的计数器十分有用。
• SQL Server: General Statistics: User Connections---- User Connections 计数器显
示了当前连接到SQL Server的用户连接数。此计数器在监视和跟踪连接趋势时很 有用，可确保服务器足以管理所有连接。记住，此计数器显示的是用户连接数，
而不是用户数。有些应用程序会为每个用户创建多个连接，而其他的应用程序可
能仅创建一个连接，但支持多个用户。
• SQL Server: Locks: Average Wait Time-----Average Wait Time 计数器是一个很好
的计数器，用来监视和跟踪由于并发数据阻塞造成的用户对于数据资源的请求需
要等待的平均时间。有了基准和后面的审核，此计数器将成为一个数据库应用程
序性能的主要指示器。但是它只是一个指示器。解决长时间的锁定需要运行跟踪
记录锁定信息。本章稍后将讨论跟踪。
• SQL Server: Locks: Deadlock/Sec----当两个或两个以上的事务锁定了不同的资
源，且其中一个事务要求访问对立事务持有的资源时，就会发生死锁。如果觉得
难以理解，可以参见下面“导致死锁的示例事件”一段的内容，了解导致死锁的
事件序列。
• SQL Server Access Methods: Page Splits/Sec-----如第 5 章所述，当 SQL Server
试图向聚集索引或非聚集索引页中插入一行时，如果没有足够的空间容纳新行，
则将会发生页拆分。为了维护索引页的连接性，SQL Server会拆分出原数据页大 约一半的数据，并将其移动到未分配的页上。数据拆分是维护索引必需的，但它
会造成过度的I/O操作，因为逻辑上相连的数据已不再是物理上相连的。随着插
入的行越来越多，数据碎片将变得更加严重。
Page Splits/Sec计数器通过对页拆分活动进行监视来确定表索引的碎片化速度。虽然存 在一定量的页拆分是正常的，但过度的页拆分会导致数据库性能的持续恶化。第 5 章解释
了如何检测、纠正和减轻这种碎片化。
当监视页拆分活动时，在重新生成索引后即可创建一个基准。接下来的性能审核完成
后，比较页拆分活动。当计数器开始出现峰值时，就应该使用一个合适的填充因子来重新
生成索引。
导致死锁的示例事件
在不同的连接上同时执行两个存储过程。第一个存储过程Procl更新Table A 中的一行 或多行。第二个存储过程Proc2更新Table B 中的一行或多行。此时，Procl在 Table A 中 已更新的行上有排他锁，Proc2在 Table B 中已更新的行上有排他锁。 下一步，Procl试图更新TableB中已被Proc2更新过的行。但是它无法更新，因为Proc2 已经有一个排他锁了。此时，Procl被 Proc2阻塞。然后Proc2试图更新Procl更新过的行， 也被阻塞。这种互相阻塞就叫做死锁。
SQLServer不会允许死锁继续下去。数据库引擎监视死锁，如果发现一个，它就会选 择并终止一个进程。一个已终止的死锁所引发的错误如下所示：
Msg 1205, Level 13, State 51, Line 6 Transaction (Process ID 53) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
进程选择的依据是开销。回滚开销最少的进程会被终止，而剩下的进程则会继续，导
致死锁最显著的原因是在一个不一致的进程中更新表。当数据库开发人负创建用于数据修
改的过程时，应尽可能以相同的顺序更新多个对象。例如，如 果 Procl和 Proc2都先更新 TableA,然后再更新TableB,这样可能会发生一个短时间的锁定，但不会出现死锁。 死锁有时候会发生，但它们不应当经常发生。因为SQL Server会自动检测并终止它们， 因此有时很难进行查错。Profiler工具可用于识别死锁中违反规则的进程，本章稍后将会介 绍该工具。
2 .动态管理视图
SQL Server 2008提供很多动态管理视图(DMV),可以用来搜集基准信息和诊断性能问 题。其中一些视图提供了和性能计数器一样的信息，但采用的是关系型的即时格式。其他
视图提供了更加具体的数据库性能信息。本节并不会介绍所有的视图，但下面的视图在创
建和比较性能基准中会相当有用：
• sys.dm_os_performance_counters-----就操作系统信息而言，sys.dm_os_performance_
counter是一个非常有的动态管理视图。该视图提供的信息和性能监视器很类似, 只是信息以关系格式返回，而返回的值也是即时的。因为数据是即时的，所以至少
需要查询每秒计数器两次才能确定它们真实的值。该视图返回的列如表10-2所示。
sys.dm_db_index_physical_stats-----如 第 5 章所述，该视图返回与一个表上的索引
相关的信息，包括每个数据页上的数据ft,索引叶级和非叶级上的碎片数量，以 及索引中记录的平均大小。
• sys.dm dbindexusageStats-----sys.dm dbindexusagestats 视图收集累积的索引
使用数~据。此视图可以用来标识很少引用的索引，它们可能导致开销增长而不是
提髙读取性能。下面的代码例子演示了该视图的一种可能的使用方式：把它和sys.
indexes系统视图联接起来，以返回索引名称、表名称和索引使用信息：
USE AdventureWorks2008; GO
SELECT object_name(S.object_id) AS TableName
,I.name AS IndexName, S,user_seeks AS Seeks ,S.user_scans AS Scans, S•user_updates AS Updates ,S.last user seek AS LastSeek, S.last user scan AS LastScan FROM sys.dm_db_index_usage_stats S
JOIN sys.indexes I ON S.object_id =1.object_id
AND S.index_id =1.index_id WHERE S.object一id > 100000 --Return only user owned index data ORDER BY Seeks, Scans;