作为DBA，每个人都会用一系列计数器来监视SQLSERVER的运行环境，使用计数器，既可以衡量当前的数据库的性能，还可以和以前的性能进行对比。我们也可以一直以快速和简单的方法把计数器做了一张图表来识别数据库的性能的变化情况，来分析数据库性能的趋势。

　　下面是我常用的前10位的SQL Server计数器，严格的来说，它们没有特定的顺序。对于每一个计数器，我将尽可能所描述的是什么，在某些情况下，我也会说说这些计数器的理想值。这样可以参考用于衡量自己的数据库的指标情况。

　　高速缓存命中率计数器，表示SQL Server接受命令查询所需的数据页恰好在高速缓存中的概率，如果在高速缓存中查找不到，则数据页要重新到磁盘或者其它地方获取。这个数值越高，表示SQL Server能够从缓存中获得的数据概率越高，而不是再从磁盘读取。这个数值理论上是越高越好，接近到100.有了这100，100％的时间在SQL Server的内存中找到了需要的数据页，那么性能一直很高。如是是一个很低的数值可能表明内存方面有问题，最有可能是内存不足。

　　页寿命表示页在缓存中存放的时间。页面停留的时间越长在内存中，那么下一次查询时，如果所需的页面还在缓存中，SQL Server将不再需要从磁盘读取。页寿命根据不同的服务器的基值不同，和内存大小有一定的关系，我们应该观察这个计数器，以确定数据库环境中正常基线是什么。有人统计了一下，低于300（或5分钟），说明我们的服务器内存不足。

　　批请求/秒是指SQL Server是每秒接收批处理的数量。这个计数器是可以查看我们的服务器处理速度。数字越大，表明我们的数据库处理查询的吞吐量越大。像许多计数器一样，没有一个单一的数字，可以说明服务器是太忙了。如今的服务器越来越强大，因此可以一刻不停的处理更多批次的请求。随着时间的推移，应该收集这个计数器，以确定我们的服务器环境基准数值是什么。

　　编译/秒 是指SQL Server每秒编译执行计划的次数。编译一个执行计划是资源密集型操作，耗时比较长且申请的资源比较多。汇编/秒应该和批请求/秒同时观察，当两者同时发生时，以获取是否有并发症，对服务器有伤害。要做到这一点，可以使用 请示数/编译数=？来保持一个稳定的数值。理想的情况下，可以为每10批次一个编译的要求。

　　有时因为一些重要的事件发生时，导致执行计划失效，SQL Server将重新编译它。该重编译/秒表示每秒钟重新编译执行计划的次数，和编译一样，都是代价高昂的操作，所以应尽量减少重新编译次数。理想情况下我们要保留这个计数器小于编译/秒（上面第4项）的10% .

　　用户连接计数器是指同一时刻连接到服务器的用户的数量。我们需要观察这个基线用户连接数，不同时间的用户数量是不同的，且有个高低区间。如果此计数器的值下降，并在系统上的负荷是相同的，那么可能有一个瓶颈，导致我们的服务器不能来处理的正常负荷，这个需要检查了。当然也要注意计数器的值下降也可能是因为连接的确少了的原因。

　　为了使SQL Server来管理系统上的并发用户时，SQL Server需要经常锁定资源，有时长有时短暂。锁等待/秒是指每秒针系统等待恰好所申请的资源被锁定的次数。理想情况下我们不希望任何要求等待锁，因此，要保持这个计数器为零或接近零。

　　这个计数器表示：当插入、更新数据时，由于原来的页不够存放了，需要进行分页动作，那么每秒种进行分析的次数，就是该指标，因为拆分时执行性能昂贵，除了IO操作外，还导致表碎片越来越多，表性能低下。因此，减少页拆分将有利于系统高效执行，需要进行合理的设计。理想的情况下，这个计数器应小于批请求/秒（上面第三项）的20% .

　　进程阻塞计数器是指某一时刻进程阻塞的的个数。当一个进程因为申请的资源得不到释放时，这个进程被阻塞了，而其它依赖于同一个资源的进程都不能向前推进，最后导致阻塞的进程越来越多，要解决这个问题唯一的办法是直到其资源释放。理想情况下我们不希望看到任何阻塞的进程，当进程被阻止时应该深入调查。

　　检查点页/秒表示每秒写入到磁盘的确认检查的页数。我们应该根据自己的数据库生成一个基准曲线。一旦建立了基准曲线，我们可以看看它是否还在上升。如果此计数器一直在上升，这有可能是因为内存有问题，导致磁盘和内存的页面交换在频繁的进行。

　　当您怀疑计算机硬件是影响SQL Server运行性能的主要原因时，可以通过SQL Server Performance Monitor监视相应硬件的负载，以证实您的猜测并找出系统瓶颈。下文将介绍一些常用的分析对象及其参数。

Processor:%User Time
　　表示耗费CPU的数据库操作，如排序，执行aggregate functions等。如果该值很高，可考虑增加索引，尽量使用简单的表联接，水平分割大表格等方法来降低该值。

Memory: Page Faults / sec
　　如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。

SQLServer:Cache Hit Ratio
该值越高越好。如果持续低于80%，应考虑增加内存。 注意该参数值是从SQL Server启动后，就一直累加记数，所以运行经过一段时间后，该值将不能反映系统当前值。

Process: Working Set
　　SQL Server的该参数应该非常接近分配给SQL Server的内存值。在SQL Server设定中，如果将"set working set size"置为0, 则Windows NT会决定SQL Server的工作集的大小。如果将"set working set size"置为1，则强制工作集大小为SQLServer的分配内存大小。一般情况下，最好不要改变"set working set size"的缺省值。

Process:%Processor Time
　　如果该参数值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。

Processor:%Privileged Time
　　如果该参数值和"Physical Disk"参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。另外设置Tempdb in RAM，减低"max async IO"，"max lazy writer IO"等措施都会降低该值。

Physical Disk:Avg.Disk Queue Length
　　该值应不超过磁盘数的1.5~2倍。要提高性能，可增加磁盘。
　　注意：一个Raid Disk实际有多个磁盘。