1. 引言
1.1什么是 SQL Server 活动监视器？
SQL Server 活动监视器是内置的诊断工具。 SQL Server 显示以下信息的管理工作室 SQL Server 进程及其对服务器性能的影响。它允许您跟踪 SQL Server 通过单一界面即可处理进程、监控资源等待、分析高成本查询和观察 I/O 模式。
1.2 为什么要使用 SQL Server 活动监视器？
活动监视器是您排查性能问题的第一道防线。它可以让您立即了解设备上正在发生的事情。 SQL Server 无需复杂的 T-SQL 查询或第三方工具即可实现实例。
该工具擅长帮助您快速识别常见问题，例如会话阻塞、CPU密集型查询、过多的查询执行以及I/O瓶颈。当用户报告应用程序运行缓慢或无响应时，“活动监视器”可帮助您确定数据库服务器是否是罪魁祸首。
对于那些不使用数据库的数据库管理员来说 SQL Server 日常使用中，活动监视器提供了一个便捷的入口点，方便用户了解服务器活动。即使是经验丰富的数据库管理员也将其作为性能调查的起点。
1.3 活动监视器与其他监视工具
虽然活动监控功能很有价值，但了解它与其他监控选项的比较情况也很重要：
活动监视器与 sp_WhoIsActive： 活动监视器提供了一个多窗格的图形界面，而 sp_WhoIsActive 是一个综合性的存储过程，可在单个结果集中提供更详细的信息。sp_WhoIsActive 显示活动监视器分组的特定等待类型，并提供更细粒度的阻塞信息。
活动监视器与 sp_who2： 传统的 sp_who2 命令显示基本的会话信息，但活动监视器更进一步，以有组织的、可视化的格式显示等待统计信息、昂贵的查询和 I/O 指标。
活动监视器与第三方工具： 像 SolarWinds Database Performance Analyzer 这样的商业监控解决方案提供历史跟踪、警报和高级分析功能，而 Activity Monitor 则不具备这些功能。不过，Activity Monitor 无需额外费用或安装。
1.4 数据库管理员的主要收益
活动监视器具有多项优势，使其成为必不可少的数据库管理员工具：
- 零成本： 作为内置的 SQL Server 使用 Management Studio 功能，无需支付许可费或进行部署。
- 实时监控： 实时查看当前服务器活动，刷新间隔可配置，从 1 秒到 1 小时不等。
- 综合行动： 右键单击进程可终止会话、查看查询详细信息或启动 SQL Server 分析器跟踪——全部来自工具内部。
- 多重视角： 通过五个专门的窗格从不同角度查看服务器运行状况，每个窗格都侧重于性能的特定方面。
- 快速故障排除： 在几分钟内识别最常见的性能问题，加快平均问题解决速度。
- 进入门槛低： 无需任何高级知识即可开始有效使用该工具，但深入了解 SQL Server 专业知识有助于解读。
2. 活动监视器入门
要有效利用活动监视器，您需要了解启动该工具的前提条件、所需权限和各种方法。
2.1 先决条件和系统要求
使用 SQL Server 活动监视器，你需要 SQL Server SSMS（管理工作室）安装在您的本地计算机或跳转服务器上。活动监视器工具已进行了重大重新设计。 SQL Server 2008 年，因此本指南中的信息适用于 SQL Server 2008 及更高版本。
您必须具备网络连接。 SQL Server 您要监控的实例。对于云托管数据库，通常需要 VPN 连接或正确配置的防火墙规则才能访问该实例。
活动监视器适用于所有版本 SQL Server包括 Express、Standard 和 Enterprise 版本。该工具本身在客户端计算机上的 SSMS 中运行，因此服务器资源仅受其执行的监控查询的影响。
2.2 必要权限
正确的权限对于活动监视器的正常运行至关重要。如果没有相应的权限，您可能会看到空白显示或收到访问被拒绝的错误提示。
2.2.1 查看服务器状态权限
此 查看服务器状态 使用活动监视器的首要条件是拥有相应的权限。此服务器级权限允许您查看所有活动进程及其相关指标。
要授予此权限，服务器管理员可以执行以下命令：
GRANT VIEW SERVER STATE TO [YourLoginName];
如果没有 VIEW SERVER STATE 命令，活动监视器可能会打开，但其任何窗格中都不会显示任何数据。
2.2.2 数据库级权限
要查看“数据文件 I/O”窗格中的信息，您需要额外的权限。具体来说，您必须拥有以下组合之一：
- 创建数据库 许可，或
- 修改任何数据库 许可，或
- 查看任何定义 允许
这些权限必须与以下条件结合使用： 查看服务器状态 实现完整的活动监视器功能。
2.2.3 权限故障排除
如果“活动监视器”打开但未显示任何数据，最常见的原因是权限问题。请检查您的登录帐户是否在服务器级别拥有“查看服务器状态”的权限。您可以通过运行以下命令来验证您的权限：
SELECT * FROM fn_my_permissions(NULL, 'SERVER');
请在 permission_name 列中查找“VIEW SERVER STATE”权限。如果该权限缺失，请联系数据库管理员授予其权限。
2.3 如何在 SSMS 中打开活动监视器
SQL Server Management Studio 提供了四种不同的启动活动监视器的方法，您可以根据自己的工作流程偏好灵活选择。
2.3.1 方法 1：从工具栏
打开“活动监视器”最快捷的方法是使用工具栏图标：
- 连接到你的 SQL Server 实例在 SQL Server 管理工作室。
- 在标准工具栏中找到“活动监视器”图标（它类似于带有绿色播放按钮的条形图）。
- 点击图标启动活动监视器。
当您已经在 SSMS 中工作并且需要快速检查服务器活动时，此方法是最快的。
2.3.2 方法二：从对象资源管理器
您也可以直接从对象资源管理器启动活动监视器：
- 在对象资源管理器中，找到 SQL Server 您要监控的实例。
- 右键单击实例名称。
- 选择 活动监视器 从上下文菜单。
当连接到多个服务器时，这种方法很有用，因为它能确保您监控的是正确的实例。
2.3.3 方法 3：使用键盘快捷键
对于以键盘操作为主的用户而言， SQL Server Management Studio 提供了一个专用快捷方式：
- 确保 SSMS 是活动窗口，并且您已连接到实例。
- 媒体中心 按Ctrl + 其他 + A.
- 将打开对象资源管理器中当前选定实例的活动监视器。
请注意，“活动监视器”将连接到您在对象资源管理器中选择的任何服务器实例，因此请确保在使用此快捷方式之前已选择正确的实例。
2.3.4 方法 4：从选项菜单（启动配置）
如果您经常使用活动监视器，您可以将 SSMS 配置为在每次启动应用程序时自动启动它：
- In SQL Server 管理工作室，导航至 工具 -> 可选项.
- 在“选项”对话框中，展开 环境，然后选择 创业公司.
- 来自 在启动时 下拉列表，选择 打开对象资源管理器和活动监视器.
- 选择 OK.
下次启动 SSMS 并连接到服务器时，活动监视器将与对象资源管理器一起自动打开。
3. 了解活动监视器窗格
活动监视器将信息组织成五个可展开的窗格，每个窗格都提供服务器活动的不同视角。了解每个窗格显示的内容对于有效排查故障至关重要。
3.1 概览窗格
概览窗格显示四个实时图表，让您快速了解您的健康状况。 SQL Server 例如，这些图表会按可配置的时间间隔更新，帮助您一目了然地识别异常模式。
3.1.1% 处理器时间
该图显示了处理器执行非空闲线程所花费的时间百分比。 SQL Server 跨所有 CPU 的实例。该值表示 SQL Server指的是处理器利用率，而不是整个服务器的 CPU 使用率。
如果处理器使用率持续达到或接近 100%，则说明服务器受 CPU 限制。这可能表明查询效率低下、缺少索引或硬件容量不足。请使用“最近耗时查询”窗格来确定哪些查询消耗的 CPU 资源最多。
3.1.2 等待任务
该指标显示等待资源释放才能继续执行的任务数量。任务可能等待 CPU、I/O、内存或锁。
持续存在大量等待任务表明资源争用。“资源等待”窗格提供了有关导致等待的资源类型的更多详细信息。
3.1.3 数据库 I/O (MB/s)
此图显示了内存和磁盘之间的数据传输速率。它综合考虑了读取和写入操作，单位为兆字节每秒。
数据库 I/O 峰值可能表明查询正在执行大型表扫描、日志记录活动过多或正在执行检查点操作。“数据文件 I/O”窗格按数据库和文件细分 I/O 活动。
3.1.4 每秒批量请求数
该指标代表了以下数量： SQL Server 实例每秒接收的批次。一个批次可以是单个语句，也可以是同时提交的多个语句。
该值可反映服务器的整体活动情况。正常工作时间内批量请求突然下降可能表明应用程序连接存在问题或用户体验出现问题。
3.1.5 设置刷新间隔
您可以自定义活动监视器更新数据的频率：
- 在概览窗格中的任意位置单击鼠标右键。
- 选择 刷新间隔.
- 从预定义值中选择一个时间间隔：1 秒、5 秒、10 秒（默认）、30 秒、1 分钟或 1 小时。
将刷新间隔设置为低于 10 秒会增加服务器的监控开销。对于高负载的生产系统，建议使用 30 秒或更长的间隔，以最大程度地减少影响。
3.2 进程窗格
“进程”窗格显示有关当前正在运行的会话的信息。 SQL Server 例如，此窗格对于识别谁在执行什么操作以及发现阻塞性问题至关重要。
3.2.1 理解过程信息
“进程”窗格中的每一行代表服务器上的一个活动会话。该窗格显示来自所有数据库和所有用户的会话，让您可以全面了解服务器活动。
显示的信息包括登录名、应用程序名称、主机名、正在访问的数据库以及当前命令。这有助于您将数据库活动与特定用户或应用程序关联起来。
3.2.2 主要列说明
了解关键列有助于您有效地解读过程信息：
- 会话 ID： 每个连接都有一个唯一的标识符。系统进程使用否定会话 ID。
- 用户进程： 指示这是用户会话（是）还是系统进程（否）。
- 登录： 此 SQL Server 登录名或与会话关联的 Windows 帐户。
- 数据库： 当前会话的数据库上下文。
- 任务状态： 显示会话当前状态（运行中、已暂停、已休眠等）。
- 命令： 正在执行的命令类型（SELECT、INSERT、UPDATE 等）。
- 应用： 创建连接的应用程序名称。
- 等待时间： 会话等待资源的时间（以毫秒为单位）。
- 等待类型： 会话正在等待的具体资源类型。
- CPU 时间： 该会话自连接以来消耗的总 CPU 时间。
- 内存使用情况： 当前分配给会话的内存量（以 KB 为单位）。
3.2.3 过滤和排序过程
“进程”窗格包含强大的筛选功能，可帮助您专注于相关会话：
- 点击任意列标题中的下拉箭头。
- 筛选器显示该列的可用值，包括 全部内容, 空白和 非空白.
- 选择特定值，筛选显示内容，仅显示这些会话。
例如，您可以进行筛选 任务状态 仅显示正在运行的会话，或进行筛选 数据库 查看针对特定数据库的活动。
您还可以通过单击列标题来按列排序。单击一次按升序排列，单击两次按降序排列。
3.2.4 识别阻塞和被阻塞的会话
“进程”窗格可帮助您识别阻塞情况，即一个会话阻止其他会话继续进行：
- 被屏蔽： 显示阻塞当前会话的会话 ID。如果此列包含值，则表示该会话正在等待另一个会话持有的锁。
- 头部阻挡器： 如果此会话阻塞了其他会话但自身未被阻塞，则显示“1”。这是阻塞链的根本原因。
要调查阻塞问题，首先要确定阻塞头（阻塞头列中标记为“1”的会话），然后检查它正在做什么，并决定是让它完成还是终止它。
3.2.5 进程操作（终止、详细信息、跟踪）
活动监视器允许您对单个会话执行操作：
- 在“进程”窗格中右键单击任意会话。
- 您会看到几个选项：
- 订阅计划详情 显示本次会话执行的最后一个命令。
- 终止进程： 终止会话（请谨慎使用）。
- 跟踪过程 SQL Server 分析器： 推出 SQL Server 探查 并自动筛选，仅显示本次会话的活动。
“详细信息”选项会显示命令文本，但请注意，这只是…… 最后 命令已执行——它可能已停止运行。当您需要查看会话正在执行的完整命令序列时，“跟踪”选项特别有用。
3.3 资源等待窗格
“资源等待”窗格汇总了等待统计信息，显示会话最常等待的资源类型。此信息对于诊断性能瓶颈至关重要。
3.3.1 理解等待统计数据
日期 SQL Server 如果无法立即授予资源请求（例如锁、CPU 时间或内存），请求任务将进入等待状态。等待统计信息会跟踪这些等待时间，帮助您了解服务器在哪些方面花费了时间等待而不是执行任务。
“资源等待”窗格从系统动态管理视图（例如 sys.dm_os_wait_stats 和 sys.dm_exec_requests）收集数据。在每个刷新间隔，它都会计算当前快照与上一个快照之间的差异，从而显示每种等待类型的累积速率。
3.3.2 等待类别
活动监视器将数百种不同的等待类型归纳为更广泛的类别，以简化解释：
- CPU： 等待 CPU 时间可用的任务。
- 缓冲锁存器： 等待短期同步对象，以保护对内存中数据页的访问。此类别包括页面闩锁等待 (PAGELATCH_*)。
- 锁： 会话持有其他会话需要的锁而导致的等待。
- 记忆： 等待排序和哈希等操作所需的内存授权。
- 网络 I/O： 等待向客户端发送数据或从客户端接收数据。
- SQL CLR： 与公共语言运行时执行相关的等待。
这种分组方式虽然简化了视图，但也掩盖了一些重要的细节。例如，“缓冲区闩锁”可能将 PAGELATCH_SH、PAGELATCH_UP 和 PAGELATCH_EX 等待事件归为一类，而这些事件对性能的影响各不相同。
3.3.3 解读等待时间和等待任务
“资源等待”窗格显示每个等待类别的两个关键指标：
- 累计等待时间（毫秒）： 此等待类别在当前刷新间隔内累计的总毫秒数。
- 等待任务： 当前该类别中等待资源的任务数量。
等待时间值尤其值得关注。如果刷新间隔为 10 秒，并且某个类别的等待时间为 20,000 毫秒，则表示存在多个并发等待（20,000 毫秒 / 10,000 毫秒 = 该间隔内 2 个并发等待的平均值）。
3.3.4 识别性能瓶颈
使用“资源等待”窗格来确定服务器在哪些地方花费了最多的等待时间：
- 展开“资源等待”窗格。
- 观察等待时间最长的等待类别。
- 排序方式 累计等待时间 了解哪些资源最为紧张。
高缓冲区闩锁等待通常表明内存中存在数据页争用，这可能暗示存在 I/O 瓶颈或 tempdb 争用。高锁等待指向阻塞问题。高内存等待表明查询操作的内存授权不足。
3.4 数据文件 I/O 面板
数据文件 I/O 窗格显示服务器上每个数据库文件的磁盘活动，帮助您识别 I/O 瓶颈并了解磁盘利用率模式。
3.4.1 理解 I/O 指标
“数据文件 I/O”窗格显示每个数据库文件的多个指标：
- 数据库： 数据库的名称。
- 文件类型： 可以是数据（包括表和索引）或日志（事务日志）。
- 逻辑名称： 逻辑文件名，定义于 SQL Server.
- MB/秒读取： 从该文件读取数据的速率。
- MB/秒写入速度： 写入此文件的数据速率。
- 响应时间（毫秒）： 此文件的 I/O 操作平均响应时间。
这些指标与概览窗格的刷新间隔相同，让您可以实时了解磁盘活动。
3.4.2 识别 I/O 瓶颈
注意以下这些可能表明 I/O 性能问题的模式：
- 高响应时间： 响应时间持续高于 15-20 毫秒表明磁盘子系统运行缓慢。响应时间高于 50 毫秒则表明存在严重的 I/O 瓶颈。
- 不平衡负载： 如果某个数据文件的 I/O 速率明显高于同一数据库中的其他文件，则可以通过添加其他文件来分散负载，从而获得更好的效果。
- Tempdb 活动过多： tempdb 文件上的高 I/O 率通常表明查询会生成大型中间结果集或使用效率低下的执行计划。
3.4.3 数据库文件分析
使用“数据文件 I/O”窗格可以了解数据库如何使用磁盘资源：
- 展开“数据文件 I/O”窗格。
- 排序方式 MB/秒读取 or MB/秒写入 识别最活跃的文件。
- 注意任何活动量持续很高或响应时间过长的文件。
- 将此信息与“最近的高成本查询”窗格进行交叉比对，以确定哪些查询导致了 I/O 负载。
3.5 近期高成本查询窗格
“最近高成本查询”窗格通常是排查应用程序性能问题最有价值的窗格。它会显示消耗大量服务器资源的查询，帮助您发现优化机会。
3.5.1 理解查询指标
活动监视器会显示每个高成本查询的多个指标：
- 执行次数/分钟： 过去一分钟内查询执行了多少次？
- CPU（毫秒/秒）： 此查询每秒消耗的 CPU 时间。
- 物理读取次数/秒： 此查询每秒物理磁盘读取次数。
- 逻辑写入/秒： 每秒逻辑写入次数（到缓冲区缓存）。
- 逻辑读取/秒： 每秒逻辑读取次数（从缓冲区缓存读取）。
- 平均持续时间（毫秒）： 此查询的平均执行时间。
- 计划数量： 此查询的缓存执行计划数量。
这些指标不仅能帮助你了解哪些查询成本高，而且 为什么 它们价格昂贵，而且运行频率也不高。
3.5.2 排序选项
您可以按不同指标对“最近的高成本查询”窗格进行排序，以查找不同类型的问题：
- 点击任意列标题即可按该指标排序。
- 常见的分类策略包括：
- 按CPU使用率排序： 找出占用处理器时间最多的查询。
- 按执行次数/分钟排序： 找出运行频率过高的查询。
- 按实体书数量排序： 找出导致磁盘 I/O 最多的查询。
- 按平均时长排序： 查找长时间运行的查询。
在排查性能问题时，尝试按多个列排序，以获得不同的视角。CPU 使用率适中但每分钟执行次数极高的查询可能才是真正的问题所在。
3.5.3 查看查询文本
要查看开销较大的查询背后的实际 SQL 语句：
- 在“最近的高成本查询”窗格中，右键单击查询行。
- 选择 编辑查询文本.
- 此时会打开一个新的查询窗口，显示完整的 SQL 语句。
这样一来，您可以检查查询逻辑并找出潜在的优化机会。然后，您可以复制查询文本以测试修改后的版本。
3.5.4 分析执行计划
执行计划会告诉你如何 SQL Server 执行查询，揭示出诸如缺少索引或不合适的连接类型等效率低下的问题：
- 在“最近的高成本查询”窗格中，右键单击查询行。
- 选择 展示执行计划.
- SQL Server Management Studio 会以图形方式显示查询的执行过程。
查找占用查询成本比例较高的操作、缺少统计信息或索引的警告以及意外的表扫描操作。这些通常表明优化工作的重点应该放在哪里。
3.5.5 识别问题查询
在“最近高成本查询”窗格中留意以下模式：
- 过度处决： 每分钟执行数千次的查询可能表明存在 N+1 查询问题，即应用程序代码在循环中调用数据库。
- 高强度体力阅读： 物理读取频率高的查询频繁地访问磁盘，这表明缺少索引或查询编写不佳。
- 高CPU占用率但低持续时间： 许多快速查询累积起来会消耗大量 CPU 资源，其对服务器性能的影响与少数慢速查询一样大。
- 多个计划数量： 执行计划过多的查询可能会出现参数嗅探问题，或者非参数化查询会导致计划缓存膨胀。
4. 使用活动监视器进行性能故障排除
当您系统地使用“活动监视器”来诊断和解决性能问题时，它的优势才能真正体现出来。本节将介绍常见的故障排除场景以及相应的解决方法。
4.1 诊断过多的查询执行
最常见的性能问题之一是查询执行频率远高于必要频率，这通常是由于应用程序设计问题造成的。
4.1.1 识别重复查询
要找出执行频率过高的查询：
- 打开活动监视器并展开 近期昂贵的查询 窗格。
- 排序方式 执行次数/分钟 （每分钟执行次数）。
- 查找执行次数异常高的查询。
- 右键单击可疑查询并选择 编辑查询文本 检查 SQL 语句。
例如，如果您发现一个简单的 SELECT 语句每分钟执行 37,000 次，就应该质疑应用程序是否真的需要如此频繁地调用此查询。大多数每分钟执行超过几千次的查询都值得调查。
4.1.2根本原因分析
过多的查询执行通常源于以下问题：
- N+1 查询问题： 应用程序代码首先检索项目列表，然后对每个项目执行单独的查询以获取相关数据。这将创建 N 个额外的查询，其中 N 为项目数量。
- 缺少缓存： 该应用程序会查询数据库以获取很少更改的数据，而不是将其缓存在应用程序内存中。
- 轮询循环： 代码反复查询数据库以检查状态变化，而不是使用变更通知或消息队列。
- ORM效率低下： 当开发人员不了解他们的代码如何转换为 SQL 时，Entity Framework 和类似工具有时会生成效率低下的查询模式。
要确定根本原因，请将查询追溯到应用程序代码。请注意…… 应用领域 和 登录 查询执行时，“进程”窗格中将显示列。您也可以右键单击进程并选择。 跟踪过程 SQL Server 探查 查看调用模式。
4.1.3 解决方案与最佳实践
一旦发现查询执行次数过多，请考虑以下解决方案：
- 批量处理： 修改应用程序代码，使用连接或 IN 子句在单个查询中检索多个项目，而不是在循环中执行单独的查询。
- 结果缓存： 将应用程序内存中经常访问、不经常更改的数据缓存起来，并设置适当的过期时间。
- 急切加载： 配置 ORM 使用预加载策略，以更少、更高效的查询获取相关数据。
- 查询参数化： 确保查询使用参数而不是连接值，这样可以提高计划缓存的重用率并减少编译开销。
4.2 调查阻塞问题
当一个会话持有大量锁，导致其他会话无法继续执行操作时，就会发生阻塞。这会导致应用程序响应速度变慢，用户体验不佳。
4.2.1 识别阻塞链
检测和分析阻塞：
- 打开活动监视器并展开 加工流程 窗格。
- 寻找包含价值观的会话。 被阻止 列——这些正在等待其他会话持有的锁。
- 查找包含“1”的会话 头部阻挡器 列——这些是造成链阻塞的根本原因。
- 注意 会话ID 头部阻挡器。
- 右键单击头部阻挡器会话并选择 信息 查看它正在执行什么命令。
理解阻塞链至关重要。你需要调查的是阻塞链的源会话，而不是下游被阻塞的会话。
4.2.2 了解锁的类型
此 等待类型 “进程”窗格中的列指示被阻塞的会话正在等待哪种类型的锁：
- LCK_M_X： 独占锁等待，通常由 UPDATE、DELETE 或 INSERT 操作引起。
- LCK_M_S： 共享锁等待，通常是 SELECT 语句等待独占锁释放。
- LCK_M_U： 更新锁等待，一种在更新过程中使用的中间锁类型。
- LCK_M_IX： 意图独占锁等待，表示页面级或行级锁争用。
此 等待资源 该列显示哪个数据库对象被锁定，帮助您了解哪个表或索引卷入了争用。
4.2.3 解决阻塞问题
一旦你确定了阻塞会话及其正在执行的操作，你就有以下几种选择：
- 等待完成： 如果头部阻塞程序正在运行一个即将完成的合法查询，最好让它自然完成。
- 终止会话： 如果头部阻塞程序卡住或正在运行应该取消的查询：
- 在“进程”窗格中右键单击会话。
- 选择 终止进程.
- 在对话框中确认操作。
- 优化查询： 如果阻塞反复出现于相同的查询中，则优化这些查询以减少其锁定持续时间。
- 调整隔离级别： 考虑使用 READ COMMITTED SNAPSHOT ISOLATION 来减少读取密集型工作负载中的阻塞。
- 指数调整： 添加索引可以加快查询速度，减少查询持有锁的时间。
4.3 分析高 CPU 使用率
当“概览”窗格显示处理器时间持续达到或接近 100% 时，您需要确定哪些查询导致了这种情况，并确定是否可以对它们进行优化。
4.3.1 识别 CPU 密集型查询
查找占用过多 CPU 资源的查询：
- 打开 近期昂贵的查询 窗格。
- 排序方式 CPU（毫秒/秒） 显示占用 CPU 时间最多的查询。
- 查看列表中的热门搜索词。
- 右键单击高 CPU 查询并选择 编辑查询文本 查看 SQL 语句。
- 选择 展示执行计划 了解查询是如何执行的。
不仅要注意单个查询的 CPU 使用率，还要注意…… 执行次数/分钟 列。一个每次执行仅消耗少量 CPU 资源，但每分钟运行数千次的查询，可能会成为 CPU 消耗大户。
4.3.2 查询优化技术
降低CPU占用率的常用方法包括：
- 添加缺失的索引： 索引查找比表扫描占用更少的 CPU 资源。请检查执行计划中是否存在缺失的索引建议。
- 重写低效查询： 用基于集合的操作替换游标，消除 WHERE 子句中不必要的函数，并删除冗余的连接。
- 更新统计数据： 过时的统计数据会导致 SQL Server 选择效率低下的执行计划。对受影响的表运行 UPDATE STATISTICS 语句。
- 减少数据量： 更早地添加 WHERE 子句来筛选数据，使用 TOP 或 OFFSET/FETCH 进行分页，并避免使用 SELECT *。
- 修复参数嗅探问题： 当参数嗅探导致问题时，请使用 OPTION (RECOMPILE)、查询提示或计划指南。
4.4 内存问题调查
内存压力会导致查询溢出到磁盘，从而显著降低性能。活动监视器可帮助您识别内存密集型操作。
4.4.1 理解内存指标
此 内存使用 “进程”窗格中的列显示分配给每个会话的内存（以千字节为单位）。单个会话内存使用量过高通常表示：
- 大型排序或哈希操作无法放入初始分配的内存中
- 查询检索到海量结果集
- 过度并行化导致执行计划操作符出现大量副本。
- CLR 存储过程或函数中的内存泄漏
“资源等待”窗格可能会显示内存等待，因为查询无法获得足够的内存授权，必须等待内存可用。
4.4.2 识别内存密集型查询
查找导致内存压力的查询：
- 在 加工流程 窗格，按以下方式排序 内存使用 查看占用内存最多的会话。
- 右键单击内存使用率高的会话并选择 信息 查看他们的查询。
- 在 近期昂贵的查询 在窗格中查找高查询 逻辑读取 or 逻辑写作因为这通常与内存使用情况相关。
- 检查使用内存授权的排序和哈希匹配运算符的执行计划。
执行计划中出现“内存授权”警告或溢出警告的查询表明存在内存压力问题。
4.5 检测应用程序性能问题
当用户报告应用程序响应时间缓慢时，活动监视器可帮助您确定数据库是否是瓶颈。
4.5.1 将活动监视器与应用程序问题关联起来
为了调查应用程序运行缓慢的原因：
- 记录用户报告问题的确切时间和受影响的应用程序。
- 打开活动监视器并检查 概述 当时资源峰值情况的面板。
- 在 加工流程 窗格，按以下方式筛选 应用领域 仅显示来自受影响应用程序的连接。
- 寻找高 等待时间 这些值表示数据库延迟。
- 访问 近期昂贵的查询 用于显示来自消耗大量资源的应用程序的查询的窗格。
如果数据库没有显示任何异常活动，而用户却遇到速度缓慢的问题，那么问题很可能出在应用程序代码、网络延迟或客户端性能上。
4.5.2 识别低效的应用模式
活动监视器揭示了应用程序设计中的几种反模式：
- 聊天类应用： 大量小型查询而非更少但更高效的查询。最近的高成本查询中，连接数高且包含大量简单查询，以此来识别此类问题。
- N+1 查询： 一个查询之后，紧接着又有 N 个查询用于获取相关数据。表面上看，这是一个简单的查询，但每分钟的执行次数却极高。
- 大型结果集： 应用程序检索的数据量远远超过所需。请查找高 逻辑读取 结合简单的 SELECT * 查询。
- 超时次数不足： 未设置命令超时的应用程序可能会无限期地保持连接打开状态，在“进程”窗格中显示为长时间运行的会话。
5. 其他方法：通过 T-SQL 获取活动监视器数据
虽然活动监视器提供了方便的图形界面，但有时您需要以编程方式检索等效信息或创建自定义监视解决方案。
5.1 使用动态管理视图 (DMV)
SQL Server 通过动态管理视图公开活动信息，活动监视器在后台查询这些视图。
5.1.1 活动监控的关键驱动因素
用于复制活动监视器功能的最重要的 DMV 包括：
- sys.dm_exec_requests： 显示当前正在执行的请求的 CPU、I/O 和等待信息。
- sys.dm_exec_sessions： 包含会话级信息，例如登录名、主机名和程序名。
- sys.dm_os_wait_stats： 提供整个实例的累计等待统计信息。
- sys.dm_exec_query_stats： 包含缓存查询的汇总性能统计信息。
- sys.dm_io_virtual_file_stats： 返回数据文件和日志文件的 I/O 统计信息。
- sys.dm_exec_sql_text: 检索给定 sql_handle 或 plan_handle 的 SQL 文本。
- sys.dm_exec_query_plan： 返回缓存查询的执行计划。
5.1.2 流程信息示例查询
要复现“流程”窗格的功能，您可以查询：
SELECT
s.session_id AS [Session ID],
CASE WHEN s.is_user_process = 1 THEN 'Yes' ELSE 'No' END AS [User Process],
s.login_name AS [Login],
ISNULL(CAST(r.blocking_session_id AS VARCHAR), '') AS [Blocked By],
CASE
WHEN r2.session_id IS NOT NULL
AND (r.blocking_session_id = 0 OR r.session_id IS NULL)
THEN '1'
ELSE ''
END AS [Head Blocker],
ISNULL(DB_NAME(r.database_id), '') AS [Database],
ISNULL(t.task_state, '') AS [Task State],
ISNULL(r.command, '') AS [Command],
r.cpu_time AS [CPU Time],
r.total_elapsed_time AS [Elapsed Time],
r.wait_time AS [Wait Time],
r.wait_type AS [Wait Type],
s.memory_usage * 8 AS [Memory Use (KB)],
s.host_name AS [Host Name],
s.program_name AS [Application]
FROM sys.dm_exec_sessions s
LEFT JOIN sys.dm_exec_requests r ON s.session_id = r.session_id
LEFT JOIN sys.dm_exec_requests r2 ON r.session_id = r2.blocking_session_id
LEFT JOIN sys.dm_os_tasks t ON r.session_id = t.session_id
WHERE s.session_id != @@SPID
ORDER BY s.session_id;
5.1.3 等待统计信息的示例查询
要查看类似于“资源等待”窗格的等待统计信息：
SELECT TOP 10
wait_type AS [Wait Type],
wait_time_ms / 1000.0 AS [Wait Time (sec)],
waiting_tasks_count AS [Waiting Tasks],
wait_time_ms / NULLIF(waiting_tasks_count, 0) AS [Avg Wait Time (ms)]
FROM sys.dm_os_wait_stats
WHERE wait_type NOT LIKE '%SLEEP%'
AND wait_type NOT LIKE '%IDLE%'
AND wait_type NOT LIKE '%QUEUE%'
ORDER BY wait_time_ms DESC;
5.2 使用 sp_WhoIsActive
sp_WhoIsActive 是一个功能强大的社区创建的存储过程，它在单个结果集中提供比活动监视器更详细的信息。
5.2.1 安装 sp_WhoIsActive
安装 sp_WhoIsActive：
- 从下载最新版本
http://whoisactive.com. - 下载的文件是一个包含过程定义的 SQL 脚本。
- 打开脚本 SQL Server 管理工作室。
- 连接到你的 SQL Server 实例。
- 执行脚本以在主数据库中创建该过程。
- 授予相应用户执行权限。
因为 sp_WhoIsActive 安装在 master 分支上，所以可以从任何数据库上下文中访问它。
5.2.2 基本用法示例
使用 sp_WhoIsActive 的最简单方法是：
EXEC sp_WhoIsActive;
这将返回一个结果集，显示所有活动会话及其查询、等待类型、阻塞信息和资源使用情况。
取 10 秒钟的样本，显示该时间段内的活动情况：
EXEC sp_WhoIsActive @delta_interval = 10;
这会计算 CPU 和读取次数等指标的变化量，显示这 10 秒钟内发生了什么。
5.2.3 高级参数
sp_WhoIsActive 支持众多可自定义参数：
- @筛选： 将结果筛选到特定会话、数据库或登录名。
- @filter_type: 指定过滤器适用的对象（会话、数据库、登录等）。
- @get_plans： 将执行计划包含在结果中（设置为 1）。
- @get_locks： 显示详细的锁定信息（设置为 1）。
- @get_transaction_info: 显示交易详情（设置为 1）。
- @sort_order: 按不同指标（CPU、读取次数、持续时间等）对结果进行排序。
- @destination_table： 将结果插入表格以进行历史记录跟踪。
示例显示按 CPU 排序的计划：
EXEC sp_WhoIsActive
@get_plans = 1,
@sort_order = '[CPU] DESC';
5.3 使用系统存储过程
SQL Server 包括用于监控活动的传统存储过程，尽管它们提供的信息比 DMV 或活动监视器少。
5.3.1 sp_who 和 sp_who2
sp_who 过程显示基本会话信息：
EXEC sp_who;
sp_who2 程序提供了更详细的信息：
EXEC sp_who2;
这两种方法都能显示会话 ID、登录名、CPU 时间和阻塞信息。但是，它们缺乏 DMV 或活动监视器提供的丰富详细信息。它们最适合在需要快速获取少量信息时进行快速检查。
5.3.2 其他有用的系统程序
其他系统监控程序包括：
- sp_lock： 显示锁定信息（已弃用；请改用 sys.dm_tran_locks）。
- sp_monitor： 显示有关统计数据 SQL Server 活性。
- sp_help： 显示对象定义和元数据。
- DBCC SQLPERF： 显示事务日志空间使用情况和等待统计信息。
5.4 创建自定义监控脚本
对于需要超出活动监视器提供的功能的特定监视的环境，您可以使用 DMV 构建自定义解决方案。
5.4.1 完整的活动监视器等效脚本
以下是一个可以复现大部分活动监视器功能的完整脚本：
-- Processes Information
SELECT
s.session_id AS [Session ID],
CONVERT(CHAR(1), s.is_user_process) AS [User Process],
s.login_name AS [Login],
ISNULL(CONVERT(VARCHAR, w.blocking_session_id), '') AS [Blocked By],
CASE
WHEN r2.session_id IS NOT NULL
AND (r.blocking_session_id = 0 OR r.session_id IS NULL)
THEN '1'
ELSE ''
END AS [Head Blocker],
ISNULL(DB_NAME(r.database_id), N'') AS [Database],
ISNULL(t.task_state, N'') AS [Task State],
ISNULL(r.command, N'') AS [Command],
SUBSTRING(st.text, (r.statement_start_offset/2) + 1,
((CASE r.statement_end_offset
WHEN -1 THEN DATALENGTH(st.text)
ELSE r.statement_end_offset
END - r.statement_start_offset) / 2) + 1) AS [Statement],
st.text AS [Command Text],
r.cpu_time AS [CPU Time (ms)],
r.total_elapsed_time / 1000 AS [Elapsed Time (sec)],
r.wait_time AS [Wait Time (ms)],
r.wait_type AS [Wait Type],
r.wait_resource AS [Wait Resource],
s.memory_usage * 8 AS [Memory Use (KB)],
s.host_name AS [Host Name],
c.client_net_address AS [Net Address],
s.program_name AS [Application]
FROM sys.dm_exec_sessions s
LEFT JOIN sys.dm_exec_requests r ON s.session_id = r.session_id
LEFT JOIN sys.dm_exec_requests w ON r.session_id = w.blocking_session_id
LEFT JOIN sys.dm_exec_requests r2 ON r.session_id = r2.blocking_session_id
LEFT JOIN sys.dm_os_tasks t ON r.session_id = t.session_id
AND r.request_id = t.request_id
LEFT JOIN sys.dm_exec_connections c ON s.session_id = c.session_id
OUTER APPLY sys.dm_exec_sql_text(r.sql_handle) st
WHERE s.session_id != @@SPID
ORDER BY s.session_id;
-- Recent Expensive Queries
SELECT TOP 20
qs.execution_count /
DATEDIFF(MINUTE, qs.creation_time, GETDATE()) AS [Executions/min],
qs.total_worker_time / 1000 AS [CPU Time (ms)],
qs.total_physical_reads AS [Physical Reads],
qs.total_logical_writes AS [Logical Writes],
qs.total_logical_reads AS [Logical Reads],
qs.total_elapsed_time / qs.execution_count / 1000 AS [Avg Duration (ms)],
SUBSTRING(st.text, (qs.statement_start_offset/2) + 1,
((CASE qs.statement_end_offset
WHEN -1 THEN DATALENGTH(st.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) st
WHERE qs.execution_count > 0
ORDER BY qs.total_worker_time DESC;
5.4.2 使用 SQL Agent 作业实现自动化监控
您可以使用以下方式安排自定义监控脚本 SQL Server 代理人：
- 创建表格以存储监控结果。
- 修改监控脚本，将结果插入到此表中。
- In SQL Server 管理工作室，扩展 SQL Server 经纪人 在对象资源管理器中。
- 右键单击 工作机会 并选择 新工作.
- 配置作业以定期运行监控脚本。
- 根据收集的数据设置警报或报告。
这种方法能够进行历史跟踪和趋势分析，而活动监视器则无法提供这些功能。
6. 活动监测器的局限性和注意事项
虽然活动监视器很有价值，但了解其局限性有助于您正确使用它，并在必要时使用其他工具进行补充。
6.1 了解活动监视器的开销
活动监视器并非免费——它会消耗服务器资源来收集和显示信息。了解这种开销有助于您合理使用它。
6.1.1 对服务器资源的影响
活动监视器每次刷新时都会对系统动态管理视图 (DMV) 执行查询。这些查询会消耗 CPU 资源、产生逻辑读取操作，并且可能会短暂地持有系统表的锁。在繁忙的服务器上，这种开销会影响性能。
“进程”和“最近耗时查询”窗格的开销尤其大，因为它们必须扫描可能非常大的动态管理视图 (DMV) 和缓存表。在缓存了数千个查询计划的服务器上，刷新“最近耗时查询”可能需要几秒钟的时间。
微软的文档警告说，低于 10 秒的刷新间隔会明显影响服务器性能，尤其是在负载已经很高的系统上。
6.1.2 刷新间隔最佳实践
选择适合你实际情况的刷新间隔：
- 1-5秒： 仅用于在负载较低的服务器上立即排查关键问题。请勿按此时间间隔运行活动监视器。
- 10 秒（默认值）： 适用于大多数故障排除场景和一般监控。
- 30-60秒： 对于高负载生产服务器或需要长时间监控的情况，这是更好的选择。
- 仅可手动刷新： 适用于需要偶尔检查当前状态而无需持续轮询的情况。
调查结束后务必关闭活动监视器。不要让它持续运行，尤其是不要让不同用户的多个实例同时运行。
6.2 等待类型分组问题
活动监视器对等待进行分类的方法虽然简化了视图，但可能会掩盖重要的诊断信息。
6.2.1 活动监视器组等待方式
SQL Server 活动监视器跟踪数百种不同的等待类型，每一种都指示特定的资源或条件。活动监视器将这些等待类型归类为“缓冲区闩锁”、“锁定”和“内存”等大类。
例如，“缓冲区闩锁”类别包括 PAGELATCH_SH、PAGELATCH_UP、PAGELATCH_EX 以及其他几种特定的等待类型。虽然它们都与页面访问相关，但其原因和解决方法各不相同。
微软没有明确说明哪些等待类型对应哪些类别，因此很难理解你实际看到的内容。
6.2.2 缺失的等待类型
活动监视器不会显示所有等待类型。最值得注意的是，它通常会忽略 CXPACKET 等待，而 CXPACKET 等待表示并行查询执行。CXPACKET 等待很常见，通常不会造成问题，但了解它们的存在有助于您理解工作负载特征。
当活动监视器显示“缓冲区闩锁”是您的首要等待进程，但其他工具显示 CXPACKET 占主导地位时，这种差异源于活动监视器的过滤和分组逻辑。
6.2.3 为什么特定的等待类型很重要
了解具体的等待类型对于故障排除至关重要：
- 页面锁定_EX： 这通常表示 tempdb 分配页存在争用。解决方法是添加更多 tempdb 数据文件。
- 页面锁定_SH： 这可能表明用户表中存在热点页面。解决方案涉及分区或索引重组。
- 页面锁定向上： 更新过程中常见现象。可能表示运行正常，而非出现问题。
活动监视器将所有这些问题都归类到“缓冲区闩锁”下，这使得诊断更加困难。而 sp_WhoIsActive 和 DMV 查询等工具则会显示具体的等待类型。
6.3 数据准确性和及时性
活动监视器提供近乎实时的视图，但“近乎”是关键所在。了解其数据收集方法有助于您正确解读结果。
6.3.1 快照监控与连续监控
活动监视器会显示每次刷新间隔时拍摄的快照。快照之间发生的事件不会被捕获。例如，如果一个查询运行了 2 秒，而您每 10 秒刷新一次，那么您可能只会看到一次，也可能一次也看不到，具体取决于时间。
这意味着活动监视器擅长发现持续性问题（阻塞持续数分钟、CPU 使用率持续偏高），但可能会错过瞬态问题（短暂的死锁、偶尔的查询峰值）。
6.3.2 汇总和抽样
“最近高成本查询”窗格显示自查询计划进入缓存以来汇总的数据。如果两个参数值不同的相同查询共享同一个计划，则会显示为一行。这种汇总方式可能会掩盖特定参数组合的问题（参数嗅探问题）。
“资源等待”窗格通过比较快照来计算速率。如果快照之间等待统计信息重置（这种情况很少见但有可能发生），则计算出的速率可能不准确。
6.4 何时不应使用活动监视器
活动监视器并非适用于所有监视场景。请了解何时应选择其他更合适的工具。
6.4.1 历史分析要求
活动监视器仅显示当前或最近的活动，不存储历史数据。如果您需要分析数天或数周的趋势、将当前性能与基线进行比较，或生成性能模式报告，则活动监视器无法满足您的需求。
对于历史分析，请使用 SQL Server内置的性能仪表板、带有文件目标的扩展事件或第三方监控解决方案。
6.4.2 详细等待统计需求
当您需要精确的等待类型信息以进行高级调优时，活动监视器的分组和筛选功能不足以满足需求。请直接使用 DMV 查询或 sp_WhoIsActive 函数。
要进行全面的等待统计分析，请直接查询 sys.dm_os_wait_stats 并手动筛选掉良性等待。
6.4.3 生产服务器注意事项
在高负载的生产服务器上，活动监视器的开销可能会造成问题。多个数据库管理员不应该在同一台服务器上同时运行活动监视器。
对于生产监控，可以考虑使用轻量级替代方案，例如将计划的 DMV 快照存储在监控数据库中，或者使用只读路由来监控 Always On 配置中的辅助副本。
7. 使用活动监视器的最佳实践
遵循最佳实践可确保您从活动监视器中获得最大价值，同时最大限度地减少对服务器的负面影响。
7.1 何时使用活动监视器
活动监视器在特定场景下表现出色。当它的优势符合您的需求时，请使用它。
7.1.1 实时性能问题
当用户遇到问题且您需要立即诊断问题时，“活动监视器”是理想之选。实时视图可帮助您了解当前发生的情况。
当您接到“应用程序运行缓慢”的提示时，首先应该做的就是打开“活动监视器”。您可以快速确定数据库是繁忙、阻塞还是处于空闲状态。
7.1.2 应用程序运行缓慢调查
当某个应用程序无响应时，“活动监视器”可帮助您确定是否是数据库问题导致的。按应用程序名称筛选“进程”窗格，即可仅查看该应用程序的数据库活动。
如果用户报告问题时应用程序没有显示任何数据库活动，则问题出在堆栈的其他位置。如果您发现大量阻塞或开销较大的查询，那么您就找到了问题所在。
7.1.3 快速健康检查
活动监视器提供了一个出色的仪表盘，方便在日常管理期间快速进行健康检查。打开它，浏览概览图表，确认一切正常。
这种简单的检查只需几秒钟，就能在问题变得严重之前发现它们。把它纳入你的日常习惯吧。
7.2 最佳配置设置
正确配置活动监视器可以提高其可用性并降低资源占用。
7.2.1 建议刷新间隔
根据您的需求选择合适的刷新间隔：
- 主动故障排除： 10 秒的响应时间既能保证良好的响应速度，又能提供合理的开销。
- 扩展监测： 30-60 秒可减少较长观察期内对服务器的影响。
- 关键问题诊断： 5 秒可以提供很高的精度，尤其是在每一秒都至关重要的时候，但要尽量缩短使用时间。
- 定期健康检查： 当您不观看视频时，请手动刷新（每隔 1 小时刷新一次）。
使用完毕后，请务必关闭活动监视器。如果设置过长的运行间隔后忘记关闭，会浪费服务器资源。
7.2.2 过滤策略
使用筛选器来专注于相关信息并降低认知负荷：
- 按以下方式筛选流程 数据库 仅查看针对特定数据库的活动。
- 筛选条件 登录 跟踪特定用户的活动。
- 筛选条件 任务状态 = 正在运行以隐藏空闲会话。
- 筛选条件 应用领域 将流量与特定程序隔离。
- 仅显示非空白项 被阻止 仅显示阻塞情况。
7.2.3 列选择和排序
制定一套系统化的方法来审查活动监测数据：
- 首先是概述： 检查图表是否存在明显的尖峰或异常情况。
- 检查进程是否存在阻塞： 按会话 ID 排序，然后查找“被阻止者”值。
- 审查资源等待情况： 按累计等待时间排序，找出资源瓶颈。
- 分析高成本查询： 按不同指标（CPU、执行次数、读取次数）排序，以查找不同类型的问题。
- 使用 I/O 面板进行验证： 确认 I/O 密集型查询是否与高磁盘活动相关。
7.3 与其他工具的集成
活动监视器最好作为更广泛的工具包的一部分使用，而不是作为独立解决方案使用。
7.3.1 与……一起使用 SQL Server 探查
活动监测器和 SQL Server 分析器可以很好地互补。当您在活动监视器中发现问题会话时，右键单击它并选择 跟踪过程 SQL Server 探查.
这将启动性能分析器，并预先配置筛选器，仅捕获该会话的活动。您可以看到执行语句的完整序列、计时信息和错误消息——这些详细信息是活动监视器所不提供的。
要了解更多有关 SQL Server 分析器功能和高级追踪技术，请参阅我们的 全面 SQL Server Profiler 指南.
7.3.2 补充扩展事件
扩展事件提供低开销、详细的监控，可以捕获活动监视器遗漏的信息。创建扩展事件会话可以跟踪特定事件，例如死锁、长时间运行的查询或过多的重新编译。
使用“活动监视器”进行即时调查，“扩展事件”进行持续监视和历史分析。这两个工具满足不同的需求。
要了解更多有关 SQL Server 扩展事件功能和高级监控技术，请参阅我们的 全面 SQL Server 扩展活动指南.
7.3.3 第三方监控解决方案
SolarWinds Database Performance Analyzer、Redgate SQL Monitor 和 Quest Spotlight 等商业工具提供了 Activity Monitor 所缺乏的功能：警报、历史趋势、容量规划和自动诊断。
这些工具是对活动监视器的有益补充，而非替代。即使有了更高级的监控工具，活动监视器仍然可用于快速检查和调查。
7.4 应避免的常见错误
了解活动监控器常见的错误用法有助于您更有效地使用它。
7.4.1 保持活动监视器持续运行
最常见的错误是打开“活动监视器”并让它无限期地运行。这会浪费服务器资源，而且由于您没有主动监控，因此几乎没有任何价值。
不使用活动监视器时，请将其关闭。如果需要持续监控，请实施具有定时数据收集功能的正规监控方案。
7.4.2 过度依赖活动监测器
活动监视器提供了一种服务器健康状况的视角，但不要完全依赖它。应结合使用 Windows 性能监视器来获取操作系统级别的指标，使用扩展事件监视器来获取详细的跟踪信息，并使用执行计划分析来进行查询优化。
活动监视器可以帮助您发现问题，但解决这些问题通常需要其他工具和更深入的分析。
进一步了解 SQL Server 我们性能监控器中的 完整的指南.
7.4.3 忽略历史趋势
活动监视器显示当前状态，但性能问题通常只有随着时间的推移才能显现出规律。实施历史数据收集，以便将当前指标与基线进行比较，从而识别趋势。
如果没有历史背景，你可能不会意识到，如今“正常”的 CPU 使用率比上个月的基准值高出 30%，这表明 CPU 使用率正在逐渐下降。
8. 活动监视器问题排查
活动监视器本身有时也会出现问题。了解如何排查这些问题可以避免不必要的麻烦。
8.1 活动监视器无法打开或不显示任何数据
当“活动监视器”打开但显示空白窗格或根本无法打开时，可能有多种因素导致此问题。
8.1.1 权限问题
活动监视器问题的最常见原因是权限不足。要验证并解决此问题：
- 检查您的服务器级权限：
SELECT * FROM fn_my_permissions(NULL, 'SERVER') WHERE permission_name = 'VIEW SERVER STATE'; - 如果没有返回任何行，则说明您没有查看服务器状态的权限。
- 请服务器管理员授予此权限：
USE master; GRANT VIEW SERVER STATE TO [YourLogin]; - 授予权限后，关闭并重新打开活动监视器。
8.1.2 版本兼容性问题
使用旧版本 SQL Server 管理工作室连接到较新的 SQL Server 版本问题可能会导致活动监视器故障。该工具可能无法识别新的等待类型或系统视图列。
始终使用与您的系统版本相同或更新的 SSMS 版本。 SQL Server 版本。微软提供最新版本的 SSMS，可从单独的免费下载列表中获取。 SQL Server 本身。
8.1.3 防火墙和网络问题
活动监视器需要连接到…… SQL Server 实例运行在标准端口（默认为 1433）上。如果可以通过对象资源管理器连接，但活动监视器连接失败，则可能是防火墙规则阻止了特定连接。
确认您的客户可以联系到 SQL Server 请确保机器已连接到所有必要的端口。请检查 Windows 防火墙以及客户端和服务器之间的任何网络防火墙。
8.2 活动监视器永久暂停
这是一个常见问题，尤其是在 SQL Server 2019 年，活动监视器打开时处于暂停状态，并且拒绝恢复。
8.2.1 理解暂停状态
当活动监视器暂停时，所有窗格都会显示“已暂停”状态，并且恢复按钮可能无法使用。这会导致您无法查看任何服务器活动。
暂停状态通常是由于权限问题、远程连接限制或 SSMS 版本错误造成的，而不是有意暂停操作。
8.2.2 常见原因
活动监视器可能由于以下原因进入永久暂停状态：
- 最近添加的新窗格缺少“查看服务器状态”权限 SQL Server 版本
- 远程连接已禁用 SQL Server 例
- 特定系统查询的身份验证失败
- 特定 SSMS 版本（特别是 18.0 至 18.3 版本）中存在错误。
- 客户端和服务器之间的连接问题
8.2.3 解决步骤
要解决活动监视器暂停状态问题：
- 更新 SSMS： 下载并安装最新版本 SQL Server 从微软官网下载的 Management Studio 版本。后续版本修复了许多暂停状态的错误。
- 验证权限： 请确保您拥有查看服务器状态和查看任何定义的权限。
- 检查远程连接： 验证 SQL Server 实例允许远程连接：
EXEC sp_configure 'remote access';如果该值为 0，请管理员启用它。
- 重启 SSMS： 有时只需关闭所有窗口并重新启动即可。 SQL Server Management Studio 解决了这个问题。
- 使用 Windows 身份验证连接： 如果使用 SQL 身份验证，请尝试改用 Windows 身份验证，因为它有时可以绕过与身份验证相关的暂停问题。
8.3 使用活动监视器时的性能问题
如果活动监视器本身运行缓慢或导致服务器性能下降，则需要进行调整。
8.3.1 降低监控开销
为了最大限度地减少活动监视器的影响：
- 将刷新间隔增加到 30 秒或 1 分钟。
- 单击折叠按钮，关闭当前不使用的窗格。
- 当窗格折叠时，活动监视器不会查询其中的数据。
- 避免同时运行多个活动监视器实例。
- 在不主动调查问题时，请完全关闭活动监视器。
8.3.2 其他轻量级监测方法
如果活动监视器对您的环境来说资源消耗过大，请考虑其他替代方案：
- 直接查询车辆管理部门： 编写特定的 T-SQL 查询，仅检索所需信息。
- 使用 sp_WhoIsActive： 该存储过程经过高度优化，通常比活动监视器开销更低。
- 实施抽样： 定期安排 SQL Agent 作业，以捕获 DMV 数据的快照，并将结果存储在表中以供后续分析。
- 监控辅助副本： In 始终在线可用性组对可读的辅助磁盘而不是主磁盘运行活动监视器。
8.4 信息不准确或缺失
有时活动监视器显示的信息似乎不正确或不完整。
8.4.1 与车管所核实数据
当活动监视器结果可疑时，请直接查询底层动态管理视图 (DMV) 进行验证。例如，如果“进程”窗格显示没有阻塞，但用户报告有阻塞，请查询：
SELECT
blocking_session_id,
session_id,
wait_type,
wait_time,
wait_resource
FROM sys.dm_exec_requests
WHERE blocking_session_id != 0;
如果此查询显示活动监视器遗漏的阻塞，则说明存在显示问题。
8.4.2 理解数据刷新时序
请记住，“活动监视器”显示的是快照。如果查询的执行计划未从缓存中移除，则在两次刷新间隔之间运行的查询不会出现在“最近的高成本查询”列表中。
同样，“资源等待”窗格中的等待统计信息反映了自上次快照以来的累积情况。快速变化的工作负载每次刷新都可能显示不同的模式。
9. 高级活动监测技术
经验丰富的数据库管理员会以复杂的方式使用活动监视器，以提取最大的诊断价值。
9.1 结合多个面板进行根本原因分析
当您将多个窗格中的信息关联起来，以了解复杂的性能问题时，活动监视器的真正威力就显现出来了。
9.1.1 将等待与进程关联起来
当“资源等待”窗格显示某个类别的等待时间过长时，请使用“进程”窗格来确定哪些会话正在经历这些等待：
- 请注意累计等待时间较长的等待类别（例如，“锁定”）。
- 切换到“进程”窗格。
- 排序方式 等待类型 根据当前等待时间分组进行会话。
- 查找显示问题类别中等待类型的会话。
- 对于这些会话，请检查 等待资源 列用于查看涉及哪些数据库对象。
- 右键单击并选择 信息 查看查询文本。
这种关联性有助于你将问题从“我们有锁等待”转变为“这个特定的查询正在等待此表上的锁”。
9.1.2 将高成本查询与 I/O 问题关联起来
当“数据文件 I/O”窗格显示特定数据库的磁盘活动较高时：
- 注意哪些数据库文件的读取或写入速率较高（MB/秒）。
- 切换到最近的高成本查询。
- 排序方式 物理读取/秒 识别大量从磁盘读取数据的查询。
- 筛选或直观地识别针对数据库运行的高 I/O 查询。
- 检查这些查询的执行计划，是否存在表扫描或缺少索引导致过多的 I/O。
这种多窗格分析将症状（磁盘 I/O 过高）与原因（特定的低效查询）联系起来。
9.2 使用活动监视器进行容量规划
虽然活动监视器不存储历史数据，但您可以策略性地利用它进行容量规划观察。
9.2.1 识别高峰使用模式
在一天中的不同时间段监控服务器活动，以识别使用模式：
- 在已知的业务高峰时段开启活动监控。
- 请注意处理器时间百分比图表的峰值。
- 记录最大等待任务数。
- 观察高峰时段的每秒批处理请求数。
- 在“进程”窗格中记录最繁忙的数据库。
- 为了进行比较，请在非高峰时段重复上述步骤。
如果高峰时段处理器使用率持续超过 80%，则说明 CPU 容量已接近极限。同样，等待次数的增加也表明资源争用日益严重。
9.2.2 资源趋势分析
虽然“活动监视器”显示的是当前状态，但您也可以通过记录一段时间内的关键指标来快速查看趋势：
- 每天在同一时间截取概览窗格的屏幕截图
- 记录每个图表中的峰值
- 通过每周对比来识别增长趋势
- 注意观察平均处理器时间或 I/O 速率是否逐渐增加。
该手动趋势分析是对更复杂的监控解决方案的补充，有助于证明容量扩展的合理性。
9.3 记录绩效基准
建立基准性能指标有助于您识别性能何时下降。
9.3.1 采集基线指标
在已知表现良好的时期，记录活动监视器指标：
- 在正常业务运营期间（非高峰期或非高峰期）打开活动监视器。
- 记录概览窗格值：
- 典型处理器时间百分比范围
- 平均等待任务数
- 正常数据库 I/O 速率
- 典型批量请求/秒
- 注意“资源等待”窗格中显示等待时间最长的类别。
- 通常在“进程”窗格中记录活动进程的数量。
- 记录近期高成本查询的代表性查询执行指标。
请保存此基线文档，以便将来在调查性能问题时参考。
9.3.2 当前性能与基准性能比较
当出现性能问题时，请将当前活动监视器读数与您记录的基线进行比较：
- 处理器时间是否显著高于基准值？重点关注 CPU 密集型查询。
- 等待任务的数量是否达到基线水平的 2-3 倍？调查资源等待情况。
- I/O 是否显著升高？请检查“数据文件 I/O”窗格以及开销较大的查询。
- 高峰时段批量请求是否低于基线水平？请检查是否存在阻塞或连接问题。
通过对比，您可以确定发生了哪些变化，并有针对性地集中精力进行故障排除。
9.4 创建自定义监控工作流
针对常见调查场景制定系统化的工作流程，以确保进行彻底、可重复的分析。
9.4.1 逐步调查过程
当用户报告性能问题时，请遵循一致的工作流程：
- 快速健康检查： 打开活动监视器，扫描概览窗格图表，查找明显的异常情况。
- 检查是否存在阻塞： 展开“进程”窗格，在“阻止依据”列中筛选非空白项。
- 识别资源争用： 查看按等待时间排序的“资源等待”窗格。
- 查找高成本查询： 检查最近的高成本查询，按 CPU 使用时间排序，然后按执行次数排序，最后按读取次数排序。
- 关联 I/O 模式： 将昂贵的查询与数据文件 I/O 窗格活动进行交叉引用。
- 文件调查结果： 截取屏幕截图并记录相关的会话 ID、等待类型和查询详情。
- 深潜： 使用 Profiler 跟踪、执行计划分析和 DMV 查询对已识别的问题进行详细调查。
9.4.2 升级标准
制定判断何时应该升级问题、何时应该继续调查的标准：
- 立即上报： 阻塞链持续时间超过 5 分钟，处理器使用率超过 2 分钟，关键系统进程显示 SUSPENDED 状态。
- 通过分析升级问题： 反复出现代价高昂的查询，占用 CPU 50% 以上；I/O 响应时间持续过高，超过 50 毫秒；内存授权反复失败。
- 进一步调查： 临时等待在几分钟内解决，查询计划并非最优但性能可接受，轻微阻塞持续时间<30秒。
10. 不同环境下的活动监测 SQL Server 选项
活动监视器已经发展到 SQL Server 版本不断更新，每次发布都会带来改进，偶尔也会出现一些新问题。
10.1 活动监视器 SQL Server 2008年及以后
SQL Server 2008 年推出的现代活动监测器设计至今仍基本保持不变。
10.1.1 中引入的新功能 SQL Server 2008
此 SQL Server 2008 年活动监测器重新设计后，带来了显著的改进：
- 概览窗格中的图形化仪表板，包含实时图表
- 可展开/折叠的窗格界面取代了旧的仅网格视图
- “最近高成本查询”窗格显示汇总查询性能数据
- 用于监控每个文件磁盘活动的数据文件 I/O 面板
- 增强型资源等待窗格，带有等待分类功能
- 右键单击上下文菜单可执行诸如终止会话和启动分析器之类的进程操作。
- 可配置的刷新间隔，范围从 1 秒到 1 小时
这些变化将活动监视器从一个简单的进程列表转变为一个全面的监控仪表板。
10.1.2 变更 SQL Server 2005
SQL Server 2005 年的活动监视器功能要有限得多：
- 通过对象资源管理器中的“管理”文件夹访问，而不是通过工具栏访问。
- 单网格显示包含基本信息的流程列表
- 没有图形图表或多窗格
- 无需昂贵的查询或 I/O 监控
- 有限的等待统计信息
2008 年的重新设计是一次彻底的重新构想，而不是渐进式的改进。
10.2 活动监视器 SQL Server 2014/2016
SQL Server 2014 年和 2016 年对活动监视器的底层数据收集进行了逐步改进，但视觉上的变化不大。
10.2.1 改进和增强
这些版本的主要改进包括：
- 监控拥有数千个缓存计划的服务器时性能更佳
- “进程”窗格中增强的筛选功能
- 提高了等待统计信息汇总的准确性
- 更好地处理大型结果集的列排序和筛选
- 更高效的 DMV 查询可减少监控开销
核心接口保持一致 SQL Server 2008 年，保持管理员的熟悉度。
10.3 活动监视器 SQL Server 2019/2022
最近的 SQL Server 版本更新延续了 Activity Monitor 的发展，重点在于性能和稳定性。
10.3.1 最新特性和功能
SQL Server 2019 年和 2022 年活动监测器包括：
- 支持这些版本中引入的新等待类型
- 使用 WPF 技术提升 SSMS 的渲染性能
- 更好地处理大量活跃会话
- 增强与云 SQL 平台的兼容性
- 更准确的 CPU 和 I/O 指标
10.3.2 近期版本中的已知问题
SQL Server 2019 年引入了多个活动监视器漏洞：
- 永久暂停状态： 活动监视器经常进入暂停状态且无法恢复，尤其是在 SSMS 18.0-18.3 版本中。此问题已在更高版本的 SSMS 中修复。
- 远程连接失败： 某些配置会阻止在远程实例上打开活动监视器。解决方法包括启用特定的跟踪标志或使用较新版本的 SSMS。
- 权限问题： 新的系统视图需要额外的权限，但文档中没有明确说明，即使使用 VIEW SERVER STATE 也会导致显示空白。
使用 SSMS 时，请始终使用最新版本。 SQL Server 2019 年和 2022 年，以避免这些问题。
11. 实际应用案例和示例
实际案例演示了如何在常见的故障排除场景中有效地应用活动监视器。
11.1 案例研究：诊断运行缓慢的 Web 应用程序
开发团队报告称，他们的 Web 应用程序运行速度变得非常慢，页面加载时间从正常的 2-3 秒增加到 20-30 秒，令人无法接受。
11.1.1 初步调查概览窗格
打开“活动监视器”并查看“概览”窗格：
- 处理器时间百分比图表显示 CPU 使用率为 85-95%，明显高于正常的 30-40% 的基准值。
- 等待任务的数量在 10-20 个任务之间波动，而正常基线为 0-3 个任务。
- 数据库 I/O 活动适中，约为 50 MB/s。
- 每秒批量请求数低于预期，为每秒 100 个，而正常情况下工作时间内每秒请求数为 300-400 个。
这种模式表明CPU瓶颈导致资源争用，进而造成吞吐量下降。服务器虽然高负荷运转，但处理的请求数量却不多。
11.1.2 识别问题查询
展开“最近执行次数较多的查询”窗格，并按每分钟执行次数排序：
- 排名最高的查询每分钟执行 15,000 次。
- 右键单击并选择 编辑查询文本 检查查询。
- 该查询是一个简单的 SELECT 语句，用于检索单个用户记录：
SELECT * FROM Users WHERE UserId = @UserId. - 对于正常的应用程序使用情况，此查询不应该每分钟执行 15,000 次。
右键单击查询并选择 展示执行计划该计划显示对 Users 表进行表扫描，并警告 UserId 列缺少索引。
在“进程”窗格中按应用程序筛选，仅显示 Web 应用程序的连接。多个会话显示相同的查询重复运行。
11.1.3 分辨率和验证
问题源于两个方面：查询执行次数过多和缺少索引。解决方法：
- 创建缺失的索引：
CREATE NONCLUSTERED INDEX IX_Users_UserId ON Users (UserId); - 联系开发团队 关于执行次数过多的问题。调查显示应用程序代码中存在 N+1 查询问题，其中循环会检索列表中每个项目的用户详细信息。
- 修改应用程序 使用 IN 子句或表值参数将用户查找批量合并到单个查询中。
- 验证修复是否成功 部署后通过监控活动监视器发现，CPU 使用率降至 35-40%，每分钟执行次数降至 200-300 次，应用程序响应时间恢复正常。
11.2 案例研究：解决阻塞问题
用户反映订单录入系统会周期性地卡顿 30-60 秒，然后恢复正常运行。
11.2.1 检测阻塞链
在这些冻结事件发生期间打开活动监视器，并展开“进程”窗格：
- 排序方式 会话ID 查看所有已安排的会议。
- 多个会话显示数值。 被阻止 列，全部指向会话 ID 73。
- 第 73 场显示“1” 头部阻挡器 该栏目证实这是根本原因。
- 此 等待类型 对于阻塞的会话，显示 LCK_M_X，表示它们正在等待独占锁。
- 此 等待资源 该列显示阻塞发生在订单表中。
11.2.2 分析原因
右键单击会话 73 并选择 信息 查看命令：
UPDATE Orders
SET Status = 'Processing',
LastModified = GETDATE()
WHERE OrderId IN (SELECT OrderId FROM #TempOrders);
此更新是每小时运行一次的批处理作业的一部分。正在检查 登录 该列确认会话属于批处理服务帐户。
该查询在处理数千个订单时，会占用 Orders 表的锁。 等待时间 阻塞会话数稳步增加，证实了长时间运行的操作是问题所在。
11.2.3 实施修复
短期解决方案：
- 文件会话 73 的详细信息，包括查询文本和持续时间。
- 由于这是合法的批量处理，请允许更新自然完成。
- 完成后，确认阻塞的会话已清除，操作恢复正常。
已实施的长期解决方案：
- 重新安排批处理作业 在非高峰时段（凌晨 2 点至 4 点，而不是在营业时间内）运行。
- 修改批处理 以每次 100 条记录的小批量方式更新订单，并在批次之间释放锁定。
- 添加索引 在 OrderId 列上进行更新，以加快更新操作。
- 考虑快照隔离 减少读取操作的阻塞影响。
11.3 案例研究：识别过多的查询执行
数据库监控显示，过去一个月 CPU 使用率逐渐增加，但应用程序代码没有发生明显变化。
11.3.1 发现异常执行计数
打开“活动监视器”并查看“最近的高成本查询”窗格：
- 排序方式 执行次数/分钟 查看执行频率最高的查询。
- 排名最高的查询每分钟执行 37,000 次——远远高于其他任何查询。
- 右键单击并选择 编辑查询文本.
- 该查询检索产品类别信息：
SELECT CategoryId, CategoryName FROM ProductCategories WHERE CategoryId = @CategoryId; - 这个简单的查询应该速度很快且可以缓存，但它每分钟却执行数万次。
11.3.2 追溯到应用程序代码
在“进程”窗格中，找到执行此查询的会话：
- 注意 应用领域 该列显示“产品目录服务”。
- 右键单击其中一个会话并选择 跟踪过程 SQL Server 探查.
- SQL Profiler 显示该查询会以不同的 CategoryId 值快速连续地重复执行。
- 请联系负责 ProductCatalogService 的开发团队进行代码审查。
代码审查揭示了问题所在：最近的一项更改会检索带有类别的产品列表。对于结果集中的每个产品（通常超过 1,000 个），代码都会单独调用数据库来获取类别信息——这是一个典型的 N+1 查询问题。
11.3.3 优化应用程序
实施适当的修复措施：
- 修改应用程序查询 使用 JOIN 语句，在一次数据库调用中检索产品及其类别：
SELECT p.ProductId, p.ProductName, c.CategoryId, c.CategoryName FROM Products p INNER JOIN ProductCategories c ON p.CategoryId = c.CategoryId WHERE p.Active = 1; - 部署更新后的代码 并监控活动监视器。
- 验证修复是否成功： 类别查询的每分钟执行次数从 37,000 次下降到 100 次以下，整体 CPU 使用率下降了 40%。
- 记录吸取的教训 并与开发团队分享，以防止将来代码更改中出现类似问题。
12. 检测潜在的数据库损坏
虽然活动监视器并非专门设计用于检测数据库损坏，但其显示中的某些模式可能表明存在潜在的损坏问题，需要进一步调查。
12.1 潜在数据库损坏的症状
如果数据库损坏且正在被访问，您可能会偶尔看到以下情况：
1. 在“进程”窗格中：
- 会话卡在 SUSPENDED 状态，并出现异常等待类型
- 显示错误状态的进程
- 查询反复失败
2. 在“资源等待”窗格中：
- 异常的 I/O 相关等待类型可能表明磁盘存在问题（尽管这更有可能表明硬件问题而不是逻辑损坏）。
3. 近期高价查询：
- 如果查询反复尝试读取损坏的页面，则会导致物理读取次数异常高。
12.2 使用 DBCC CHECKDB 进行进一步检查
当活动监视器显示提示可能存在数据损坏的症状时，应立即运行 DBCC CHECKDB 命令来验证数据库完整性。此命令会扫描所有数据库页，验证校验和，并检查逻辑一致性错误。
要了解有关如何使用 DBCC CHECKDB 检查和修复数据库损坏的更多信息，请参阅我们的 DBCC CHECKDB 综合指南.
12.3 使用专业工具进行维修
如果 DBCC CHECKDB 确认数据库已损坏，您可以选择以下几种修复方法：
- 首选方法是从已知有效的备份中恢复。参见 我们关于如何备份和恢复的全面指南 SQL Server 数据库.
- 对于轻微的数据库损坏，使用带有 REPAIR_REBUILD 的 DBCC CHECKDB 命令可以解决问题。
- 对于没有近期备份的关键数据库，专业机构会提供备份服务。 SQL恢复软件 服务通常可以恢复内置修复选项无法恢复的数据。
13. 结论
SQL Server 活动监视器对于数据库管理员来说是一个非常宝贵的工具，它可以立即提供有关服务器性能的见解，并帮助快速有效地诊断问题。
13.1 要点总结
在本指南中，我们探讨了“活动监视器”如何帮助您了解和排查问题。 SQL Server 性能：
- 活动监视器通过有条理的图形界面，提供对进程、等待、查询和 I/O 的实时可见性。
- 五个窗格——概览、进程、资源等待、数据文件 I/O 和最近的高成本查询——分别提供了服务器活动的独特视角。
- 通过系统地进行活动监视器调查，可以解决诸如查询执行过多、阻塞链和 CPU 使用率过高等常见故障排除问题。
- 虽然活动监视器功能强大，但它也存在一些局限性，例如缺乏历史数据、等待类型分组以及监视开销，这些都会影响其适用性。
- 通过 DMV 查询、sp_WhoIsActive、扩展事件以及可能的第三方工具来补充活动监视器，可以创建全面的监视策略。
- 遵循最佳刷新间隔实践，在不使用时关闭活动监视器，并将多个窗格合并以进行关联，可以最大限度地发挥其价值，同时最大限度地减少其影响。
13.2 活动监视器作为工具包的一部分
活动监视器应作为性能调查的首选工具，而非唯一工具。它的优势在于能够在故障排除过程中提供即时可见性，帮助您快速确定数据库是否是瓶颈所在，并识别哪些具体方面需要深入调查。
您可以将“活动监视器”比作汽车的仪表盘——它会立即告诉您哪里出了问题，并帮助您确定大致的故障区域。就像汽车仪表盘不会告诉您发动机故障指示灯亮起的具体原因一样，“活动监视器”会指出问题所在，但并不总是能揭示问题的根本原因。要进行更深入的分析，则需要其他工具和专业知识。
将活动监视器集成到包含执行计划分析、等待统计跟踪、历史监控解决方案和性能最佳实践的更广泛工具包中。将其与适当的索引策略、查询优化技术和容量规划结合使用。
13.3 继续你的学习之旅
掌握活动监视器只是成为高效数据库管理员的第一步。继续提升您的技能，方法如下：
- 学习解读执行计划并识别低效操作
- 理解 SQL Server 等待统计数据及其影响
- 研究指标设计和优化技术
- 探索 SQL Server的架构及其查询处理方式
- 实践系统性的故障排除方法
- 利用扩展事件进行详细追踪的构建经验
- 了解事务隔离级别及其对性能的影响
使用活动监视器进行的每一次性能调查都能让你学到一些关于如何运作的新知识。 SQL Server 了解数据库的工作原理以及应用程序如何与数据库交互。记录你的发现，与同事分享知识，并建立常见问题解决方案库。
13.4 其他资源
利用以下宝贵资源拓展您的知识：
- 打开活动监视器 SQL Server 管理工作室（SSMS）
: 官方 SQL Server 关于如何打开活动监视器的文档 SQL Server 管理工作室（SSMS）。 - 活动监视器 ： 官方的 SQL Server 关于如何使用活动监视器的文档。
14. 常见问题 (FAQ)
问：什么是 SQL Server 活动监视器？
A: SQL Server 活动监视器是内置工具。 SQL Server 管理工作室，用于显示有关在系统上运行的进程的实时信息 SQL Server 实例及其对服务器资源的影响。它提供了一个图形化仪表板，包含五个窗格，分别显示服务器活动的不同方面，包括处理器使用率、等待任务、I/O 速率、活动会话和高成本查询。
问：如何在SSMS中打开活动监视器？
答：您可以通过四种方法打开活动监视器：（1）单击 SSMS 工具栏中的活动监视器图标；（2）右键单击您的…… SQL Server 在对象资源管理器中选择实例名称并选择 活动监视器（3）按压 按Ctrl + 其他 + A或者 (4) 配置 SSMS 通过以下方式自动启动它 工具 -> 可选项 -> 环境 -> 创业公司.
问：使用活动监视器需要哪些权限？
A：你需要 查看服务器状态 需要权限才能查看大多数活动监视器信息。对于“数据文件 I/O”窗格，您还需要以下权限之一： 创建数据库, 修改任何数据库 或 查看任何定义 权限。如果没有这些权限，活动监视器可能可以打开，但会显示空白窗格。
问：为什么我的活动监视器暂停或无法工作？
答：活动监视器暂停通常是由于权限问题、SSMS 版本过旧或远程连接被禁用造成的。解决方法：(1) 更新到最新 SSMS 版本；(2) 确认您拥有“查看服务器状态”权限；(3) 检查远程连接是否已启用。 SQL Server 例如，（4）重新启动 SSMS，以及（5）如果适用，尝试使用 Windows 身份验证而不是 SQL 身份验证进行连接。
问：活动监视器和 sp_WhoIsActive 有什么区别？
答：活动监视器是 SSMS 内置的图形化工具，提供用于不同监视方面的有序窗格。sp_WhoIsActive 是一个由社区创建的免费存储过程，它在单个结果集中返回详细的会话信息，并提供比活动监视器更具体的等待类型、阻塞详细信息和自定义选项。活动监视器更适合直观地查看，而 sp_WhoIsActive 则擅长脚本监视并提供更详细的信息。
问：活动监视器是否会影响服务器性能？
答：是的，活动监视器会产生可衡量的开销，因为它会在每次刷新间隔查询系统动态管理视图 (DMV)。刷新频率越低，影响越大——微软警告说，低于 10 秒的刷新间隔可能会影响服务器性能。不使用活动监视器时，请务必将其关闭；对于高负载的生产服务器，建议将刷新间隔设置为 30-60 秒。
问：我可以使用 T-SQL 获取活动监视器数据吗？
答：是的，活动监视器会查询系统动态管理视图，例如 sys.dm_exec_requests、sys.dm_exec_sessions、sys.dm_os_wait_stats 和 sys.dm_exec_query_stats。您可以使用 T-SQL 直接查询这些 DMV，以编程方式检索等效信息，从而实现自定义监视脚本和自动化数据收集。
问：默认刷新间隔是多少？
答：默认刷新间隔为 10 秒。您可以通过在“概览”窗格中的任意位置单击鼠标右键，然后选择“更改刷新间隔”来更改此设置。 刷新间隔用户可以从预设选项中选择：1 秒、5 秒、10 秒、30 秒、1 分钟或 1 小时。较低的间隔时间可以提供更实时的视图，但会增加监控开销。
问：如何让 SSMS 在启动时自动打开活动监视器？
A：通过 SSMS 选项配置自动启动：导航至 工具 -> 可选项 -> 环境 -> 创业公司，然后选择 打开对象资源管理器和活动监视器 来自 在启动时 下拉菜单。每次在 SSMS 中连接到服务器时，活动监视器都会自动打开。
问：活动监测器的局限性是什么？
答：主要限制包括：(1) 不具备历史数据存储或趋势分析功能；(2) 等待类型被归类，而非具体显示；(3) 某些等待类型（例如 CXPACKET）可能不会显示；(4) 时间点快照可能遗漏瞬态问题；(5) 监控开销可能会影响繁忙的服务器；(6) 缺乏主动监控的告警机制；以及 (7) 无法跨多个服务器聚合数据。 SQL Server 例如，对于这些需求，可以使用扩展事件、数据收集集或第三方监控工具来补充活动监视器。
关于作者
袁盛 是一位高级数据库管理员 (DBA)，拥有超过 10 年的 SQL Server 环境和企业数据库管理。他成功解决了金融服务、医疗保健和制造等行业的数百个数据库恢复场景。
袁专长于 SQL Server 数据库恢复 高可用性解决方案以及性能优化。他拥有丰富的实践经验，包括管理数TB数据库、实施Always On可用性组，以及为关键业务系统开发自动化备份和恢复策略。
通过他的技术专长和实践方法，袁致力于创建全面的指南，帮助数据库管理员和 IT 专业人员解决复杂的 SQL Server 高效应对挑战。他始终掌握最新 SQL Server 版本和微软不断发展的数据库技术，定期测试恢复场景以确保他的建议反映现实世界的最佳实践。
有关于的问题 SQL Server 恢复或需要额外的数据库故障排除指导？袁欢迎 反馈和建议 用于改进这些技术资源。