性能监视器的各类指标
一、内存指标
1、Windows层面上的内存使用检查
在检查SQL Server内存使用之前，DBA必须首先检查一下Windows层面的内存使用情况。
Windows层面没有明显的内存压力，是SQL Server正常运行的前提。
需要检查的有：
1.Windows系统自身内存使用数量、内存分布，Windows是否有内存压力，以及压力是否比较严重。
2.DBA还要检查服务器上每一个进程的内存使用情况，俩接哪些进程用的内存最多，哪些进程有内存压力。
3.还应该对照这些进程和Windows系统，分析它们是否相互影响。
在完成了这些检查，DBA才能确认是SQL Server是否存在来自SQL Server外部的内存压力。
这些工作可以用Windows的性能监视器Performance Monitor来完成。
下面会说明Windows系统内存使用的、单个进程内存使用的一些性能计数器Performance Counter。
针对一些指标也会有它们的阀值。但需要注意的是，仅仅通过一两个性能指标，就断定问题所在是比较危险的，常常会得到相反的结论。很多性能指标是相互联系的、相互影响的。需要对比这些值的变化趋势、以及相互作用，才能得到正确的结论。
2、Windows系统使用情况
对Windows系统，主要从3个角度分析内存的使用。
1.整体使用分析.
(1)Committed Bytes = 物理内存 + 分页文件大小。
整个Windows系统，包括Windows自身，以及所有用户进程使用的内存总数，
包括物理内存里的数据和文件缓存中的数据。
(2)Commit Limit = 物理内存 + 分页文件大小。
整个Windows系统能够申请的最大内存数，其值等于物理内存加上文件缓存的大小。
如果Committed Bytes已经接近或者等于Commit Limit，说明系统的内存使用已经接近极限。
如果缓存文件不能自动增长，系统将不能提供更多的内存空间。
(3)*Available MBytes = 空闲物理内存。
现在系统空闲的物理内存数。这个指标能够直接反映出Windows层面上有没有内存压力。
(4)Page File：%Usage 和 Page File：%Peak Usage，分页文件使用量。
反应缓存文件使用量的多少。数据在文件缓存中存的越多，说明物理内存数量和实际需求量的差距越大，
性能也越差。
(5)*Pages/sec = 每秒从磁盘读取/写入的页面数 = 每秒从磁盘读取的页数 + 每秒从向磁盘写入的页数。
Hard Page Fault每秒种需要从磁盘上读取或写入的页面的数目。这包括Windows系统、所有应用进程的，所有磁盘Paging操作，是Memory：Pages Input/sec 和 Memory：Pages Output/sec的和。
实际上，还有一个指标是Memory：Page Faults/sec，只的是Soft Page Fault和Hard Page Fault的总和。
由于Soft Page Fault一般不会带来性能影响，因此一般不太关注。所以Page Fault/sec就没有Pages/sec那么有用。
总结：
一个性能良好的系统，需要处理的数据应该是长期保存在物理内存中。如果频繁的被换入换出，那么会严重影响性能，所以如果一个系统不缺内存，那么Pages/sec不能长时间的保持在一个高的值。
DBA通过比较Committed Bytes、Commit Limit、Page File：%Usage 和 Page File：%Peak Usage ,连接现有内存地址空间的使用大小,以及有多少数据是缓存在硬盘上的分页文件中。
通过查看Available MBytes的值，可以知道系统有多少空闲的物理内存还可以使用。对一个服务器，如果长期小于10MB，一般说明内存不够，同时还要查看Pages/sec的值，确认系统是否因为物理内存不足，而频繁做Paging操作。如果是，就说明物理内存不足。
2.Windows系统自身内存使用情况。
一般在32位上，Windows正常的内存使用约有几百MB，在64位机器上，可以到1-2GB左右。但如果Windows在做一些特殊操作， 或者Windows层面出现内存泄漏，一般由一些硬件驱动造成，Windows可能会用到几GB甚至10GB，反过来挤压了应用程序的物理内存使用， 所以DBA也要学会确认Windows自身的内存使用情况。
通过下面的性能计数器，可以知道Windows的内存使用情况：
*Memory：Cache Bytes = Windows使用的物理内存。
系统的Working Set，也就是系统使用的物理内存数目，包括高速缓存、页交换区、可调页的ntoskrnl.exe和驱动程序代码，以及系统映射视图等。
Cache Bytes计数器是下面几个计数器的和：System Cache Resident Bytes、System Driver Resident Bytes、
System Code Resident Bytes 和 Pool Paged Resident Bytes。它们的定义如下：
(1)Memory：System Cache Resident Bytes（System Cache）
系统高速缓存，消耗的物理内存，高速缓存的主要功能，是提高文件读写的速度。
(2)Memory：Pool Paged Resident Bytes
页交换区，消耗的物理内存。
(3)Memory：System Driver Resident Bytes。
可调页的设备驱动程序代码，消耗的物理内存。
(4)Memory：System Code Resident Bytes。
Ntoskrnl.exe中可调页代码，消耗的内存。
3.System Pool。
Windows中有两块重要的交换区Pool是，Memory：Pool Nonpaged Bytes非页交换区、Memory：Pool Paged Resident Bytes页交换区。
如果这两块内存出现泄漏，或者空间用尽，Windows会出现一些奇怪的不正常行为，进而影响SQL Server稳定运行，所以要检查一下这两块内存的使用情况。
3、单个Process使用情况
分析了Windows，就要开始看每个进程的内存使用。比较常见的是，从Available MBytes上看出服务器的内存基本用尽，
但从Memory：Cache Bytes的值看，Windows自己没有使用多少，现在要分析到底是哪个进程使用了物理内存。
需要强调的是，在使用Process下的性能计数器时，要注意选择所有的进程，
而不是只选择_Total下的计数器。大部分情况，_Total的值对分析问题没有什么意义。有必要把服务器上所有process的计数器都检查一遍，
才能找出内存使用不正常的进程。
(1)Process：%Processor Time 指的是目标进程消耗的cpu资源数，包括用户态和核心态的时间。
(2)Process：Page Faults/sec 指的是目标进程上发生的Page Faults的数目。
(3)Process：Handle Count 指的是目标进程handle，也就是指向object的指针的数目。如果进程内部有对象总是创建，不及时回收，就会发生Handle Leak。
(4)Process：Thread Count 指的是目标进程的线程数。如果进程总是创建新的线程，不释放线程，就会发生Thread Leak。
(5)Process：Pool Paged Bytes 指的是目标进程所使用的Paged Pool大小。
(6)Process：Pool Nonpaged Bytes 指的是目标进程所使用的Non-Paged Pool大小。
以上这些计数器比较好理解。
主要是下面这几个计数器含义不容易明白。但这些是判断一个进程内存使用的关键计数器，其实就是：是否已经提交、是否共享、是否在物理内存中。
(7)Process：Working Set 某个进程的地址空间中，存放在物理内存的那一部分。
(8)Process：Virtual Bytes 某个进程所申请的虚拟地址空间的大小，包括Reserved Memory 和 Committed Memory。
(9)Process：Private Bytes 某个进程的提交了的地址空间Committed Memory中，非共享的部分。
4、SQL Server的内存性能计数器
SQL Server服务器的性能监视器有很多以SQLServer: 或 MSSQL&<Instance Name>开头的计数器对象，这些计数器由SQL Server自己维护，
所以能从各方面反映SQL Server的运行状态。是管理员观察SQL Server是否健康的好工具。
为了俩接SQL Server内存使用情况，需要观察的计数器对象主要有：
1.Memory Manager：监视服务器内存总体使用情况的计数器。常用的计数器如下：
(1)Total Server Memory（KB）：从缓冲池提交的内存。注意，这不是SQL Server使用的总内存，只是Buffer Pool的大小。
(2)Target Server Memory（KB）：服务器能够使用的内存总量。当Total Server Memory小于Target Server Memory时，
说明SQL Server还没有用足系统能够给SQL Server的所有内存。SQL Server会不断的缓存新的数据页和执行计划，而不会对这2部分缓存做清理，
这样SQL Server的内存使用量会逐渐增加。
当Target Server Memory因为系统内存压力变小时，它可能会小于Total Server Memory。那么SQL Server会清理缓存，降低内存使用量，
知道Total Server Memory 和 Target Server Memory一样大位置。
下面这几个计数器反映了内存的分布情况。
(3)Optimizer Memory(KB): 服务器正在用于查询优化的动态内存总数.
(4)SQL Cache Memory(KB): 服务器正在用于动态SQL Server高速缓存的动态内存总数.
(5)Lock Memory(KB): 服务器用于锁的动态内存总数.
(6)Connection Memory(KB): 服务器正在用来维护连接的动态内存总量.
(7)Granted Workspace Memory(KB): 当前给予执行哈希、排序、大容量复制、索引创建等操作的进程的内存总量。
(8)Memory Grants Pending: 等待工作空间内存授予的进程总数。如果这个值不为0，就说明当前有一个用户的内存申请，由于内存压力而被延，。
这一般说明比较严重的内存瓶颈。
2.Buffer Manager：提供了计数器，用于监视SQL Server如何使用。
包括了：A。内存存储数据页、内部数据结构、过程缓存。
B。计数器监视SQL Server读取、写入的数据页时的物理IO。
由于Buffer Pool是SQL Server内存最活跃、使用最多的部分，所以也是最容易出现性能瓶颈的部分，这部分的计数器非常重要。
(1)Buffer Cache Hit Ratio：在缓冲区高速缓存中找到而不需要从磁盘中读取的页的百分比。该比率是缓存命中总次数，
与过去几千次页面访问的缓存查找总次数之比。经过很长时间后，该比率的变化应该很小，基本上应该在99%以上。
由于从缓存中读取数据，比从磁盘读取数据开销要晓得多，一般希望这个比率高一点。
如果小于95%，通常就说明内存不足，可以通过增加SQL Server的可用内存量来提高缓冲区告诉缓存命中率。
(2)Checkpoint pages/sec: 由要求刷新所有脏页的检查点，或者其他操作每秒刷新到磁盘的页数。这个计数器的值与内存有没有压力没有直接关系。
相反，和用户的行为有关，如果用户主要是读，就不会有很多数据改动的脏页，checkpoint的值就比较小。
相反，如果用户做了很多增删改操作，那么内存中修改过的脏页就很多，每次checkpoint的量就大，这个值在分析Disk IO问题时用的比较多。
(3)Database pages: 缓冲池中有数据库内容的页数，也就是所谓的Database Cache的大小。
(4)Free pages: 所有空闲可用的总页数。当这个值降低时，说明SQL Server正在分配内存给一些用户。当这个值下降到比较低时(只剩几百个page)，
SQL Server就会开始做Lazy Writer，把一些内存腾出来。所以一般这个值不会是0，但是如果反复降低，说明SQL Server存在内存瓶颈，
一个没有内存瓶颈的SQL Server的Free Pages会维持在一个稳定的值。
(5)Lazy writes/sec: 每秒被缓冲区管理器的惰性编写器Lazy writer写入的缓冲区数。惰性编写器是一个系统进程，用于批量刷新脏的老化的缓冲区，
(包含更改的缓冲区，必须将这些更改写回磁盘，才能将缓冲区重用于其他页)，并使它们可用于其他用户进程。
这些数据页和执行计划，被称为老化的缓冲区，而这个清理动作，就是由Lazy writer完成的。所以如果SQL Server内存压力不大，
Lazy writer就不会被经常触发，如果被经常触发，那就说明有内存瓶颈。
(6)Page life expectancy: 页如果不被引用，会在缓冲池中停留数秒。如果SQL Server没有新的内存需求，或者有空余的空间来完成新的内存需求，
那么Lazy writer就不会触发，页面会一直被放在缓冲池里，那么Page Life Expectancy就会维持在一个比较高的水平。
如果SQL Server出现了内存压力，Lazy writer就会被触发，Page Life Expectancy就会突然下降。
所以一个SQL Server的Page Life Expectancy总是高高低低，不能维持在一个稳定的水平上，那这个SQL Server应该有内存压力。
(7)Page reads/sec：每秒发出的物理数据库页的读取数。这个统计信息显示的是所有数据库间的物理页的读取总数。
(8)如果用户访问的数据都缓存在内存中，那么SQL Server就不需要从物理磁盘上读取页面。对一个内存非常充裕的SQL Server，运行一段时间后， 理论上应该能把自己要的数据全都缓存在内存中，不需要再做任何Page Reads。所以从一个侧面反映了SQL Server的内存是否不足。
而当SQL Server需要读这些页面时，必须要腾出内存空间，所以当Page reads/sec比较高时，一般Page Life expectancy会下降，Lazy writer/sec会上升，这都是有关联的。
(9)由于物理IO的开销大，Page Reads动作一定会影响SQL Server的性能，可以通过使用更大的数据缓存、智能索引， 更有效的查询，或者更改数据库设计等方法，将Page reads降低。
(10)Page writes/sec：每秒执行的物理数据库页的写入数。这个值和内存使用没什么关系，和Checkpoint pages/sec一样，跟用户的修改量有关。
(11)Stolen pages: 用于非Database Pages（包括执行计划缓存）的页数，这里是Stolen Memory在Buffer Pool中的大小。
(12)Target Pages：缓冲池中理想的页数，乘8KB就应该是Target Server Memory的值。
(13)Total Pages：缓冲池的页数（包括数据库页、可用页、Stolen页）乘以8KB，就应该是Total Server Memory的值。
从这些SQL Server内存计数器，再加上系统一级的内存相关的计数器，DBA就能从性能监视器日志中分析SQL Server的内存使用的历史情况。
二、CPU指标
要确定服务器CPU使用率到底是多少，其中有多少是SQL Server使用的。如果SQL Server的CPU使用率不是很高，
而是其他应用程序导致的，那也不用继续检查SQL Server了，这个性能监视器可以很容易的检查。
1.检查整个服务器的CPU使用情况，可以使用下面这些计数器：
(1)Processor：%Processor Time : 该计数器可以监视CPU执行的非闲置线程所用的时间。
持续80%到90%的状态可能表明需要升级CPU或需要增加更多的处理器。
对于多处理器系统，应该为每个处理器监视一个该计数器的独立实例，代表了在一个特定处理器上的处理器时间之和。若要确定所有处理器的平均时间，请使用System: %Total Processor Time计数器。
(2)Processor：%Privileged Time（Kernel Mode）：对应于处理器执行Microsoft Windows内核命令（如处理SQL Server I/O请求）所用时间百分比。
如果Physical Disk计数器的值很高时，该计数器的值也一直很高，则考虑安装速度更快或效率更高的磁盘子系统。
(3)Processor：%User Time（User Mode）：对应于处理器执行用户进程（例如 SQL Server）所用时间的百分比。
(4)System：Processor queue length：对应于等待处理器时间的线程数。
当一个进程的线程需要的处理器循环数超过可获得的循环数时，就产生了处理器瓶颈。
如果有很多进程在争用处理器时间，可能需要安装一个速度更快的处理器。如果使用的是多处理器系统，则可以增加一个处理器。
(5)Context switches/sec：指计算机上的所有处理器全都从一个线程转换到另一个线程的综合速率。
当正在运行的线程自动放弃处理器时出现上下文转换，由一个有更高优先就绪的线程占先或在用户模式和特权 (内核) 模式之间转换以使用执行或分系统服务。
如果此计数器的数值较大，则表明锁定竞争很激烈，或者线程在用户和内核模式之间频繁切换。
2.检查每个进程的CPU使用情况，可以使用下面这些计数器：
(1)Processor：%Processor Time
(2)Processor：%Privileged Time（Kernel Mode）
(3)Processor：%User Time（User Mode）
检查处理器使用率时，需考虑 SQL Server 实例执行的工作类型。如果SQL Server正在做大量的运算，例如包含聚合的查询，或受内存限制但不需要磁盘I/O 的查询，此时所用的处理器时间可能是100%。
如果这导致其他应用程序的性能降低，应尝试改变工作负荷。例如，让计算机只运行 SQL Server 实例。
若使用率为 100% 左右（表示在处理大量的客户端请求），可能表示进程正在排队，等待处理器时间，并因而导致出现瓶颈。可以通过增加速度更快的处理器来解决这一问题。
三、IO指标
在确定SQL Server是否有IO问题，以及IO问题的根源之前，DBA要先检查一下Windows层面的IO是否正常。
如果整个系统的Io比较繁忙，就要确认这个负荷是否只来自于SQL Server。这个思路和分析，与内存问题是一样的。
从Windows的层面分析方法，将主要依赖于性能监视器中的各个计数器。Windows可以在一个物理磁盘上划出若干个逻辑分区，给每一个分区一个逻辑盘符，也可以将整个磁盘做单独一个分区使用。
对于分配在同一块物理磁盘的逻辑分区，其实它们的操作都是共享磁盘的读写带宽，相当于在一块磁盘上的工作。
而Windows上的应用，只认逻辑盘符。逻辑盘在哪一块物理磁盘上，是否和其他逻辑盘共享同一块磁盘，应用程序是不知道的。
所以关于磁盘，有两组计数器，LogicalDisk和PhysicalDisk：
A.LogicalDisk：记录的是按照逻辑盘符，每个逻辑盘的读写计数器。从这些计数器，我们可以俩接系统及应用向不同的盘符发出的工作量各有多大。
B.PhysicalDisk：以物理磁盘为单位。如果某个武力磁盘时由RAID组成的磁盘陈列，那么Windows只会列出一整块物理磁盘。如果物理磁盘上有若干个逻辑分区，这些分区将以一组为单位出现。
从PhysicalDisk下的计数器，可以了解磁盘的响应速度。所以如果要分析磁盘的性能，主要是分析PhysicalDisk下的计数器，而LogicalDisk只起到参考作用。
1.系统级
常用的磁盘计数器有：
(1)% idle time
表明在采样区间内，磁盘处于空闲状态的百分比。相对于经常大于100%的 %Disk Time，这个值是准的。
当磁盘处于空闲状态时，它的值是100%。当磁盘在满负荷操作时，它的值是0%。所以建议通过这个值，反推出%Disk Time的真实值。
(2)% disk time
表明在采样区间内，磁盘处于读写状态的百分比。理论上，这个值应该小于100%，而且应该是%Disk Read Time 和 %Disk Write Time的和。
但由于算法的限制，在磁盘很忙的时候，这个计数器往往会远大于100%。所以这个计数器能够给DBA看到一个趋势线，但是值本身是不准的。
(3)% disk read time
(4)% disk write time
(5)Disk Bytes/sec
每秒磁盘读、写的数量，以Bytes为单位。它是Disk Read Bytes/sec 和 Disk Write Bytes/sec的和。
一个很保守的参考值是：
好： (20MB - 40MB)
一般：(10MB - 20MB)
(6)Disk Read Bytes/sec
(7)Disk Write Bytes/sec
(8)Disk Reads/sec
(9)Disk Writes/sec
(10)Disk Transfers/sec
(11)Avg. disk sec/transfer 磁盘每一次读或者写的操作所花的平均时间。
(12)Avg. disk sec/read 磁盘每一次读操作所花的平均时间。
(13)Avg. disk sec/write 磁盘每一次写操作所花的平均时间。
这3个值也经常用来衡量磁盘的速度。参考值是：
很好： < 10ms
一般： 10 ~ 20ms
有点慢：20 ~ 50ms
非常慢：> 50ms
(14)Avg. disk bytes/transfer
(15)Avg. Disk Queue Length
在某个时间点，磁盘队列的长度，也就是发出的磁盘操作正在鞥带被磁盘处理的请求数目。
例如：有一个应用发出一条读请求，但是目标磁盘当时正在处理其他任务。那么这个新的读请求就会被放在磁盘队列里。
这个时候磁盘队列的值就是1。理论上，这个值不应该长时间的大于2.
(16)Avg. disk read queue length
(17)Avg. disk write queue length
(18)Current Disk Queue Length
需要强调的是，分析者不能从某一个计数器的值就确定磁盘有没有瓶颈，而是要综合他们的值看。
例如，在磁盘负荷高峰时，可能会看到Avg. disk sec/transfer 比较高的现象，但是这个时候Disk Bytes/sec是不是也很高就比较关键了。
如果Disk Bytes/sec已经接近了磁盘的最高上限，那么就更是一个磁盘超负荷的问题了。
如果Disk Bytes/sec不算很高，那么应该考虑为什么磁盘的速度不理想，是磁盘本来就能力比较差，还是哪里的硬件配置不优化。
另外，SQL Servr并不是一直在发起IO请求，但是发起了以后，总希望能够快速做完。如果不能及时做完，就会影响性能。
所以看计数器的值，要更加看磁盘繁忙的那些时间段，而不是整体时间的平均值，整体时间的平均值基本上没有什么意义。
举例，checkpoint影响SQL Server整体性能的问题。当时断言这块磁盘比较慢。
那么这是怎么看出来的呢？主要是比较下面3个计数器：
Avg.Disk Queue Length：当SQL Server在做checkpoint时，disk queue是很长的，最长值在40以上。
这时候，Disk Bytes/sec的最大值基本上在7MB，而Avg.Disk sec/Write却经常超过50ms。
所以可以说这块磁盘的吞吐量是比较低的，只要用户一直在这样修改数据库，SQL Server就需要这样写日志，这个工作量是无法减少的。所以要解决这个问题，一定要解决磁盘的写入速度问题。
2.SQL Server相关的性能计数器
除了动态管理视图、SQL Trace文件外，性能监视器里和SQL Server相关的一些计数器也可以提供很多有用的信息。
它们能够反映SQL Server引起IO动作的操作频率，以及它们的完成情况。
常用的如下：
A：Buffer Manager
下面的计数器能够反映和Buffer Pool有关的IO动作。
(1)Page Reads/sec 和 Page Writes/sec
反映SQL Server每秒读写多少页面。通过这两个计数器，可以清楚的了解由于Buffer Pool的行为带来了多少磁盘读写。
(2)Lazy Writes/sec 反映Lazy Writer为了清空Buffer Pool每秒做了多少页面的写入操作。
(3)Checkpoint Writes/sec 每秒从Buffer Pool中写入到磁盘的Dirty Page数目。
(4)Readahead Pages/sec 每秒SQL Server做的预读(read ahead)数目。
B：Access Methods
除了读取和写入指令需要访问的页面，SQL Server还要做一些辅助工作，帮助指令完成。这些工作也会带来IO动作。
例如:
(1)Freespace Scans/sec
在堆heap结构中查找能够使用的空间。对没有聚集索引的表，SQL Server会以堆的形式存储。
如果这个计数器很高，说明SQL Server在堆的管理上花费了很多资源。应该考虑多建一些聚集索引。
(2)Page Splits/sec
当表上有许多插入操作时，一些页面会被放满。为了维护索引上的顺序，SQL Server需要把一页分成2页，这个操作就是Page Split。
当数据库的修改比较多，尤其是插入比较多时，Page Split是难免的。如果这个值比较高，而你又觉得它的确对性能有影响，
那么可以考虑定期重建索引，使用比较小的填充值(fill factor).
(3)Page Allocations/sec 当SQL Server需要创建对象，例如，表、索引时，分配给新对象的页面的数量。
(4)Workfiles/sec
当SQL Server为了完成某些操作而在内存中建立一个Hash结构时(例如用Hash的算法做Join时)，该计数器就加1.
如果某些Hash结构比较庞大，SQL Server可能会将一部分数据写入硬盘里，所以这个值其实并不直接意味着磁盘读写。
但是由于SQL Server 通常只是在没有合适的索引时，才选择Hash算法，所以DBA可以通过这个值来了解数据库的索引是不是需要优化。
很多情况下索引优化就能够大大降低SQL Server的读的数量。所以在做IO问题时，这个计数器也是必须要看的。
(5)Worktables/sec
每秒创建的工作表数。例如，工作表可用于存储查询假脱机query spool、Lob变量、XML变量、表变量、右边的临时结果。
(6)Full Scans/sec
每秒SQL Server做的全表扫描数目。如果一个表设计良好，就应该没有很多的全表扫描。
而全表扫描通常意味着比较大的内存使用和比较多的IO请求。所以在一个SQL Server系统，尤其是一个OLTP系统，这个值越小越好。
(7)Index Serarches/sec 每秒检索索引的次数，也就是利用索引完成指令的数目。
C：Database
在这个计数器组下面，我们能够看到一些和日志写入有关的计数器。
例如;
(1)Log Flushes/sec SQL Server每秒在这个数据库上做的日志写的次数。
(2)Log Bytes Flushed/sec SQL Server每秒在这个数据库上做的日志写的量Bytes。
(3)Log Flush Wait Time
写入日志的操作曾经因为磁盘来不及响应而遇到的等待时间。
这种等待会导致前端的事务不能提交，所以会严重影响SQL Server的性能。正常的SQL Server，这个值应该在绝大多数时间里都是0.
(4)Log Flush Waits/sec
在每秒提交的事务里，有多少个事务曾经等待过日志写入完成。
理想情况下，日志写入应该立刻完成，不需要等待。如果有等地啊，需要检查存放日志文件的磁盘性能。
(5)MSSQL:SQL Statistics - Batch Requests/sec SQL Server每秒完成的批处理Batch数目。
(6)MSSQL:Databases - Active Transactions 在SQL Server里打开的，还没有提交的事务数。
(7)MSSQL:Databases -Transactions/sec
每秒的的事务数。
D：General Statistics
(1)MSSQL:General Statistics -User Connections 用户连接数