有没有可能在短短几秒内回答这个问题？也许你试图查看性能监视器PerfMon里面的性能计数器。里面有大约1000个名称各异的不同计数器。你可能会问：“Skipped Ghosted Records/sec”（每秒跳过的幻影记录数）= 10，这个数值好还是坏？正确的回答是，这个数值可能并不重要。不过，有些计数器确实很重要。本文将帮助你找出这类计数器，还会教你如何为最常见的性能问题排除故障。
想开始入手，先从下列网址安装SQL Heartbeat工具：
http://www.sqlsolutions.com/downloads/activity-monitor/Download.html
连接到你的服务器后，你会看到服务器树结构中的两个类别：
点击“Online Activity/SQL Heartbeat”节点，你会立即看到五个不同的图表。但是最好点击“Historical Data”（历史数据），等待一两天，等到累积了更准确的衡量指标为止。之后，你该查看图表上的哪些内容呢？首先，你应该关注一下Waits图表：
顺便说一下，你有没有注意到这张图上的周期性模式？比如说，周末期间活动比较少，到了晚上活动增加。为了更全面地了解数据库在正常工作时间段的运行状况，你在分析时可以将这些时段排除在外（特别是由于这些时段可能是进行完全备份的时候）。我们可以排除这类数据，让我们的图表更流畅：
下一步是查看哪个类别最糟糕。如果主色是蓝色或黄色（代表读取或写入），那么你的服务器是磁盘输入/输出密集型的。下面是个示例：
为什么是输入/输出密集型的？点击Physical R/W图表。问题可能出在工作负载上，比如说输入/输出操作次数太多：
非常频繁的输入/输出活动可能是糟糕的高速缓存命中率引起的。你可以点击Cache Hits（高速缓存命中）按钮来证实：
注意：不要使用性能监视器PerfMon所报告的“Cache Hits Ratio”（高速缓存命中率）。PerfMon报告的只是“医院里的平均温度”而已——它是对周末和繁忙时段、夜间索引碎片整理和白天操作求平均值，用的是不同的使用模式。
有时候，“高速缓存命中率”足够好，但是延迟很差。点击Seek Time（寻道时间）按钮来证实：
50毫秒（ms）意味着，服务器每秒只能执行20次输入/输出操作。这样的速度仅仅相当于老式软盘！
有些服务器是处理器密集型的，下面是一台典型的处理器密集型服务器的模样：
一般来说，如果服务器是处理器密集型的，情况并不坏，只要绝对数值不是很高（千万要牢记：Y轴表示服务器每秒使用所有处理器时的处理器毫秒，所以在4个处理器上，每秒使用处理器最多可以有4000毫秒。）但是如果处理使用率的绝对值很高，那么点击Query Stats（查询统计数字）按钮。你会看到按处理器、读取和写入分类的前十大有问题的查询。这些查询很可能是需要优化的对象。
顺便说一下，你每天可以通过电子邮件来获得所有这些报告。只要在SQL Heartbeat中进行配置：点击工具栏中的Reports（报告）按钮。
#p# 现在，其实只剩下了一个次要的方面。你有没有看到上面的红色尖峰？这些是锁。各种各样的锁都很危险。每天一小时的处理器使用时间没什么问题，但是1分钟的锁定时间会导致超时、客户不高兴。死锁更为严重。
为了给锁和死锁排除故障，请从下列网址安装SQL Deadlock Detector：
http://www.sqlsolutions.com/downloads/sql-deadlock-detector/Download.html
连接到同一台服务器，在数据收集了几小时后查看事件列表。
有时候，锁包括几十个进程。从SQL Deadlock Detector里面，你能获得关于参与锁的进程的所有细节：
提供的信息包括锁定表的名称、具体的T-SQL语句以及父存储过程。
小结
你可以迅速确定自己的SQL服务器其运行状况是否良好。实际上，说到处理最常见的性能问题，你只要遵照上述步骤，就能够成为SQL服务器性能方面的专家。
原文链接：http://www.sqlsolutions.com/articles/articles/Become_SQL_performance_Expert_in_few_simple_steps.htm
