数据库管理员的主要责任之一是持续监视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。
原文地址：https://www.cnblogs.com/zhouwansheng/p/9462362.html