SQL Server 性能监视器：完整指南 [2026]

打开性能监视器
拓展 数据采集器套件
右键单击 用户自定义
选择 全新发布 -> 数据采集器套件
输入描述性名称（例如，“SQL Server 绩效指标”
选择 手动创建（高级）
点击 下一篇
确保 创建数据日志->性能计数器
点击 下一篇
点击添加选择柜台
添加期望 SQL Server 和系统计数器.
米 采样间隔
- 对于常规监测，使用 1 分钟（60 秒）
- 对于主动故障排除，使用 15-30 秒
- 避免长期运行高频捕获，因为它们会影响性能并生成过多数据。
点击 下一篇
选择保存日志的位置
点击完成，将创建一个新的数据收集器集。
默认情况下，新的数据收集器集将不是会自动启动。您需要在左侧面板中找到它，位于“ 性能 -> 数据采集器套件 -> 用户自定义 -> 您的数据收集器，右键单击它并选择开始

4.3 要添加的关键计数器

内存 -> 可用兆字节
物理磁盘 -> 平均磁盘秒/读取（除 _Total 之外的所有实例）
物理磁盘 -> 平均磁盘秒/写入（除 _Total 之外的所有实例）
物理磁盘 -> 磁盘读取次数/秒（除 _Total 之外的所有实例）
物理磁盘 -> 磁盘写入次数/秒（除 _Total 之外的所有实例）
处理器 -> % 处理器时间（除 _Total 之外的所有实例）
SQLServer：常规统计信息->用户连接
SQLServer：内存管理器->内存授予待定
SQLServer：SQL 统计信息 -> 批量请求/秒
SQLServer：SQL 统计信息 -> SQL 编译次数/秒
SQLServer：SQL 统计信息 -> SQL 重新编译次数/秒
系统 -> 处理器队列长度

4.4 设置停止条件

配置停止条件以防止数据无限增长：

创建数据收集器集后，右键单击它并选择物业
点击 停止条件 标签
启用 总持续时间
将持续时间设置为 1 天（24 小时）
点击 OK 救

这样可以确保日志文件不会变得过大，并按计划自动重启。

4.5 安排数据收集

自动收集数据以确保一致的监控：

右键单击数据收集器集并选择物业
点击 活动行程 标签
点击添加创建新的时间表
配置开始日期和时间
设置重复模式（例如，每天）
点击 OK 保存时间表

要实现自动启动，请通过在 Windows 任务计划程序中创建启动触发器，将数据收集器集配置为在服务器启动时启动。

5. 设置性能监视器 SQL Server（Windows XP/Server 2003 及更早版本）

对于 Windows XP / Server 2003 及更早版本，您可以创建计数器日志，这样您就可以选择一组性能计数器并定期将它们记录到文件中。

5.1 创建计数器日志

请按照以下步骤创建新的计数器日志：

打开性能监视器
拓展 性能日志和警报 在左窗格中
右键单击 计数器日志
选择 新日志设置
使用数据库服务器名称命名日志（例如“ProductionSQL01”）
点击 OK 开始配置

为每个服务器创建单独的计数器日志允许您测试单个服务器的性能，而无需同时收集所有服务器的数据。

5.2 添加性能计数器

创建计数器日志后，添加要监视的特定性能计数器：

点击 添加计数器 按键
更改计算机名称以指向您的 SQL Server 例
媒体中心制表加载可用的性能对象
从下拉菜单中选择一个性能对象（例如，内存)
从中选择特定的计数器列表
如果适用，请选择实例（例如，单个处理器或磁盘）
点击添加包括计数器
对所有需要的计数器重复此操作
点击关闭等结束了

5.3 配置采样间隔

采样间隔决定了性能监视器收集数据的频率。请根据监控需求配置适当的间隔：

在计数器日志属性中，找到 采样数据间隔
设置间隔（默认为15秒）
对于基线监测，每日收集间隔为 1 分钟
为了进行故障排除，请使用 15-30 秒的间隔进行短时间爆发
点击 OK 申请

请记住，较小的间隔会生成更多数据，这会增加渲染和分析的难度。较大的间隔可能会错过重要的峰值。务必平衡数据粒度与存储和分析需求。

5.4 配置日志文件

正确的日志文件配置可确保数据高效且可访问地存储：

点击 日志文件 计数器日志属性中的选项卡
将日志文件类型更改为 文本文件（逗号分隔） 轻松导入 Excel
点击配置
将文件路径设置为专用位置（例如，共享的 PerformanceLogs 文件夹）
点击 OK 确认

使用可通过网络访问的共享来存储日志，以便您可以远程访问文件并与其他用户共享。

5.5 设置凭证

配置适当的凭据，以便性能监视器可以访问远程 SQL Server 实例：

在计数器日志属性中，找到 运行方式
按以下格式输入您的域用户名： 域\用户名
点击 设置密码
输入并确认您的密码
点击 OK 救

这允许 PerfMon 服务使用您的域权限而不是其自己的凭据来收集统计信息。

6.分析性能监视器数据

6.1 在性能监视器中查看日志文件

性能监视器可以显示已保存的日志文件的历史数据：

打开性能监视器
在左侧窗格中，单击 监控工具 -> 性能监视器.
右键单击图形区域的任意位置
选择物业
点击来源标签
选择 日志文件 单选按钮
点击添加
导航到您的日志文件（.blg 或 .csv）
选择文件，然后单击可选
使用 时间范围 滑块选择要分析的时间段
点击 OK 关闭“属性”对话框
单击绿色加号图标从日志文件添加计数器
选择要显示的计数器
点击 OK

图表现在将显示日志文件中的历史数据。使用“属性”中的“时间范围”滑块可以缩小特定时间段以进行详细分析。

6.2 将数据导出到 Excel

Excel 为性能计数器数据提供了强大的分析功能：

打开性能监视器并加载日志文件
右键单击图形区域的任意位置
选择 数据另存为
选择文件的位置
选择 文本文件（逗号分隔）（.csv） 从下拉菜单
点击 已保存
在 Excel 中打开 CSV 文件

格式化导出的数据以便更好地进行分析：

删除半空的第 2 行并清除单元格 A1
将 A 列格式化为日期/时间
使用零小数和千位分隔符格式化数字列
查找并替换标题中的服务器名称（例如，将“\\SERVERNAME”替换为空白）
清理标题中的对象名称（例如“内存”、“物理磁盘”、“处理器”）
将标题字体大小减小至 8 点，以提高可见性

6.3 解释计数器值

6.3.1 内存计数器分析

分析内存计数器时，请查找以下指标：

可用兆字节： 应始终保持在 4096 MB 以上
页面预期寿命： 300 秒以上的值表示内存健康。较低的值表示内存压力
缓冲区缓存命中率： 应达到或超过 99%。较低的值表示磁盘读取过多
内存授权待定： 应该始终为 0。任何正值都表示内存不足。

6.3.2 CPU计数器分析

CPU性能指标包括：

处理器时间百分比： 持续使用率超过 75% 表示存在性能问题。峰值达到 100% 是正常现象，但不应持续存在
处理器队列长度： 大于 1 的值表示 CPU 压力较大。检查任务管理器以确定哪些进程占用了 CPU
特权时间百分比： 应保持在 5-10% 之间。高于 25% 的值表明 I/O 操作过多

6.3.3 磁盘计数器分析

磁盘性能阈值：

平均磁盘秒数/读取和写入： 应保持在 10-20 毫秒以下。值越高，表示磁盘子系统越慢
磁盘队列长度： 值持续高于 2（或 RAID 中每个磁盘 2）表示存在 I/O 瓶颈
磁盘时间百分比： 持续高于 85% 的值表示磁盘饱和

6.4 使用公式和统计数据

向 Excel 添加统计公式以便快速分析：

在电子表格顶部插入 7 个空白行
在 A 列中添加标签：平均值、中位数、最小值、最大值、标准差
在单元格 B2 中，输入：=AVERAGE(B9:B100)（将 B100 调整为最后一个数据行）
在单元格 B3 中输入：=MEDIAN(B9:B100)
在单元格 B4 中输入：=MIN(B9:B100)
在单元格 B5 中输入：=MAX(B9:B100)
在单元格 B6 中输入：=STDEV(B9:B100)
在所有计数器列中复制公式
选择单元格 B9 并按 Alt+W+F+Enter 冻结窗格

这些统计数据有助于识别每个计数器的趋势、异常值和正常操作范围。

7. 日志性能分析（PAL）工具

7.1 PAL 简介

日志性能分析 (PAL) 是一款由 Clint Huffman 开发的免费工具，用于分析性能监视器日志并生成包含阈值分析的 HTML 报告。PAL 会将您的性能数据与已知阈值进行比较，并提供详细的建议，以帮助您 SQL Server 性能优化。

从 GitHub 存储库下载 PAL： https://github.com/clinthuffman/PAL

7.2 设置 PAL

按照以下步骤安装 PAL：

从 GitHub 下载 PAL 安装文件
运行安装程序
点击 下一篇 在欢迎屏幕上
查看并接受安装目录
点击 下一篇 继续
点击安装开始安装
等待安装完成
点击完成

7.3 使用 PAL 处理日志文件

使用 PAL 分析性能监视器日志：

从“开始”菜单或安装目录启动 PAL
点击 计数器日志 标签
点击浏览选择你的 .blg 文件
导航到您的性能监视器日志文件
点击可选
点击 阈值文件 标签
从下拉菜单中选择一个阈值文件（例如，“SQL Server 2016”）
点击 常见问题 标签
回答有关系统配置的问题
请指定您的 SQL Server 是 OLTP 还是数据仓库
输入可用的总 RAM
点击 输出选项 标签
选择 HTML 报告的输出目录
确保 HTML 输出格式
点击 演练： 标签
检查您的选择
确保 立即开始执行
点击完成

7.4 分析 PAL 报告

PAL 完成分析后，会生成一份 HTML 报告，其中包含：

绩效问题执行摘要
带有图表的详细计数器分析
阈值违规以颜色突出显示
针对每个问题的具体建议
历史趋势和模式

该报告使用颜色编码来指示严重程度：红色表示严重问题，黄色表示警告，绿色表示指标正常。查看每个部分以了解性能瓶颈，并遵循 PAL 的优化建议。

8.替代 SQL Server 监控工具

8.1 内置 SQL Server 工具

8.1.1 SQL Server 活动监视器

SQL Server 活动监视器显示关于以下方面的实时信息 SQL Server 流程和性能：

可选 SQL Server Management Studio（SSMS）并连接到您的服务器实例
在对象资源管理器中右键单击服务器名称
选择 活动监视器

活动监视器显示进程、资源等待、数据文件 I/O 以及近期开销较大的查询。它提供对当前数据库活动的快速洞察，但不存储历史数据。

8.1.2 SQL Server 绩效仪表板

SQL Server Management Studio 包括内置性能报告：

In SQL Server Management Studio（SSMS），右键单击 SQL Server 对象资源管理器中的实例
选择报告 -> 标准报告
从可用的报告中选择，例如 绩效仪表板

性能仪表盘提供了以下方面的视觉洞察 SQL Server 实例性能，包括系统 CPU 利用率、当前等待的请求以及性能指标。您可以通过“标准报告”菜单访问它。

8.1.3 SQL Server 探查

SQL Server 探查捕获和分析 SQL Server 查询执行、事务操作和登录活动等事件。

要启动 SQL Server 分析器：

In SQL Server Management Studio 中，单击工具 -> SQL Server 探查

分析器会造成显著的性能开销，因此请谨慎使用，最好在非高峰时段使用。在大多数情况下，扩展事件可以提供更好的性能，且性能影响更小。

8.1.4 扩展事件

扩展活动是一个内置的轻量级性能监控系统 SQL Server。取代 SQL Server 具有更好性能和更低开销的分析器。

主要功能包括：

对特定事件进行细粒度监控
最小的性能影响
可定制的活动会话
与 SSMS 和其他工具集成
支持复杂的过滤和聚合

通过 SSMS 创建扩展事件会话：

In 对象资源管理器，展开你的服务器并转到 管理 -> 扩展事件 -> 会话
用鼠标右键单击会议并选择 新建会话向导
按照说明开始新的会话。

8.1.5 动态管理视图（DMV）

DMV 公开了详细的服务器状态信息，用于监控服务器运行状况、诊断问题和调整性能。关键的 DMV 包括：

sys.dm_exec_query_stats： 查询性能统计
sys.dm_os_wait_stats： 影响服务器性能的等待类型
sys.dm_os_performance_counters： SQL Server 性能计数器数据
sys.dm_exec_requests： 当前正在执行请求
sys.dm_exec_sessions： 活跃用户会话

使用 T-SQL 查询这些视图以访问实时性能数据和历史指标。

基本用法

-- See all active connections
SELECT * FROM sys.dm_exec_connections;

-- View current sessions
SELECT * FROM sys.dm_exec_sessions;

-- Check database file stats
SELECT * FROM sys.dm_io_virtual_file_stats(NULL, NULL);

8.2 第三方监控解决方案

龙门SQL监控器

Redgate SQL Monitor 专注于监控 SQL Server 和 Azure SQL 数据库环境。它提供全屋监控、可定制的警报和仪表板、详细的报告功能以及与其他 Redgate 工具的集成。

SolarWinds的 SQL Server 监控工具

太阳风 SQL Server 监控工具，也称为 SQL Sentry，旨在诊断、解决和预防严重的性能问题 SQL Server.

伊德拉的 SQL Server 性能监控工具

IDERA SQL Diagnostic Manager 是一款功能强大的产品。 SQL Server 性能监控工具，旨在协助进行主动性能监控、诊断和调优。

应用程序管理器的 SQL 监控

应用程序管理器提供了 Microsoft SQL Server 提供有用 IT 解决方案的监控工具。它旨在监督 SQL 数据库的性能，同时识别错误并解决可能导致组织运营停止的问题。

8.3 开源监控工具

DBA 冲刺

DBA Dash 是一款免费的开源监控工具，可以洞察 SQL Server 健康状况、性能和活动。它特别适用于中小型环境，包括每日 DBA 检查、性能监控和配置跟踪。

SQL监视

SQLWATCH 提供去中心化、近乎实时的 SQL Server 以 5 秒为粒度的监控，用于捕获工作负载峰值。它支持使用 Grafana 进行实时仪表板，并使用 Power BI 进行深入分析。该工具提供丰富的配置选项、零维护要求和无限的可扩展性。

操作服务器

Opserver 由 Stack Exchange 开发，可监控多个系统，包括 SQL Server、Redis 和 Elasticsearch。它提供了整个基础架构中 CPU、内存、网络和硬件统计信息的“所有服务器”视图。

sp_WhoIsActive

sp_WhoIsActive 是一个全面的活动监控存储过程，由 Adam Machanic 创建。它适用于所有 SQL Server 从 2005 年到当前版本，被广泛使用 SQL Server 用于实时活动监控的 DBA。

要使用 sp_WhoIsActive，请从 http://whoisactive.com/ 下载，将其安装在数据库中，然后执行：

EXEC sp_WhoIsActive

该过程显示当前正在执行的查询、等待信息、阻塞详细信息和资源消耗。

9. 最佳实践 SQL Server 性能监视器

9.1 建立性能基线

性能基准为您的 SQL Server 环境。没有基线，您就无法确定当前指标是否表明存在问题或代表典型行为。

通过以下方式创建基线：

收集正常运行期间至少一周的性能数据
在高峰时段和非高峰时段捕获指标
记录关键计数器的典型值
如适用，记录季节性变化
存储基线数据以便与未来指标进行比较

每季度或在重大基础设施变更、应用程序更新或数据库修改后更新基线。

9.2 设置适当的警报阈值

配置智能阈值以接收有意义的警报，而不会让自己被通知淹没：

Memory Grants Pending > 0 表示内存压力
处理器队列长度 > 每个核心 2 表明存在 CPU 瓶颈
磁盘秒/读取或写入> 20ms 表示 I/O 速度慢
阻塞进程 > 5 表示争用问题
页面寿命预期 < 300 秒表示内存压力

根据基线数据和特定工作负载特征调整阈值。使用能够反映环境中正常变化的自适应阈值。

9.3 定期数据审查和分析

安排定期绩效评估以确定趋势和新出现的问题：

每日：查看高级指标和最新警报
每周：深入分析绩效趋势
每月：生成综合报告并与基线进行比较
季度：审查产能规划和长期趋势

记录调查结果并跟踪一段时间内的性能改进。

9.4 平衡监控开销

监控本身会消耗资源，因此需要在数据收集和性能影响之间取得平衡：

使用 30-60 秒间隔进行连续监测
仅使用 15 秒间隔进行主动故障排除
限制数据收集器设置持续时间以避免数据过多
将日志存储在与数据库文件不同的驱动器上
归档旧的性能数据以保持可管理的文件大小

如果配置正确，性能监视器会增加最小的开销，通常低于系统资源的 2%。

9.5 长期数据保留

保留性能数据以进行有意义的趋势分析和容量规划：

保留至少1-2年的性能数据
3-6 个月后将数据归档到单独的存储中
压缩旧日志文件以节省空间
记录影响性能的任何重大事件或变化

鉴于性能计数器数据相对较小，无限期地保留它通常是可行的，并且对于长期分析很有价值。

9.6 与 DevOps 实践相结合

将数据库性能监控纳入 CI/CD 管道：

在部署验证中包括数据库性能指标
自动执行新版本的性能测试
验证代码更改不会对性能产生负面影响
为每个版本创建性能基准
将监控警报与事件管理系统集成

10. 常见性能问题故障排除

10.1 识别 CPU 瓶颈

CPU 瓶颈表现为查询响应时间慢和处理器利用率高。请使用以下步骤诊断 CPU 问题：

检查“处理器队列长度”计数器。如果每个核心的值超过 2，则表示 CPU 压力较大
检查处理器时间百分比。持续超过 75% 的值表明存在 CPU 瓶颈
远程桌面到 SQL Server
打开任务管理器（Ctrl+Shift+Esc）
点击 加工流程 标签
确保 显示所有用户的流程
点击 中央处理器 按 CPU 使用率排序的列标题
确定哪些进程消耗 CPU 资源

如果非SQL Server 应用程序占用大量 CPU，请将其从数据库服务器中移除。如果 sqlservr.exe 占用 CPU 过多，请使用以下方法进行调查：

检查 SQL 编译次数/秒和 SQL 重新编译次数/秒。如果值高于批量请求次数/秒的 10%，则表示编译次数过多
查询 sys.dm_exec_query_stats 来识别 CPU 密集型查询
审查执行计划中是否存在缺失索引或低效操作
考虑添加索引以减少表扫描

10.2 诊断内存问题

内存问题会严重影响 SQL Server 性能。使用以下指标诊断内存问题：

可用内存下降

如果可用内存持续低于 100 MB，操作系统将面临内存不足的问题。Windows 可能会将内存换出。 SQL Server 内存到磁盘，导致性能下降。

页面寿命低

页面预期寿命低于 300 秒表示缓冲区缓存周转率较高。这意味着内存分配不足或查询带来的内存压力过大。

低缓冲区缓存命中率

缓冲区缓存命中率低于 99% 意味着 SQL Server 频繁地从磁盘而不是内存读取数据。当缓冲池太小或 SQL Server 重启后仍在预热。

内存授予待定

如果“内存授予待处理”值大于 0，则表示查询正在等待内存授予。这表示内存严重短缺，需要立即处理。

要解决内存问题：

配置 SQL Server 最大内存设置，为操作系统留出足够的 RAM（通常为 4-8 GB，具体取决于服务器大小）
启用“锁定内存页面”权限 SQL Server 服务帐号
如果内存压力持续存在，请向服务器添加更多物理 RAM
识别并优化内存密集型查询

10.3 解决磁盘 I/O 问题

磁盘 I/O 经常成为数据库系统的主要性能瓶颈。请使用以下方法诊断磁盘问题：

磁盘队列长度过长

磁盘队列长度持续高于 2（对于 RAID，每个磁盘为 2）表示磁盘子系统无法跟上 I/O 请求。这会导致待处理操作积压。

磁盘延迟过高

平均磁盘读取（秒/读取）和平均磁盘写入（秒/写入）值高于 10-20 毫秒表示磁盘响应缓慢。事务日志驱动器需要特别快的性能，理想情况下写入时间应低于 5 毫秒。

磁盘时间百分比高

磁盘使用率持续高于 85% 表示磁盘已饱和。磁盘大部分时间都用于处理 I/O 请求，几乎没有剩余容量。

在解决磁盘问题之前，请先确认它们不是内存问题的症状。内存不足 SQL Server 从磁盘读取更多数据，人为地增加磁盘指标。

要解决真正的磁盘 I/O 问题：

升级到更快的磁盘（SSD 而不是 HDD）
实施 RAID 配置以获得更好的性能
将数据库文件、事务日志和 tempdb 分离到不同的物理驱动器上
添加更多内存以减少磁盘读取
优化索引以减少不必要的 I/O
审查并优化性能不佳的查询

10.4 解决阻塞和死锁

当一个会话持有的锁阻止其他会话继续进行时，就会发生阻塞。监控以下计数器以识别阻塞问题：

进程被阻止： 理想情况下应为 0
锁定等待数/秒： 需要等待的锁请求数
平均等待时间： 锁等待的平均持续时间

要调查阻塞情况：

在 SSMS 中打开活动监视器
展开 加工流程 部分
寻找非零的进程 被阻止 价值观
识别阻塞会话 ID
查看导致阻塞的查询

使用 sp_WhoIsActive 进行更详细的阻塞分析。过多的 wait_info 条目通常表示 tempdb 存在争用或阻塞问题。

为了减少阻塞：

最小化交易持续时间
使用适当的隔离级别
添加索引以减少锁定持续时间
考虑 READ_COMMITTED_SNAPSHOT 隔离
审查并优化长时间运行的查询

10.5 查询性能问题

识别开销昂贵的查询对于 SQL 性能监控至关重要。请使用以下方法查找有问题的查询：

使用活动监视器

在 SSMS 中，右键单击服务器名称
选择 活动监视器
拓展 近期昂贵的查询
审查具有高 CPU、持续时间或逻辑读取的查询

使用DMV

查询 sys.dm_exec_query_stats 以识别资源密集型查询：

SELECT TOP 50
    total_worker_time/execution_count AS avg_cpu_time,
    total_logical_reads/execution_count AS avg_logical_reads,
    execution_count,
    SUBSTRING(qt.text, (qs.statement_start_offset/2)+1,
        ((CASE qs.statement_end_offset
            WHEN -1 THEN DATALENGTH(qt.text)
            ELSE qs.statement_end_offset
        END - qs.statement_start_offset)/2) + 1) AS query_text
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
ORDER BY total_worker_time DESC

分析执行计划

在 SSMS 中，打开一个新的查询窗口
点击 显示预计执行计划 （Ctrl+L）或 包括实际执行计划 （Ctrl+M）
执行查询
审查昂贵操作的执行计划
查找表扫描、索引扫描或高成本操作。

通过以下方式优化查询：

添加适当的索引
重写查询以避免昂贵的操作
更新统计数据
使用特定的列名而不是 SELECT *
避免不必要的 DISTINCT 或 ORDER BY 子句

10.6 检测并修复损坏的数据库

数据库损坏会导致性能下降、数据丢失和系统故障。快速检测和修复损坏对于维护数据库健康至关重要。

数据库损坏指标

注意以下潜在腐败迹象：

错误消息 SQL Server 错误日志（错误 823、824 或 825）
访问特定表时出现意外的应用程序错误
之前快速的查询性能变慢
SQL Server 崩溃或意外重启
msdb.dbo.suspect_pages 表中出现的可疑页面

使用 DBCC CHECKDB 进行检测

DBCC 检查数据库是检测数据库损坏的主要工具。定期运行它可及早发现问题。

监控可疑页面

SQL Server 自动在 msdb 数据库中记录可疑页面：

SELECT 
    database_id,
    file_id,
    page_id,
    event_type,
    error_count,
    last_update_date
FROM msdb.dbo.suspect_pages
WHERE event_type IN (1,2,3)

返回的任何行都表明存在需要立即关注的损坏问题。

预防腐败策略

使用 CHECKSUM 选项启用页面验证
维护定期数据库备份
使用具有纠错功能的可靠硬件
使用制造商工具监控磁盘健康状况
安排定期运行 DBCC CHECKDB
保持 SQL Server 已更新最新补丁

恢复和修复选项

如果检测到损坏，您可以尝试内置工具 DBCC 检查数据库修复它们。如果失败，请使用第三方工具，例如 DataNumen SQL Recovery 可以处理严重的腐败问题。

11. 先进的监控技术

11.1 查询存储监控

查询存储，于 SQL Server 2016，自动捕获查询性能数据。它提供有关查询行为、执行计划和性能趋势的宝贵见解。

启用查询存储

在 SSMS 对象资源管理器中，右键单击数据库
选择物业
点击 查询存储 页
In 操作模式（请求），选择读写
根据需要配置其他设置
点击 OK

监控查询性能

通过对象资源管理器访问查询存储报告：

在对象资源管理器中展开数据库
拓展 查询存储
从可用报告中选择：
- 回归查询
- 总体资源消耗
- 资源消耗最高的查询
- 强制计划查询
- 跟踪查询

计划回归检测

查询存储会自动检测查询执行计划何时发生变化以及性能何时下降。查看“回归查询”报告，以确定受计划更改影响的查询。

强制计划管理

当查询存储识别出更好的执行计划时，强制 SQL Server 使用它：

在查询存储中打开查询
右键单击所需的计划
选择 强制计划

这可以立即提高性能，而无需更改代码。

11.2 指数维护监控

索引碎片会随着时间的推移降低查询性能。请定期监控和维护索引，以确保最佳性能。

碎片检查

使用此查询检查索引碎片：

SELECT 
    OBJECT_NAME(i.object_id) AS table_name,
    i.name AS index_name,
    ps.avg_fragmentation_in_percent,
    ps.page_count
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'SAMPLED') ps
INNER JOIN sys.indexes i ON ps.object_id = i.object_id 
    AND ps.index_id = i.index_id
WHERE ps.avg_fragmentation_in_percent > 10
    AND ps.page_count > 1000
ORDER BY ps.avg_fragmentation_in_percent DESC

请在非高峰时段运行此查询，因为它可能会占用大量资源。

页面密度分析

页面密度表示索引页的填充程度。低密度会浪费空间并降低性能：

SELECT 
    OBJECT_NAME(i.object_id) AS table_name,
    i.name AS index_name,
    ps.avg_page_space_used_in_percent
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'SAMPLED') ps
INNER JOIN sys.indexes i ON ps.object_id = i.object_id 
    AND ps.index_id = i.index_id
WHERE ps.avg_page_space_used_in_percent < 75

重组与重建决策

根据碎片级别选择索引维护操作：

碎片化 10-30%：使用 ALTER INDEX REORGANIZE
碎片化 > 30%：使用 ALTER INDEX REBUILD
碎片化率 < 10%：无需采取行动

重组操作所需的资源较少，并且可以在线运行。重建操作更为彻底，但会消耗大量资源。

11.3 数据库统计更新

数据库统计帮助 SQL Server的查询优化器可以创建高效的执行计划。过时的统计数据会导致查询性能不佳。

自动统计重建

启用自动统计更新：

ALTER DATABASE DatabaseName SET AUTO_UPDATE_STATISTICS ON
ALTER DATABASE DatabaseName SET AUTO_CREATE_STATISTICS ON

监控统计健康

检查统计数据的最后更新时间：

SELECT 
    OBJECT_NAME(s.object_id) AS TableName,
    s.name AS StatisticsName,
    STATS_DATE(s.object_id, s.stats_id) AS LastUpdated,
    sp.rows,
    sp.modification_counter
FROM sys.stats s
CROSS APPLY sys.dm_db_stats_properties(s.object_id, s.stats_id) sp
WHERE STATS_DATE(s.object_id, s.stats_id) < DATEADD(DAY, -7, GETDATE())
ORDER BY LastUpdated

需要时手动更新统计数据：

UPDATE STATISTICS TableName WITH FULLSCAN

11.4 收集自定义性能数据

通过直接查询 sys.dm_os_performance_counters 并将结果存储在表中来创建自定义性能监控解决方案。

创建自定义收集脚本

构建一个存储过程来收集性能计数器数据：

CREATE PROCEDURE dbo.CollectPerformanceCounters
AS
BEGIN
    INSERT INTO dbo.PerformanceHistory (
        SampleTime,
        CounterName,
        CounterValue
    )
    SELECT 
        GETDATE(),
        counter_name,
        cntr_value
    FROM sys.dm_os_performance_counters
    WHERE counter_name IN (
        'Page life expectancy',
        'Batch Requests/sec',
        'Buffer cache hit ratio'
    )
END

使用 sys.dm_os_performance_counters

直接查询性能计数器：

SELECT 
    object_name,
    counter_name,
    instance_name,
    cntr_value,
    cntr_type
FROM sys.dm_os_performance_counters
WHERE object_name LIKE '%Buffer Manager%'
ORDER BY counter_name

存储历史数据

创建一个表来存储一段时间内的性能指标：

CREATE TABLE dbo.PerformanceHistory (
    ID INT IDENTITY PRIMARY KEY,
    SampleTime DATETIME2 NOT NULL,
    PageLifeExpectancy BIGINT,
    BatchRequestsPerSec DECIMAL(18,4),
    BufferCacheHitRatio DECIMAL(5,2)
)

CREATE CLUSTERED COLUMNSTORE INDEX CCI_PerformanceHistory 
ON dbo.PerformanceHistory

数据透视表的存储方法

以数据透视格式存储数据，每个采样时间一行，每个计数器一列。与每个计数器每个样本存储一行相比，这可以减少存储空间并提高查询性能。

11.5 多服务器监控

对于具有多个环境 SQL Server 实例，实施集中监控。

集中监控方法

在单独的服务器上创建专用监控数据库
将所有服务器的数据收集到中央存储库
绝大部分储备使用 SQL Server 运行收集脚本的代理作业
实现网络可访问的性能计数器收集

远程服务器监控

通过在添加计数器时指定服务器名称，配置性能监视器以从远程服务器收集数据。确保防火墙规则允许性能监视器流量。

跨服务器报告

构建报告来比较多台服务器的性能，以识别异常值和容量不平衡。

12。监控 SQL Server 在云环境中

12.1 Azure SQL 数据库监控

Azure SQL 数据库提供与本地不同的内置监控功能 SQL Server.

Azure Monitor 集成

Azure Monitor 自动从 Azure SQL 数据库收集指标，包括：

DTU 或 vCore 利用率
存储使用率
连接统计
死锁和超时

通过 Azure 门户或 Azure Monitor API 访问这些指标。

内置监控功能

Azure SQL 数据库包括：

自动调整建议
查询性能洞察
用于异常检测的智能洞察
内置警报和诊断功能

查询性能洞察

此功能提供资源消耗最高的查询、查询持续时间分析和历史性能趋势的可视化。通过 SQL 数据库资源下的 Azure 门户访问它。

12.2 云原生监控工具

云平台提供针对其环境优化的本机监控解决方案：

适用于 Azure SQL 数据库的 Azure Monitor 和 Application Insights
适用于 RDS 的 AWS CloudWatch SQL Server
适用于云的 Google Cloud 监控 SQL Server

这些工具与云基础设施无缝集成，并为所有云资源提供统一监控。

混合环境监控

对于跨本地和云的混合部署，请使用支持两种环境的工具，如 Redgate SQL Monitor、SolarWinds DPA 或使用集中数据收集的自定义解决方案。

12.3 云端的性能差异

云端 SQL Server 环境具有独特的特征：

资源分配模型

云提供商使用不同的资源分配方法（DTU、vCore、无服务器），这些方法会影响您解读性能指标的方式。了解您的服务层级的限制和特性。

扩展注意事项

云环境提供动态扩展功能。监控资源利用率，以确定何时进行扩展或缩减。许多云平台提供基于性能阈值的自动扩展功能。

13.自动化性能监控

13.1 SQL Server 代理工作

使用以下方式自动收集数据 SQL Server 代理作业可进行持续监控，无需人工干预。

定期数据收集

在 SSMS 中，展开 SQL Server 经纪人
右键单击 工作机会 并选择 新工作
命名作业（例如“收集绩效指标”）
点击步骤并添加一个新步骤
将类型设置为 Transact-SQL 脚本
输入您的数据收集脚本
点击附表并添加时间表
配置频率（例如每 5 分钟）
点击 OK 创造就业机会

自动报告

创建生成并通过电子邮件发送绩效报告的作业：

创建生成报告的存储过程
使用数据库邮件通过电子邮件发送报告
安排作业每天或每周运行

13.2 PowerShell自动化

PowerShell 提供了强大的自动化功能 SQL Server 性能监视器。

性能计数器收集脚本

$counters = @(
    '\Processor(_Total)\% Processor Time',
    '\Memory\Available MBytes',
    '\PhysicalDisk(_Total)\Avg. Disk sec/Read'
)

$data = Get-Counter -Counter $counters -ComputerName 'SQLServer01'
$data.CounterSamples | Export-Csv 'C:\PerfLogs\counters.csv' -Append

WMI 查询

使用 WMI 从远程服务器收集性能数据：

$cpu = Get-WmiObject Win32_Processor -ComputerName 'SQLServer01'
$memory = Get-WmiObject Win32_OperatingSystem -ComputerName 'SQLServer01'

Write-Host "CPU Usage: $($cpu.LoadPercentage)%"
Write-Host "Available Memory: $([math]::Round($memory.FreePhysicalMemory/1MB,2)) GB"

自动警报

创建 PowerShell 脚本来检查指标并在超出阈值时发送警报：

$cpuThreshold = 80
$cpu = (Get-Counter '\Processor(_Total)\% Processor Time').CounterSamples.CookedValue

if ($cpu -gt $cpuThreshold) {
    Send-MailMessage -To 'dba@company.com' -Subject 'High CPU Alert' `
        -Body "CPU usage is $cpu%" -SmtpServer 'smtp.company.com'
}

13.3 创建监控仪表板

使用交互式仪表板可视化性能数据以获得更好的洞察力。

Power BI 集成

将 Power BI 连接到您的性能数据表
为关键指标创建可视化效果
添加时间范围和服务器选择的切片器
将仪表板发布到 Power BI 服务
配置自动刷新计划

实时仪表板创建

使用 Grafana 等工具或自定义 Web 应用程序来创建直接查询 DMV 和性能计数器的实时仪表板。

历史趋势可视化

构建折线图来显示以下随时间变化的趋势：

CPU利用率
内存使用情况
磁盘I / O
查询性能
连接计数

14.案例研究和实例

14.1 案例研究：解决内存压力

症状识别

一个制作 SQL Server 高峰时段查询响应缓慢。用户抱怨应用程序超时和性能下降。

反分析

性能监视器数据显示：

页面寿命预期下降到 50 秒（正常：>300）
缓冲区缓存命中率下降至 85%（正常：>99%）
内存授予待定值经常显示 5-10
物理磁盘读取次数/秒大幅飙升

解决步骤

检查 SQL Server 最大内存设置——发现它被设置为默认值（无限制）
对比服务器总内存与目标服务器内存——结果显示存在显著差距
配置最大服务器内存，为操作系统保留 8 GB
启用“锁定内存页面”权限 SQL Server 服务帐号
为服务器添加了 32 GB 的额外 RAM
监控一周的性能——页面预期寿命稳定在500秒以上

结果： 查询响应时间提高了 60%，用户投诉停止，应用程序性能恢复正常。

14.2 案例研究：CPU性能优化

症状识别

A SQL Server 在工作时间内 CPU 利用率持续超过 90%，导致应用程序性能缓慢和用户沮丧。

反分析

绩效监测显示：

处理器时间百分比平均为 92%，经常达到 100%
处理器队列长度始终高于 4（服务器有 8 个核心）
SQL 编译/秒是批量请求/秒的 25%（应该小于 10%）
SQL 重新编译/秒是批处理请求/秒的 15%

解决步骤

使用 DMV 识别最耗 CPU 的查询
分析已识别查询的执行计划
发现由于缺少索引而导致大表上的多次表扫描
根据执行计划建议创建适当的索引
已识别导致过度编译的动态 SQL
修改应用程序代码以使用参数化查询
针对有问题的存储过程实施计划指南
更新了频繁使用的表的统计数据

结果： 工作时间内 CPU 利用率平均下降至 45%。查询执行时间缩短了 70%。应用程序响应速度显著提升。

14.3 案例研究：磁盘 I/O 瓶颈解决

症状识别

用户报告称，在数据加载操作和晚间批处理期间，应用程序响应极其缓慢。

反分析

业绩数据显示：

事务日志驱动器上的平均磁盘秒数/写入时间超过 45 毫秒
数据文件驱动器上的磁盘队列长度平均为 12
批处理作业期间磁盘时间百分比持续数小时高于 95%
页面写入/秒非常高

解决步骤

已验证内存设置是否合适 - 未发现内存问题
分析磁盘配置——发现同一主轴组上的所有文件
将事务日志分离到专用的快速 SSD 驱动器
将 tempdb 移动到单独的 SSD 驱动器
实现了多个 tempdb 数据文件（每个核心一个）
将数据文件驱动器升级到 RAID 10 SSD 配置
优化批处理作业以使用较小的事务批次
添加索引以减少批量操作期间不必要的表扫描

结果： 平均磁盘秒/写入时间降至 3 毫秒。磁盘队列长度平均低于 1。批处理作业完成时间缩短了 75%。

15. 未来趋势 SQL Server 监控

15.1 人工智能与机器学习集成

人工智能和机器学习正在改变 SQL Server 性能监视器。

预测分析

机器学习模型根据历史数据预测未来的资源需求。这些系统可以预测：

当存储容量即将耗尽时
高峰期预计的 CPU 和内存需求
在影响用户之前查询性能下降
维护操作的最佳时间

异常检测

人工智能驱动的工具可以自动检测性能指标中的异常模式。它们可以识别人类管理员可能忽略的异常，并区分正常变化和真正的问题。

自动修复

自我修复系统会在检测到以下问题时自动解决：

重启已停止的服务
在高峰负载期间重新分配资源
应用已知问题的修补程序
自动重建碎片索引

15.2 基于云的监控演进

云监控不断发展，具有新的功能。

统一监控平台

现代平台提供单一窗口可视性：

本地 SQL Server 实例
云托管数据库
混合环境
应用性能
基础设施指标

可观察性趋势

从监控到可观察性的转变强调：

从输出理解系统行为
关联指标、日志和跟踪
深入洞察分布式系统
实时问题诊断

15.3 自我修复数据库系统

未来 SQL Server 版本将包括更多的自主能力。

自动优化

数据库将通过以下方式不断优化自身：

根据工作负载自动创建和删除索引
调整配置设置以获得最佳性能
透明地重写低效查询
动态管理资源分配

智能调优

先进的系统将从性能模式中学习并自动应用调整建议，从而减少对 DBA 手动干预的需要。

16. 结论和要点

16.1 基本监测实践总结

有效 SQL Server 性能监视器需要结合工具、技术和最佳实践的综合方法。

关键反击回顾

将监控重点放在以下重要指标上：

内存：页面预期寿命、缓冲区缓存命中率、待决内存授予
CPU：处理器时间百分比、处理器队列长度
磁盘：平均磁盘秒/读取和写入、磁盘队列长度
SQL Server：批量请求/秒、编译/秒、用户连接

最佳实践摘要

在正常运营期间建立基线
根据基线设置智能警报阈值
定期审查绩效数据
平衡监控开销和数据粒度
保留长期数据以进行趋势分析
针对每个监控场景使用适当的工具

16.2 持续改进方法

SQL Server 绩效监控不是一次性活动，而是一个需要不断改进的持续过程。

定期审查周期

每日：检查警报和当前表现
每周：回顾趋势并发现新出现的问题
每月：分析长期模式和容量需求
每季度：更新基线并审查监测有效性

掌握最新工具

保持监控工具和技术保持最新：

评估新的监控功能 SQL Server 更新
测试新兴的第三方工具
参加培训和会议
参与在 SQL Server 社区论坛
与团队成员分享知识

16.3 后续步骤

实施 SQL Server 系统地监控性能：

实施路线图

第1周： 使用必要的计数器设置性能监视器
第2周： 创建数据收集器集以进行自动收集
第3周： 在正常运营期间建立基线
第4周： 配置关键阈值警报
月2： 实施额外的监控工具（DMV、扩展事件）
月3： 开发自定义仪表板和报告
持续： 根据经验和不断变化的需求完善监控

更多资讯

继续学习有关 SQL Server 通过 Microsoft 文档、社区博客和实践操作来监控性能。尝试不同的工具和技术，找到最适合您环境的方法。

17. 常见问题 (FAQ)

17.1 最重要的是什么 SQL Server 要监控的性能计数器？

最关键的 SQL Server 性能计数器包括：

内存：页面预期寿命（应> 300 秒）和缓冲区缓存命中率（应> 99％）
CPU：处理器时间百分比（持续值 <75%）和处理器队列长度（每个核心应 <2）
磁盘：平均磁盘秒/读取和写入（应<10-20ms）和磁盘队列长度（每个磁盘应<2）
SQL Server：批处理请求/秒、SQL 编译/秒和待处理的内存授予（应为 0）

这些计数器提供对系统健康状况的全面洞察并帮助快速识别瓶颈。

17.2 我应该多久收集一次性能数据？

收集频率取决于您的监控目标：

基线监测：每1分钟（60秒）一次
主动故障排除：每 15-30 秒短时间
长期趋势：每 5 分钟

避免连续运行高频收集，因为这会影响性能并生成过多数据。常规监控应使用较长的间隔，仅在调查特定问题时使用较短的间隔。

17.3 性能监视器和 SQL Server 分析器？

性能监视器和 SQL Server 分析器有不同的用途：

性能监视器：

监控系统和 SQL Server 性能计数器
跟踪资源利用率（CPU、内存、磁盘）
低开销，适合持续监控
提供随时间变化的聚合指标

SQL Server 分析器：

追踪个人 SQL Server 事件和查询
捕获详细的查询执行信息
开销较大，不建议持续使用
最适合解决特定查询问题
已弃用，转而使用扩展事件

使用性能监视器进行整体系统监视，使用扩展事件（而非分析器）进行详细的查询级分析。

17.4 性能监视器是否会影响 SQL Server 性能？

如果配置正确，性能监视器对 SQL Server 性能，通常开销不到 2%。然而，过度监控可能会导致以下问题：

计数器过多会增加开销
采样间隔非常短（少于 15 秒）会给资源造成压力
持续高频采集产生较大的日志文件

为了尽量减少影响：

仅监控必要的计数器
使用适当的采样间隔（常规监测为 60 秒）
将日志存储在与数据库文件分开的驱动器上
在非高峰时段安排资源密集型监控

17.5 我应该保留性能监控数据多长时间？

保留取决于您的分析需求和存储容量：

最小： 3 个月用于解决近期问题
推荐： 1-2 年的产能规划和趋势分析
最佳的： 如果存储允许，可以无限期保存，因为历史数据会随着时间的推移变得更有价值

性能计数器数据压缩效果良好，占用空间相对较少。考虑将旧数据归档到单独的存储空间，而不是删除。许多组织发现，多年的历史数据对于容量规划和识别长期趋势非常有价值。

17.6 关键性能计数器的良好阈值是多少？

建议的警报阈值：

内存授予待定：当 > 0 时发出警报
页面寿命预期：< 300 秒时发出警报
% 处理器时间：当处理器时间超过 80% 并持续 5 分钟时发出警报
处理器队列长度：当每个核心 > 2 时发出警报
平均磁盘秒/读或写：> 20ms 时发出警报
磁盘队列长度：当每个磁盘 > 2 时发出警报
阻塞进程：当 > 5 时发出警报

根据您的基线数据和特定工作负载特征调整这些阈值。在一个环境中正常的值在另一个环境中可能表示存在问题。

17.7 如何监控 SQL Server 远程执行？

监控远程 SQL Server 使用这些方法的实例：

性能监视器： 添加计数器时指定远程计算机名称
电源外壳： 将 -ComputerName 参数与 Get-Counter 结合使用
车辆管理局 (DMV)： 通过SSMS连接远程服务器并查询DMV
第三方工具： 大多数监控工具都支持远程服务器监控

确保防火墙规则允许性能监视器流量，并且您在远程服务器上拥有适当的权限。对于多台服务器，请考虑使用专用监控服务器和数据库实施集中监控。

17.8 最好的免费工具是什么 SQL Server 性能监视器？

有几种优秀的免费工具可用于监控 SQL Server 性能：

Windows 性能监视器： 内置、全面、可靠
SSMS 活动监视器： 实时监控，无需额外安装
扩展事件： 内置轻量级事件监控 SQL Server
sp_WhoIsActive： 用于详细活动监控的流行免费存储过程
DBA Dash： 功能全面的开源监控工具
SQL监视： 开源且具有近乎实时的监控功能

对于大多数组织而言，性能监视器与 SSMS 工具和 sp_WhoIsActive 结合使用，可提供出色的监控功能，而无需额外成本。

17.9 如何导出 PerfMon 数据进行分析？

使用以下方法导出性能监视器数据：

导出至 CSV：

打开性能监视器并加载日志文件
右键单击图形并选择 数据另存为
选择 文本文件（逗号分隔）（.csv）
选择位置并保存
在 Excel 中打开进行分析

使用 Relog 命令：

relog input.blg -f csv -o output.csv

此命令行实用程序将二进制日志文件 (.blg) 转换为 CSV 格式，以便在电子表格应用程序中更轻松地进行分析。

17.10 什么时候应该使用第三方监控工具而不是内置选项？

在以下情况下考虑使用第三方工具：

管理大量 SQL Server 实例（10+）
需要跨多个数据中心进行集中监控
需要预测分析或异常检测等高级功能
希望将警报与事件管理系统集成
要求合规报告和历史分析
缺乏 DBA 资源来构建和维护定制解决方案
监控异构数据库环境（SQL Server（例如 Oracle、MySQL 等）

内置工具非常适合小型环境，或者您拥有经验丰富的 DBA 来开发自定义监控解决方案。第三方工具则通过节省时间、提供高级功能和专业支持来提供价值。

18.其他资源

18.1 官方文档

Microsoft 提供了大量文档 SQL Server 性能监视器：

SQL Server 性能监视器文档： https://learn.microsoft.com/en-us/sql/relational-databases/performance-monitor/
动态管理视图： https://learn.microsoft.com/en-us/sql/relational-databases/system-dynamic-management-views/
扩展事件： https://learn.microsoft.com/en-us/sql/relational-databases/extended-events/
查询商店： https://learn.microsoft.com/en-us/sql/relational-databases/performance/monitoring-performance-by-using-the-query-store
性能调整和监控： https://learn.microsoft.com/en-us/sql/relational-databases/performance/

18.2 推荐的工具和下载

必备工具 SQL Server 性能监视器：

PAL 工具： https://github.com/clinthuffman/PAL
sp_WhoIsActive： http://whoisactive.com/
DBA Dash： https://dbadash.com/
SQL监视： https://github.com/marcingminski/sqlwatch
急救包（Brent Ozar）： https://www.brentozar.com/first-aid/
SQL Server 管理工作室： https://learn.microsoft.com/en-us/sql/ssms/download-sql-server-management-studio-ssms

18.3 社区资源

从中学习 SQL Server 社区：

SQL Server 中央： https://www.sqlservercentral.com/
布伦特·奥扎尔博客： https://www.brentozar.com/blog/
SQL小屋： https://www.sqlshack.com/
MSSQL提示： https://www.mssqltips.com/
Reddit r/SQLServer： https://www.reddit.com/r/SQLServer/
堆栈溢出 SQL Server 标签： https://stackoverflow.com/questions/tagged/sql-server

这些资源提供了经验丰富的教程、故障排除建议和最佳实践 SQL Server 专业人士。参与社区论坛可以帮助您学习他人的经验并分享自己的知识。

关于作者

袁盛是一位高级数据库管理员 (DBA)，拥有超过 10 年的 SQL Server 环境和企业数据库管理。他成功解决了金融服务、医疗保健和制造等行业的数百个数据库恢复场景。

袁专长于 SQL Server 数据库恢复高可用性解决方案以及性能优化。他丰富的实践经验包括管理数TB数据库、实施 Always On 可用性组并为关键业务系统开发自动化备份和恢复策略。

通过他的技术专长和实践方法，袁致力于创建全面的指南，帮助数据库管理员和 IT 专业人员解决复杂的 SQL Server 高效应对挑战。他始终掌握最新 SQL Server 版本和微软不断发展的数据库技术，定期测试恢复场景以确保他的建议反映现实世界的最佳实践。

有关于的问题 SQL Server 恢复或需要额外的数据库故障排除指导？袁欢迎反馈和建议用于改进这些技术资源。

SQL Server 性能监视器：完整指南 [2026]

1. 介绍 SQL Server 性能监视器

1.1什么是 SQL Server 性能监视器？

1.2 性能监控的主要优势

1.3 常见的性能挑战

2. 了解 Windows 性能监视器 (PerfMon)

2.1 什么是 Windows 性能监视器？

2.2 启动性能监视器

3。 必要 SQL Server 性能计数器

3.1 内存性能计数器

可用兆字节

页面预期寿命

缓冲区缓存命中率

内存授予待定

目标服务器内存与服务器总内存

3.2 处理器性能计数器

处理器时间百分比

特权时间百分比

处理器队列长度

上下文切换次数/秒

3.3 磁盘 I/O 性能计数器

磁盘时间百分比

平均磁盘秒/读取和平均磁盘秒/写入

磁盘队列长度

磁盘字节/秒

磁盘传输/秒

3.4 SQL Server 特定计数器

3.4.1 缓冲区管理器计数器

3.4.2 SQL统计计数器

3.4.3 通用统计计数器

3.4.4 内存管理器计数器

4. 设置性能监视器 SQL Server（Windows Vista/Server 2008 及更高版本）

4.1 什么是数据收集器集？

4.2 创建数据收集器集

4.3 要添加的关键计数器

4.4 设置停止条件

4.5 安排数据收集

5. 设置性能监视器 SQL Server（Windows XP/Server 2003 及更早版本）

5.1 创建计数器日志

5.2 添加性能计数器

5.3 配置采样间隔

5.4 配置日志文件

5.5 设置凭证

6.分析性能监视器数据

6.1 在性能监视器中查看日志文件

6.2 将数据导出到 Excel

6.3 解释计数器值

6.3.1 内存计数器分析

6.3.2 CPU计数器分析

6.3.3 磁盘计数器分析

6.4 使用公式和统计数据

7. 日志性能分析（PAL）工具

7.1 PAL 简介

7.2 设置 PAL

7.3 使用 PAL 处理日志文件

7.4 分析 PAL 报告

8.替代 SQL Server 监控工具

8.1 内置 SQL Server 工具

8.1.1 SQL Server 活动监视器

8.1.2 SQL Server 绩效仪表板

8.1.3 SQL Server 探查

8.1.4 扩展事件

8.1.5 动态管理视图（DMV）

8.2 第三方监控解决方案

龙门SQL监控器

SolarWinds的 SQL Server 监控工具

伊德拉的 SQL Server 性能监控工具

应用程序管理器的 SQL 监控

8.3 开源监控工具

DBA 冲刺

SQL监视

操作服务器

sp_WhoIsActive

9. 最佳实践 SQL Server 性能监视器

9.1 建立性能基线

9.2 设置适当的警报阈值

9.3 定期数据审查和分析

9.4 平衡监控开销

9.5 长期数据保留

9.6 与 DevOps 实践相结合

3。必要 SQL Server 性能计数器

12。监控 SQL Server 在云环境中