用于监控 SQL Server 的基线性能计数器有哪些以及它们的含义是什么？
答案1
以下是我监控的计数器及其原因（有关它们作用的详细说明，请参阅 perfmon 中的“解释”按钮）。请注意，除非您有衡量基准，否则许多计数器都是无用的。您必须在应用程序出现性能问题之前对其进行监控。
处理对象：% 处理器时间 - 如果您有增长，并且此计数器平均为 80%，则是时候升级了。75-80% 的平均值表示服务器已充分利用。持续的峰值（特别是在用户连接数较低的情况下）可能意味着查询编写得不好，或者意味着是时候升级了，最好让某人查看一下代码。
系统对象：处理器队列长度 - 此值应小于系统中 CPU 数量的 2 倍。如果它在增长，并且 CPU 百分比（以上）为 80% 以上，那么您可能需要更多或更快的处理器
内存对象：页数/秒 - 通常，添加内存（或为 SQL 分配更多内存）应该会降低此计数器。此计数器本身并不表示性能问题。此计数器是主观的。值得注意的是，如果随着时间的推移，此计数器上升并且性能下降，那么肯定是时候为 SQL Server 分配更多 RAM 了。作为一条非常普遍的规则，假设 SQL Server 是机箱中唯一的应用程序，则此数字在 24 小时内的平均值为 0（有峰值）。从性能角度来看，低于 20 不应该引起太多注意，超过 20 则可能需要更多 RAM
内存对象：可用兆字节数 - 寻求随时间推移的一致性 - 不是一个神奇的数字，理论上完美的世界应该尽可能接近 0
物理磁盘对象：平均磁盘队列长度 - 一个好的经验法则是不高于主轴数量 X 2，这个数字是主观的
PhysicalDisk Object:% Idle Time - 使用这个 - 100，以便更准确地查看 %disk 时间（这是我的旧笔记，在 Windows 2008 下可能已经修复，但在 Windows 2000 和 Windows 2003 中存在一些问题）如果您正在调整，您会想知道读写比率 - 这只是基本性能
网络接口对象：字节总数/秒 - 您在这里寻找网络问题。如果它异常低（比如在 20% 的范围内）并且您有不错的负载，请查看网络配置，同样，如果它超过 60%，您可能有一个错误配置或网络瓶颈。60% 应该在 3000 批处理请求/秒左右
SQL Server 访问方法对象：每秒完整扫描 - 如果您发现许多 SQL Server 索引未被使用，请找到 SQL 开发人员并带上球棒（使用木制球棒，因为铝制球棒容易凹陷），请注意，这是相对于基线而言的，因为并非所有查询都可以使用索引 - 但绝对值得要求开发人员查看是否有任何可以完成的额外索引
SQL Server 数据库对象：事务/秒 - 使用它来了解服务器的平均利用率，随着性能下降，该值将呈上升趋势（请注意，SQLServer：SQL 统计信息：批处理请求/秒更准确，但我发现 TPS 更有用）
SQL Server 缓冲区管理器对象：缓冲区缓存命中率 - 正如您所猜测的，越高越好，更多的 RAM 应该（但不一定）可以提高这个值
SQL Server 常规统计对象：用户连接 - 更多地用于趋势分析而非实际性能，基于 Java 的应用程序通常会将其提升到 1000，因为它连接到 SQL Server 的方式
SQL Server 锁定对象：平均等待时间 - 同样是主观的，随着时间的推移，表明性能趋势/问题，但是，如果此峰值让开发人员查看该特定报告背后的代码，这对于个别问题（例如，为什么此报告运行得如此缓慢）也非常有用。它可能只是创建了很多锁定，或者可能需要进行调整（所以这次不要管它了）