SQL Server 分析器：跟踪和故障排除 SQL Server [2026]

本指南适用于需要监控 SQL Server 实例、诊断性能问题并确保系统可靠性。DBA 将找到捕获跟踪、分析事件和实施监控策略的实用指南。
应用程序开发人员受益于了解他们的代码如何与 SQL Server。SQL Profiler 可帮助开发人员识别低效的查询、验证应用程序行为并调试与数据库相关的错误。
性能分析师和顾问将探索用于工作负载分析、容量规划和系统优化的高级技术。全面的跟踪配置、筛选和分析功能可实现全面的数据库性能评估。

2.理解 SQL Server Profiler 基础知识

2.1 如何 SQL Server 探查器工作原理

SQL Server Profiler 作为一个客户端应用程序运行，连接到在 SQL Server。创建跟踪时，数据库引擎会监视指定的事件并根据您的配置捕获它们。如果配置正确，跟踪引擎会收集事件数据，对服务器性能的影响最小。

底层 SQL Trace 基础架构在整个数据库引擎中使用轻量级事件钩子。当发生与您的跟踪定义匹配的事件时，引擎会捕获相关信息，并将其发送到 Profiler 接口或存储到文件或表中。这种架构允许灵活地收集数据，而无需修改应用程序代码。

2.2 关键概念和术语

2.2.1精选活动

事件代表特定事件 SQL Server 跟踪引擎可以捕获的事件。每个事件对应特定的数据库操作或系统活动。 SQL Server Profiler 将事件组织成逻辑类别，以便于配置。

常见的事件类别包括用于查询执行的 TSQL、用于过程调用的存储过程、用于并发监控的锁以及用于异常跟踪的错误和警告。选择合适的事件决定了跟踪捕获的信息，并直接影响跟踪的实用性和性能开销。

了解事件类型有助于您配置有效的追踪。RPC:Completed 事件捕获远程过程调用完成情况，SQL:BatchCompleted 事件跟踪临时查询批次，Lock:Deadlock 事件识别死锁发生情况。请选择与您的特定故障排除或监控目标相符的事件。

2.2.2 数据列

数据列定义了跟踪捕获的每个事件的信息。常见列包括：TextData（表示实际 SQL 语句）、Duration（表示执行时间）、CPU（表示处理器利用率）、Reads（表示逻辑磁盘读取）和 Writes（表示逻辑磁盘写入）。

必需的列因用例而异。性能故障排除通常需要“持续时间”、“CPU”、“读取次数”和“写入次数”列。安全审计需要“登录名”、“数据库名称”和“对象名称”列。应用程序调试则受益于“应用程序名称”、“SPID”和“错误”列。

仅选择必要的列可以减少跟踪开销并简化分析。除非特别需要，否则请避免捕获所有可用列。每增加一列都会增加收集和处理的数据量，这可能会影响服务器性能。

2.2.3过滤器

过滤器会根据指定的条件限制跟踪捕获的事件。正确配置的过滤器可以显著减少跟踪量，使分析更易于管理，并最大限度地降低性能影响。过滤器会在捕获之前评估事件数据，从而避免不必要的数据收集。

常见的筛选条件包括：DatabaseName（用于关注特定数据库）、ApplicationName（用于隔离特定应用程序）、Duration（用于仅捕获慢速操作）以及 LoginName（用于跟踪特定用户）。组合使用多个筛选条件可以创建精确的跟踪定义，从而准确捕获您所需的信息。

对于生产环境而言，注重性能的过滤至关重要。请始终按数据库名称或应用程序名称进行过滤，以避免捕获系统活动。设置最小持续时间阈值以忽略快速执行的查询。请谨慎使用文本数据 (TextData) 过滤器，因为它们需要进行字符串比较，这会增加开销。

2.2.4 跟踪模板

跟踪模板为常见场景提供预配置的事件、列和过滤器选择。 SQL Server Profiler 包含几个内置模板，可用作tar用于创建跟踪的配置点。自定义模板可保存您的配置，以便在多个跟踪会话中重复使用。

标准模板捕获一组适用于基本监控的常规事件。TSQL 模板专注于以最小开销执行查询。优化模板专门收集用于数据库引擎优化顾问分析的事件。每个模板都在信息捕获和性能影响之间取得平衡。

创建自定义模板可以节省时间并确保跟踪会话之间的一致性。使用您偏好的事件、列和筛选器配置跟踪，然后将其保存为模板。当您反复排查类似问题时，自定义模板尤为有用。

3. 获得 Star与 SQL Server 探查

3.1 系统要求和先决条件

SQL Server Profiler 捆绑了 SQL Server Management Studio 并支持所有当前维护 SQL Server 版本，从 SQL Server 2016 2022来。

权限要求决定谁可以创建和运行跟踪。sysadmin 固定服务器角色的成员可以不受限制地访问 SQL Server 分析器功能。对于非系统管理员用户，ALTER TRACE 权限授予创建和管理跟踪的能力。

跟踪远程服务器时需要考虑网络因素。客户端跟踪需要您的工作站与 SQL Server 实例。中断的连接会停止客户端跟踪，可能会丢失捕获的数据。服务器端跟踪完全在数据库服务器上运行，从而避免了此限制。

3.2 如何启动 SQL Server 探查

3.2.1小号tar婷从 SQL Server 管理工作室（SSMS）

请按照以下步骤启动 SQL Server SSMS 的分析器：

可选 SQL Server Management Studio 并连接到任何 SQL Server 实例。
点击工具顶部菜单栏中的菜单。
从我们的数据库中通过 UL Prospector 平台选择 SQL Server 探查 从下拉菜单中选择。
此 SQL Server Profiler 应用程序在新窗口中打开。

3.2.2小号tar从 Windows Star菜单

Access SQL Server 使用以下步骤直接从 Windows 进行 Profiler：

单击 Windows 开始按钮。
类型 SQL Server 探查 在搜索框中。
从我们的数据库中通过 UL Prospector 平台选择 SQL Server 探查 从搜索结果中。
应用程序启动时没有活动连接。

或者，通过 Start 菜单rar奇：

打开开始菜单。
找到 Microsoft SQL Server 工具 文件夹中。
展开文件夹并单击 SQL Server 探查.

3.2.3 连接到 SQL Server 实例

发射后 SQL Server Profiler，按照以下步骤建立连接：

点击文件在菜单栏中。
从我们的数据库中通过 UL Prospector 平台选择 新踪迹 从下拉菜单中选择。
此 连接到服务器 对话框出现。
在 服务器名称 领域。
选择 Windows身份验证 or SQL Server 认证.
如果使用 SQL Server 身份验证，输入您的登录凭据。
点击互动建立连接。

对于远程连接，请指定完整的服务器名称，包括实例名称（如果适用）cable. 对于命名实例，请使用 SERVERNAME\INSTANCENAME 格式。如果连接尝试失败，请验证网络连接和防火墙设置。

4.创建和配置 SQL Server 痕迹

4.1 使用模板创建您的第一条轨迹

使用以下步骤创建您的第一个跟踪：

正式上线 SQL Server 探查器。
点击文件 -> 新踪迹 并连接到您的 tar获取服务器。
此 追踪属性 对话框出现。
在 轨迹名称 领域。
从中选择一个模板 使用模板 落下。
选择 标准（默认） 用于常规监控的模板。或者用于其他用途的另一个模板。该模板为常见场景提供了预配置的事件、列和过滤器。
点击运行是的tart 立即捕捉事件。

4.2 自定义您的轨迹

很多时候，模板无法满足您的要求。在这种情况下，您可以完全自定义您的跟踪：

在 追踪属性 对话。
点击空白模板来自 使用模板 落下。
点击 活动选择 选项卡，现在您可以根据需要自定义所有事件、数据列和过滤器。我们将在以下部分中讨论它们。

4.3 选择要捕获的事件

您可以在 活动选择 标签：

点击 + 图标来展开它。
单击事件旁边的复选框以选择它。

4.3.1 了解事件类别

SQL Server Profiler 将事件按类别进行逻辑分组。存储过程类别包含存储过程执行事件，包括 SP:Starting、SP:Completed 和 SP:StmtCompleted。这些事件跟踪存储过程调用和过程中的各个语句的执行。

TSQL 类别使用 SQL:BatchS 等事件捕获临时查询执行tarting 和 SQL:BatchCompleted。这些事件跟踪直接提交给 SQL Server 存储过程之外。

“锁”类别监视与并发相关的事件，包括“锁:获取”、“锁:释放”、“锁:死锁”和“锁:超时”。使用这些事件来诊断影响应用程序性能的阻塞和死锁问题。

错误和警告类别捕获异常事件，包括异常、注意和用户错误消息。这些事件有助于识别应用程序错误和 SQL Server 跟踪会话期间的警告。

4.3.2 为您的场景选择正确的事件

性能监控需要捕获资源消耗的事件。选择“RPC:Completed”和“SQL:BatchCompleted”来跟踪查询执行情况。添加“Duration”、“CPU”、“Reads”和“Writes”列来衡量资源使用情况。这些事件为识别性能瓶颈奠定了基础。

安全审计需要跟踪身份验证和授权的事件。选择“审计登录”、“审计注销”、“审计登录失败”和“对象：已打开”来监控数据库访问。添加“登录名”、“数据库名称”和“对象名称”列，以识别哪些人访问了哪些资源。

全面的事件捕获功能可有效提升调试场景的效率。您可以捕获存储过程事件、SQL 批处理事件和错误事件，从而追踪完整的执行流程。此外，还可以使用 SPID、应用程序名称和 Host命名列以将事件与特定会话关联起来。

4.4 配置数据列

默认情况下，当您选择一个事件时，其所有数据列都将被选中（勾选）。您可以取消选择不必要的列，以减少开销并简化分析：

每个跟踪的必要列包括 EventClass（用于识别事件类型）、TextData（用于捕获实际的 SQL 语句）、LoginName（用于识别执行用户）和 StartTime 为事件发生的时间戳。这些列为每个捕获的事件提供基本背景信息。

与性能相关的列用于衡量资源消耗。“持续时间”表示事件耗时（以微秒为单位）。“CPU”显示处理器时间（以毫秒为单位）。“读取次数”统计逻辑页面读取次数。“写入次数”跟踪逻辑页面写入次数。这些指标用于识别需要优化的资源密集型操作。

安全和审计列跟踪数据访问模式。DatabaseName 标识访问了哪个数据库。ObjectName 指定所涉及的表或对象。ApplicationName 揭示了哪个应用程序发起了该活动。这些列共同提供了全面的审计线索。

4.5 设置滤波器以降低噪声

4.5.1 通用过滤条件

使用以下方法配置过滤器：

打开 追踪属性 对话。
点击 活动选择 标签。
点击 列过滤器 右下角的按钮。
从左侧列表中选择一列。
在右侧面板中配置过滤条件。
点击 OK 应用过滤器。

应用名称过滤器会将活动与特定应用隔离。展开过滤器对话框中的“应用名称”列，在喜欢领域，以及 SQL Server Profiler 仅捕获来自该应用程序的事件。在排查特定应用程序的问题时，此过滤器非常有用。

数据库名称筛选器可将捕获限制在特定数据库。按数据库名称筛选可排除系统数据库活动，并专注于应用程序数据库。在喜欢 or 等于字段取决于您是否需要通配符匹配。

持续时间过滤器仅捕获运行缓慢的操作。在 大于或等于 字段。例如，设置 Duration >= 1000 仅捕获持续时间超过一秒的事件，从而过滤掉快速执行的查询。

用户名过滤器可追踪特定用户的活动。通过登录名进行过滤，即可监控特定数据库用户。此方法有助于识别哪些用户执行了有问题的查询或访问了敏感数据。

4.4.2 过滤最佳实践

有效的过滤可以在数据捕获和性能影响之间取得平衡。请始终至少应用一个过滤器，以防止捕获过多的系统活动。DatabaseName 和 ApplicationName 过滤器应该是您的首选。tarm 的点ost 痕迹。

在生产环境中，避免使用过于宽泛的追踪。未经过滤的追踪会捕获海量数据，这可能会降低服务器性能，并使分析变得不切实际。设置具体的过滤条件， tar获得故障排除目标。

在部署到生产环境之前测试过滤器。首先针对开发或测试环境运行跟踪，以验证过滤器是否能够捕获预期事件，且不会产生过多开销。根据捕获的数据量调整过滤条件。

4.5 使用跟踪模板

4.5.1 内置模板概述

标准模板提供均衡的事件捕获功能，适用于常规监控。它包含常见的查询执行事件、存储过程调用和基本的错误跟踪。如果您需要全面的可视性，但又不知道具体要查找哪些内容，请使用此模板。

TSQL 模板专注于查询执行，并尽量减少事件选择。它捕获 SQL:BatchCompleted 和 RPC:Completed 事件，其中包含性能分析所需的必要列。此模板的开销低于标准模板。

优化模板可优化数据库引擎优化顾问分析的事件选择。它捕获工作负载分析和索引建议所需的事件和列。在准备用于自动性能优化的跟踪时，请使用此模板。

TSQL_Replay 模板包含跟踪重放功能所需的所有事件和列。它捕获全面的执行详细信息，使您能够在测试环境中重现捕获的工作负载。由于数据收集量大，此模板会生成更大的跟踪文件。

4.5.2 创建自定义模板

按照以下步骤创建自定义模板：

点击文件 -> 模板 -> 新模板……
在 新模板名称 领域。
可选地，检查 基于现有模板的新模板 如果您不想从头开始构建，请选择现有模板：
点击 事件选择 选项卡，使用您想要的事件、列和过滤器自定义跟踪模板，就像您用正常的轨迹做.
点击 已保存 保存模板。

导出模板以便与团队成员共享或用于备份：

点击文件 -> 模板 -> 导出模板.
选择您想要导出的模板。
导航到您想要的保存位置。
输入文件名并单击 已保存.
共享 *.tdf 文件 (SQL Server Profiler 模板文件）与其他 SQL Server Profiler 用户。

4.6 保存跟踪输出

默认情况下， SQL Server Profiler 会在跟踪窗口中显示事件，但不会保存它们。您可以选择将跟踪数据保存到文件或表中 追踪属性 创建新轨迹时出现的对话框。

4.6.1 保存到文件

在 追踪属性 对话框，检查 保存到文件.
单击文件夹图标打开文件浏览器。
导航到您想要的保存位置。
输入扩展名为 .trc 的文件名。
点击 已保存.
米 设置最大文件大小 限制单个文件的大小。
启用 启用文件翻转 创建多个文件。
可选启用 服务器处理跟踪数据 用于服务器端跟踪。

文件大小管理可防止磁盘空间耗尽。根据可用磁盘空间和预期跟踪时长，将最大文件大小设置为合理的值，例如 500 MB 或 1 GB。当达到大小限制时，文件滚动更新功能会自动创建新文件，并在文件名后附加一个数字。

4.6.2 保存到表

在 追踪属性 对话框，检查 保存到表.
此 目标表 对话框出现。
从中选择服务器 服务器 落下。
从中选择数据库 数据库 落下。
选择现有表或在表领域。
点击 OK 进行确认。
可选设置 设置最大行数 限制表格大小。

保存到表时需要考虑性能因素。与文件存储相比，表存储会带来额外的开销，因为 SQL Server 必须通过存储引擎写入跟踪数据。当需要使用 T-SQL 立即查询跟踪数据时，请使用表存储。

对于基于表的跟踪数据，数据保留至关重要。设置最大行数限制，以防止表变得过大。定期归档或删除旧的跟踪数据以保持性能。考虑对大型跟踪表进行分区，以提高可管理性。

5. 运行和管理 SQL Server 痕迹

5.1小号tar暂停和停止跟踪

使用工具栏按钮管理跟踪执行：

绿色的开始按钮开始根据您的配置捕获事件。
点击暂停节奏rar随时暂停数据收集而不会丢失连接。
点击 Stop 停止 结束跟踪并关闭连接。

通过菜单项：

通过右键单击跟踪窗口中的任何条目：

跟踪生命周期管理会影响服务器资源。活动跟踪会消耗与捕获事件量成正比的内存和处理能力。在不需要监控的时间段内暂停跟踪以减少开销。分析完成后，请完全停止跟踪以释放资源。

客户端跟踪需要活动的 Profiler 连接。关闭 SQL Server Profiler 窗口会立即停止客户端跟踪。请最小化 Profiler 窗口（而不是关闭它），以便在使用其他应用程序时保持跟踪运行。

5.2 实时跟踪监控

在主跟踪窗口中监控捕获事件的发生情况。每行代表一个事件，每列显示事件属性。网格会在跟踪活动期间持续更新，显示事件的ost 默认情况下，最近事件位于底部。

通过观察事件频率和特征来识别模式和问题。持续时间较长的事件表明存在性能问题。频繁的错误事件表明应用程序存在问题。异常的登录活动可能预示着安全问题。实时监控能够立即响应新出现的问题。

滚动浏览已捕获的事件以检查特定事件。点击任意行即可选择事件并查看其完整详情。双击事件即可打开显示所有列值的详细属性对话框。使用滚动锁定功能可防止在查看历史事件时自动滚动。

5.3 管理多个并发跟踪

同时运行多个跟踪功能可为复杂的监控场景提供灵活性。您可以为数据库活动的不同方面创建单独的跟踪，例如，一个跟踪用于性能监控，另一个跟踪用于安全审计。每个跟踪均独立运行，并具有各自的配置。

在多条跟踪记录下，资源分配变得至关重要。每条活动跟踪记录都会消耗内存、CPU 以及潜在的磁盘 I/O。请限制并发跟踪记录的数量，并确保每条跟踪记录使用合适的筛选器，以最大程度地降低开销。在运行多条跟踪记录时，请监控服务器性能。

协调跟踪时间，避免高开销跟踪重叠。如果可能，请在活动较少的时段运行资源密集型跟踪。将不同的跟踪安排在不同的时间，而不是同时运行所有跟踪。

5.4 客户端跟踪与服务器端跟踪

默认情况下，新创建的跟踪是客户端跟踪，需要来自 SQL Server Profiler 连接到数据库服务器。如果连接断开，跟踪将立即停止ost 或 Profiler 已关闭。

您还可以创建服务器端跟踪，它完全在 SQL Server 实例，无需活动 Profiler 连接。服务器端跟踪即使在关闭后仍会继续运行 SQL Server Profiler，将数据写入指定的文件位置。

要创建服务器端跟踪：

单击文件->新建跟踪...
在 追踪属性 对话框，检查 保存到文件
设置文件位置和其他设置。
启用 服务器处理跟踪数据 创建服务器端跟踪。

不同追踪类型对性能的影响差异很大。客户端追踪必须通过网络将数据传输到 Profiler 接口，这会增加延迟和带宽消耗。服务器端追踪的开销较小，因为数据直接写入服务器磁盘。

使用客户端跟踪进行临时故障排除、快速诊断ostic 会话以及需要即时视觉反馈的情况。对于生产监控、长时间运行的捕获以及需要无人值守操作的场景，请选择服务器端跟踪。

6.分析 SQL Server 探查器数据

6.1 打开并查看已保存的轨迹

使用以下步骤加载已保存的跟踪文件：

正式上线 SQL Server 探查器。
点击文件 -> 可选 -> 跟踪文件.
导航到跟踪文件位置。
选择 .trc 文件并单击可选.
跟踪数据加载到主窗口。

按照以下步骤加载跟踪表：

点击文件 -> 可选 -> 跟踪表.
连接到服务器host跟踪表。
从中选择数据库 数据库 落下。
从中选择表表落下。
点击 OK 加载数据。

6.2 筛选和搜索轨迹数据

6.2.1 Post-捕获过滤

使用以下步骤将过滤器应用于加载的跟踪数据：

点击编辑 -> 找到最适合您的地方 或按 按Ctrl + F.
在 查找内容 领域。
从中选择要搜索的列在看落下。
点击 查找下一个“ 找到匹配的事件。

基于列的过滤功能可优化显示的数据，无需重新捕获事件。右键单击任意列标题，然后从上下文菜单中选择过滤选项。输入过滤条件即可仅显示匹配的行。此方法可隐藏不相关的事件，从而加快分析速度。

6.2.2 查找特定事件

搜索功能可帮助您在大型跟踪文件中定位特定事件。使用“查找”对话框可按文本内容、事件类型或列值进行搜索。正则表达式可在需要时启用复杂的搜索模式。

为重要事件添加书签，以便在分析过程中快速参考。右键单击感兴趣的事件，然后选择书签选项即可进行标记。使用键盘快捷键或菜单命令在书签之间导航，方便比较相关事件。

6.3 分组和聚合事件

按列值对事件进行分组，以识别模式并汇总活动。右键单击任意列标题，然后选择 按此列分组 整理事件。分组视图可将类似事件折叠在一起，让您更轻松地查看整体模式。

聚合视图提供跟踪数据的统计摘要。按文本数据分组可查看每个查询的执行次数。按登录名分组可查看每个用户的活动摘要。聚合功能可以揭示详细事件列表中难以立即发现的模式。

展开和折叠组以深入了解特定类别。点击组标题旁边的加号和减号图标可显示或隐藏分组事件。此隐藏rar逻辑视图有利于自上而下的分析，tar使用高级模式并深入细节。

6.4 从跟踪中提取 SQL 查询

按照以下步骤从跟踪数据中提取查询：

在跟踪网格中找到感兴趣的查询。
单击该行以选择事件。
在底部面板中查看完整的查询文本。
媒体中心 按Ctrl + A 选择所有查询文本。
媒体中心 按Ctrl + C 复制查询文本。
将查询粘贴到 Management Studio 中以进行进一步分析。

通过按性能列排序来识别有问题的查询。点击“时长”列标题可按执行时间排序。最慢的查询会根据排序方向显示在顶部或底部。同样，按 CPU、读取次数或写入次数排序可识别占用大量资源的操作。

通过将查询从跟踪复制到查询窗口来导出测试。修改提取的查询以测试优化策略。比较原始版本和优化版本之间的执行计划和性能指标。

6.5 关联事件并理解执行流程

亲子事件关系显示执行速度rar关键字。SQL：BatchStarting 事件父 SQL:StmtStar执行事件，这些事件又构成了过程执行事件的父级。理解这些关系有助于追踪代码的完整执行路径。

事务跟踪跨时间关联相关事件。使用 SPID 列按会话对事件进行分组。在会话中，事件按时间顺序发生，显示操作的顺序。此视图揭示了不同操作在事务内的交互方式。

通过检查共享列值来关联事件。具有相同 SPID 的事件发生在同一会话中。具有相同 ApplicationName 的事件来自同一应用程序。使用这些关联来理解复杂的执行场景。

7。常见 SQL Server 分析器用例

7.1 性能故障排除

7.1.1 识别慢查询

使用以下配置捕获慢查询：

使用 TSQL 模板。
在 活动选择 标签，验证 SQL：批处理完成 以及 RPC：已完成 被选中。
点击 列过滤器.
从我们的数据库中通过 UL Prospector 平台选择 修读年限 从列列表中。
输入 1000000 大于或等于 字段来捕获耗时超过 1 秒的查询。
点击 OK 和start 踪迹。
在使用高峰期运行跟踪。
停止跟踪并按持续时间排序以确定最慢的查询。

基于持续时间的分析揭示了执行时间模式。按“持续时间”列对捕获的事件进行排序，以便优先查看运行时间最长的操作。检查这些事件的“文本数据”列，以识别导致延迟的实际查询。

CPU 和 I/O 密集型查询需要不同的优化方法。按 CPU 列排序可查找需要算法改进的处理器密集型查询。按读取或写入列排序可识别可从索引或查询重写中受益的 I/O 密集型查询。

7.1.2 检测阻塞和死锁

按照以下步骤配置阻塞检测：

创建新的轨迹。
在 活动选择 选项卡，展开锁.
从我们的数据库中通过 UL Prospector 平台选择 锁：死锁 以及 锁：死锁链.
拓展 错误和警告.
从我们的数据库中通过 UL Prospector 平台选择 阻塞进程报告.
包括列： SPID, 文本数据, 数据库名称, 登录名.
Star跟踪并监视锁定事件。

锁事件监控揭示了影响应用程序性能的并发问题。Lock:Deadlock 事件指示何时 SQL Server 检测并解决死锁情况。锁：死锁链事件显示涉及死锁的进程。

死锁图提供死锁场景的可视化表示。当发生死锁事件时，TextData 列会包含描述死锁的 XML 文件。复制此 XML 文件并在 SQL Server Management Studio 查看图形死锁图，显示哪些进程相互阻塞。

7.1.3 查找缺失的索引

使用以下步骤捕获索引分析的工作负载：

使用调音模板。
配置跟踪以保存到文件。
在代表性工作负载期间运行跟踪。
收集至少几个小时的活动。
停止跟踪并保存文件。
启动数据库引擎优化顾问。
选择跟踪文件作为工作负载源。
运行分析以接收索引建议。

与数据库引擎优化顾问集成可自动执行索引推荐。优化顾问会分析捕获的工作负载，并建议可提升性能的索引。在实施之前，请仔细审查这些建议，并考虑存储开销和维护成本。osts.

7.2 应用程序故障排除

7.2.1 调试应用程序错误

使用此配置跟踪应用程序错误：

创建新的轨迹。
拓展 错误和警告 在事件选择选项卡中。
从我们的数据库中通过 UL Prospector 平台选择 特殊课程, 用户错误消息和注意.
包括列：误差, 文本数据, 应用名称, SPID.
筛选条件 应用名称 专注于您的申请。
Star跟踪并重现错误场景。
审查捕获的错误事件以进行诊断ostic 信息。

错误跟踪揭示了应用程序中经常隐藏的异常细节。“错误”列包含 SQL Server 错误编号。TextData 列显示错误消息以及导致错误的查询。Severity 列指示错误严重程度级别。

异常监控可捕获运行时问题，包括约束违规、权限错误和超时事件。将错误事件与之前的查询事件关联起来，以了解触发异常的原因。

7.2.2 跟踪应用程序到数据库的通信

按照以下步骤监控应用程序活动：

使用 标准版 模板。
点击 列过滤器.
从我们的数据库中通过 UL Prospector 平台选择 应用名称 并在喜欢领域。
可选筛选条件 Host名称 隔离特定的服务器。
Star应用程序运行期间的跟踪。
查看捕获的事件以查看所有数据库交互。

应用程序名称过滤将查询与特定应用程序隔离。 SQL Server 通过连接字符串设置应用程序名称，从而轻松在多应用程序环境中跟踪单个应用程序。请确保您的连接字符串包含“应用程序名称”参数，以便进行有效过滤。

连接跟踪显示会话生命周期，包括登录、查询执行和注销事件。监控连接创建率以识别连接池问题。过多的连接流失表明潜在的应用程序配置问题。

7.2.3 验证应用程序行为

使用跟踪分析验证预期的应用程序行为。捕获业务事务期间的所有数据库操作，并验证正确的查询是否按正确的顺序执行。将实际捕获的查询与预期行为进行比较，以识别差异。

参数验证可确保应用程序向存储过程和参数化查询传递正确的值。检查捕获的查询文本，以验证参数值是否符合预期。错误的参数通常会导致逻辑错误，从而导致错误的业务结果。

7.3 安全审计

7.3.1 监控登录尝试

使用以下步骤配置登录监控：

创建新的轨迹。
拓展 安全审计 在事件选择选项卡中。
从我们的数据库中通过 UL Prospector 平台选择 审计登录, 审计注销和 审计登录失败.
包括列： 登录名, Host名称, 应用名称, Star时间.
Start 跟踪来监视身份验证活动。
审查失败的登录事件以发现潜在的安全问题。

成功和失败的登录可提供全面的身份验证跟踪。“审核登录”事件记录成功的身份验证尝试，包括用户身份和来源信息。“审核登录失败”事件指示可能表示攻击或配置问题导致的登录尝试失败。

身份验证跟踪可以揭示数据库访问的模式。监控登录频率以检测异常活动。多次登录失败后再次成功登录可能表明凭据已被盗用。从意外位置登录失败的情况需要调查。

7.3.2 跟踪数据访问和修改

使用此配置监控数据访问：

创建新的轨迹。
拓展 安全审计.
从我们的数据库中通过 UL Prospector 平台选择 审计数据库对象访问.
包括列： 对象名, 登录名, 文本数据, 数据库名称.
筛选条件 对象名 监控特定的敏感表。
Start 跟踪以捕获访问尝试。

SELECT、INSERT、UPDATE、DELETE 跟踪提供全面的数据修改审计。使用适当的过滤器捕获 SQL:BatchCompleted 事件，以监控所有数据访问操作。按 ObjectName 或 TextData 过滤，以重点关注敏感表。

敏感数据访问需要仔细监控，以确保符合安全策略。专门为包含个人信息、财务数据或其他机密信息的表创建跟踪。定期审查访问模式，以识别不当的数据访问。

7.3.3 识别未经授权的活动

通过分析捕获的跟踪记录中的查询模式来检测可疑活动。查找与正常应用程序行为不符的异常查询。不包含 WHERE 子句且检索整个表的 SELECT 语句可能表明存在数据泄露尝试。

权限提升尝试会显示为权限错误或执行管理命令的尝试。监控尝试访问系统表、修改服务器配置或创建特权帐户的查询。筛选错误事件并检查 TextData 列中是否存在可疑活动。

7.4 容量规划和工作负载分析

通过捕获正常运行期间的代表性工作负载来建立基准。在典型工作时间内运行跟踪，以了解标准活动模式。将这些跟踪保存为性能基准，以供将来比较。

峰值使用情况识别可揭示系统何时承受最大负载。捕获不同时间段的轨迹，包括工作时间、批处理时段以及下班后的活动。分析事件计数和资源消耗，以识别峰值时段。

资源利用率模式源自工作负载分析。按时间间隔分组事件，了解全天的活动分布情况。计算聚合 CPU、磁盘 I/O 和持续时间指标，量化资源消耗。利用这些数据规划容量升级或发现优化机会。

8。高级 SQL Server 分析器技术

8.1 使用 T-SQL 创建服务器端跟踪

8.1.1 使用 sp_trace_create 和相关过程

使用 T-SQL 存储过程以编程方式创建服务器端跟踪。此方法可实现自动跟踪创建和管理，无需 SQL Server Profiler 的图形界面。

使用此示例代码定义服务器端跟踪：

声明跟踪 ID 和文件路径的变量。
调用 sp_trace_create 来创建新的跟踪。
使用 sp_trace_setevent 添加事件和列。
（可选）使用 sp_trace_setfilter 来配置过滤器。
调用 sp_trace_setstatus 来tart 踪迹。

sp_trace_create 过程初始化一个新的跟踪定义。指定输出文件路径、最大文件大小和滚动更新选项。该过程返回一个跟踪 ID，用于后续过程调用以配置跟踪。

使用 sp_trace_setevent 过程添加事件。为要捕获的每个事件-列组合指定跟踪 ID、事件 ID 和列 ID。多次调用此过程以构建完整的跟踪配置。

使用 sp_trace_setfilter 过程配置过滤器。指定跟踪 ID、列 ID、逻辑运算符、比较运算符和过滤值。多个过滤器调用组合起来可以创建复杂的过滤条件。

Star通过调用状态值为 1 的 sp_trace_setstatus 来停止跟踪。通过调用状态值为 0 的相同过程来停止跟踪。通过调用状态值为 2 来删除跟踪定义。

8.1.2 服务器端跟踪的优点

降低客户端开销使服务器端跟踪成为生产监控的理想选择。数据库服务器处理所有跟踪操作，而无需消耗客户端计算机资源。将事件传输到客户端应用程序不会消耗网络带宽。

自动执行可实现无人值守的跟踪收集。即使没有客户端连接，服务器端跟踪在创建后仍会继续运行。通过以下方式安排跟踪创建： SQL Server 用于自动监控的代理作业。

服务器端处理可降低性能影响。事件直接写入磁盘，无需额外的序列化或网络传输。缓冲区管理可优化磁盘 I/O，从而提高整体性能。

8.2 跟踪重放功能

8.2.1 捕获跟踪以进行重放

按照以下步骤创建可重放的跟踪：

使用 TSQL_重放 模板。
验证是否已选择所有必需的事件和列。
配置跟踪以保存到文件。
在您想要捕获的工作负载期间运行跟踪。
停止跟踪并保存文件。

必需的事件和列可确保跟踪重放的完整。TSQL_Replay 模板包含所有必需的事件类型和数据列。缺少必需元素会导致重放失败，因此在进行重放捕获时，请务必使用此模板。

8.2.2 重放痕迹

使用以下步骤重放捕获的工作负载：

In SQL Server 分析器，点击文件 -> 可选 -> 跟踪文件.
选择可重放的跟踪文件。
点击重播 -> 开始.
连接到 tar在重播对话框中获取服务器。
配置重播选项，包括重播顺序和时间。
点击 OK 开始重播。
在状态窗口中监控重播进度。

重播配置选项控制如何 SQL Server Profiler 会重现捕获的工作负载。按捕获顺序重放事件以保持时间关系。请配置是保持原始时间还是尽快重放事件。

8.2.3 跟踪重放的用例

通过重现真实的工作负载，负载测试可以从轨迹重放中获益。捕获生产工作负载轨迹，并在测试系统中重放，以验证真实使用模式下的性能。调整并发设置以模拟不同的负载级别。

环境迁移验证确保新系统能够处理现有工作负载。从当前生产系统捕获跟踪信息，并在新硬件或更新的硬件上重放。 SQL Server 版本。比较性能指标以验证迁移不会降低性能。

测试场景包括代码更改后的回归测试、验证优化器更改 SQL Server 版本和压力测试硬件配置。Replay 提供一致、可重复的工作负载，以实现可靠的测试。

8.3 将 SQL Profiler 与数据库引擎优化顾问集成

通过捕获包含相应事件的跟踪来为数据库引擎优化顾问创建工作负荷文件。使用优化模板确保捕获所有必要的信息以供分析。

启动数据库引擎优化顾问，并选择跟踪文件作为工作负荷源。该顾问会分析捕获的查询，并推荐可提高性能的索引、索引视图或分区策略。

性能优化工作流将跟踪捕获与调优分析集成在一起。在正常运行期间捕获代表性工作负载，使用调优顾问进行分析，审查建议，在开发过程中测试建议的更改，并最终在生产环境中实施已批准的更改。

8.4 自动跟踪收集

使用以下方式安排跟踪 SQL Server 代理作业自动收集数据。创建使用 sp_trace 过程定义服务器端跟踪的 T-SQL 脚本。安排这些脚本在特定时间或间隔运行。

PowerShell 自动化可实现复杂的跟踪管理场景。编写 PowerShell 脚本来创建跟踪、监控其状态并处理收集的数据。通过任务计划程序或 SQL Server 代理。

SQL Server 代理作业提供可靠的计划执行。创建作业tar在监控周期开始时启动跟踪，并在数据收集完成后停止跟踪。配置作业通知以提醒管理员发生故障。

8.5 以编程方式分析跟踪

使用 fn_trace_gettable 函数通过 T-SQL 读取跟踪文件。此表值函数解析跟踪文件并以结果集的形式返回事件数据。使用标准 T-SQL 查询此数据以执行自定义分析。

自定义分析脚本支持自动化跟踪处理。编写查询来计算汇总统计数据、识别模式或标记异常。安排这些脚本在跟踪收集完成后自动运行。

通过查询表中存储的跟踪数据来生成报告。创建按时间段、用户或应用程序聚合事件的视图。构建报告解决方案，定期洞察数据库活动和性能。

9. SQL Server 分析器最佳实践

9.1 性能最佳实践

9.1.1 最小化跟踪开销

仅选择必要的事件以减少跟踪开销。每增加一种事件类型都会增加跟踪引擎必须处理的数据量。请检查您的监控目标，并仅包含与这些目标直接相关的事件。

有效使用过滤器，避免捕获不相关的数据。按数据库名称过滤可排除系统数据库。按持续时间过滤可仅捕获慢速查询。按应用程序名称过滤可专注于特定应用程序。适当的过滤可显著降低跟踪开销。

服务器端与客户端的考量因素会影响性能。服务器端跟踪会将数据直接写入磁盘，开销极小。客户端跟踪会通过网络将事件传输到 Profiler 接口，这会增加延迟和带宽消耗。建议使用服务器端跟踪进行生产监控。

9.1.2 优化跟踪存储

文件大小管理可防止磁盘空间耗尽。根据可用存储空间设置最大文件大小限制。启用文件滚动更新功能可创建多个文件，而不是无限增大单个文件。在跟踪执行期间监控磁盘空间。

表存储与文件存储的性能权衡有所不同。文件存储绕过了存储引擎，因此在跟踪执行期间性能更佳。表存储允许针对跟踪数据执行 T-SQL 查询，但会增加写入开销。请根据您的分析需求选择存储类型。

9.2 安全最佳实践

权限管理控制哪些人可以创建和运行跟踪。仅向需要跟踪功能的受信任用户授予 ALTER TRACE 权限。sysadmin 角色的成员拥有不受限制的跟踪访问权限。请定期审查和审核跟踪权限。

敏感数据保护需要谨慎的跟踪配置。处理敏感数据时，请避免捕获完整的查询文本。考虑过滤或加密包含机密信息的跟踪输出。将跟踪文件存储在具有适当访问控制的安全位置。

跟踪文件安全可防止未经授权访问捕获的数据。设置文件权限以限制对跟踪文件的访问。如果跟踪文件包含敏感信息，请对其进行加密。分析完成后删除跟踪文件，以最大程度地降低泄露风险。

9.3 生产环境注意事项

9.3.1 何时在生产中使用 Profiler

风险评估决定何时 SQL Server Profiler 适合用于生产环境。Profiler 会引入可衡量的开销，并且会随着跟踪范围的扩大而增加。评估诊断是否ost在运行生产跟踪之前，ic 值可以证明性能影响。

最小化影响配置可实现更安全的生产跟踪。使用高选择性过滤器仅捕获关键事件。设置持续时间阈值以忽略快速执行的查询。在故障排除会话期间，将跟踪持续时间限制为较短的时间段。配置服务器端跟踪以减少客户端开销。

9.3.2 生产监控的替代方案

扩展事件降低了生产监控的开销。这项现代技术比 SQL Server 分析器。将监控解决方案迁移到扩展事件以供长期生产使用。

查询存储会自动捕获查询性能数据，无需手动配置跟踪。在生产数据库上启用查询存储，即可跟踪一段时间内的查询执行统计信息。查询存储提供 most 性能监控功能，无需跟踪开销。

动态管理视图 (DMV) 为特定场景提供轻量级监控。DMV 提供当前状态信息，但不捕获历史事件。定期查询 DMV 即可监控服务器运行状况，无需承担持续跟踪的开销。

9.4 痕迹管理最佳实践

命名约定可确保跟踪文件易于识别且井然有序。跟踪文件名应包含日期、时间、服务器名称和用途。所有跟踪记录均应使用一致的命名模式，以便于管理和分析。

文档记录跟踪配置和用途。记录您捕获的事件、创建跟踪的原因以及从分析中了解到的信息。维护针对生产系统运行的跟踪日志，以用于合规性和故障排除。

保留策略可防止过多的跟踪文件累积。根据业务需求和存储容量定义跟踪文件的保留时长。自动删除旧的跟踪文件以释放磁盘空间。删除前，将重要的跟踪文件存档到长期存储中。

9.5 应避免的常见错误

过度追踪会导致性能开销过大，并生成难以管理的数据量。避免在未使用过滤器的情况下捕获所有事件。tar只使用狭窄且集中的追踪，并仅在必要时扩大范围。更多数据并不总是能够有效排除故障。

忘记停止跟踪会浪费资源并占用大量磁盘空间。监控完成后务必停止跟踪。设置跟踪持续时间限制或最大文件大小，以防止跟踪失控。定期监控正在运行的跟踪，并停止不活跃或不必要的跟踪。

忽略过滤器优化会导致性能不佳和分析困难。在进行测试之前，请投入时间配置有效的过滤器。tar追踪痕迹。在开发环境中测试过滤器，以验证它们是否捕获了预期数据。根据捕获的结果审查并优化过滤器。

10. 替代品 SQL Server 2025 年的 Profiler

10.1 扩展事件：现代替代品

10.1.1 什么是扩展事件

扩展事件代表 SQL Server的现代事件处理架构。微软专门设计了这个系统来解决 SQL Server Profiler 的局限性包括性能开销和配置灵活性。扩展事件提供了全面的监控功能，同时显著降低了资源消耗。

架构和优势使扩展事件与旧式追踪技术区别开来。事件引擎深度集成到 SQL Server的核心架构，以最小的开销捕获事件。异步事件缓冲可防止监控阻塞数据库操作。灵活 tar获取选项可实现多种输出配置。

性能优势使扩展事件成为生产监控的理想选择。基准测试表明，扩展事件的开销比同类产品低 50-90%。 SQL Server 分析器跟踪。该架构在高事件量下具有更好的扩展性，并支持更多并发监控会话。

10.1.2 从 Profiler 迁移到扩展事件

事件映射翻译 SQL Server 分析器事件与扩展事件等效。Most Profiler 事件具有对应的扩展事件。Microsoft 提供了映射两个系统之间常见事件的文档。

在扩展事件中创建会话需要学习新的语法和概念。使用 T-SQL CREATE EVENT SESSION 语句或 Management Studio 中的扩展事件图形界面定义事件会话。会话指定要捕获的事件、要收集的数据以及存储结果的位置。

10.1.3 扩展事件工具和接口

SSMS 扩展事件 UI 提供图形化会话管理。您可以通过对象资源管理器中的“管理”文件夹访问扩展事件。通过界面创建、修改和监控事件会话。以网格和图表等图形格式查看捕获的数据。

T-SQL 会话管理支持编程式扩展事件控制。编写 CREATE EVENT SESSION 语句，在代码中定义会话。使用 ALTER EVENT SESSION 修改正在运行的会话。使用 DROP EVENT SESSION 删除会话。此方法有助于自动化监控解决方案。

10.2 SQL Server 查询存储

查询存储会自动捕获已启用该功能的数据库的查询性能数据。此功能可跟踪一段时间内的查询计划、执行统计信息和性能指标，无需手动配置跟踪。查询存储会维护历史数据，从而实现趋势分析和回归检测。

通过查询存储进行实时查询性能监控，揭示当前系统行为。查看最近执行的查询、其执行计划和资源消耗情况。识别持续时间增加或执行计划发生变化的查询，这些查询可能预示着存在问题。

历史查询分析支持跨时间段比较。查询存储会保留性能数据，保留期限可配置。将当前性能与历史基线进行比较，以识别性能回归。分析性能趋势，预测未来的容量需求。

当您需要自动、始终在线的性能监控时，请使用查询存储。在生产数据库上启用查询存储，以持续跟踪查询行为。查询存储通过提供性能问题的历史上下文，补充了基于跟踪的故障排除。

10.3 动态管理视图（DMV）

通过 DMV 进行轻量级监控，无需捕获历史事件即可提供当前状态信息。DMV 暴露内部 SQL Server 通过可查询视图获取统计数据和元数据。使用标准 T-SQL SELECT 语句查询 DMV。

用于性能监控的常见 DMV 查询包括用于查询性能统计的 sys.dm_exec_query_stats、用于当前正在执行的请求的 sys.dm_exec_requests 以及用于等待统计的 sys.dm_os_wait_stats。这些视图可以洞察服务器运行状况和活动的特定时间点。

DMV 通过提供实时指标来补充基于跟踪的监控。使用 DMV 进行快速健康检查和当前状态分析。将 DMV 查询与跟踪数据相结合，可获得全面的故障排除方法。

10.4 第三方监控工具

商业替代方案提供了增强的监控能力，超越 SQL Server的内置工具。SolarWinds、Redgate 和 Quest 等供应商的产品提供全面的监控、警报和分析功能。这些工具通常结合了多种数据源，包括跟踪、DMV 和性能计数器。

通过功能比较，揭示不同监控方法的优势。第三方工具提供卓越的用户界面、自动警报和历史趋势分析功能。 SQL Server的内置工具不提供任何额外的 cost 以及更深层次的集成。根据您的具体需求和预算评估工具。

10.5 选择适合您需求的工具

决策矩阵有助于选择合适的监控工具。对于临时故障排除， SQL Server Profiler 仍然易于使用且高效。对于生产监控，扩展事件或查询存储可提供更佳性能。对于全面的企业监控，第三方解决方案可提供最佳性能。ost 功能。

选择工具的标准包括性能开销、易用性、数据保留要求和预算限制。选择工具时，请考虑您团队的专业知识。即使新的替代方案提供更好的功能，熟悉的工具也能更快地进行故障排除。

结合多种工具，打造全面的监控策略。使用查询存储进行持续性能跟踪，使用扩展事件进行特定问题调查，并使用 DMV 进行实时健康检查。这种分层方法可提供强大的监控功能，且不会产生过多的开销。

11。故障排除 SQL Server 分析器问题

11.1 常见连接问题

身份验证失败会阻止 SQL Server 分析器连接到 tar获取服务器。验证您使用的凭据是否与所选的身份验证方法一致。Windows 身份验证要求您的 Windows 帐户具有适当的 SQL Server 权限。 SQL Server 身份验证需要有效的 SQL 登录凭据。

网络连接问题表现为超时错误或连接失败。请验证 SQL Server 允许远程连接。检查防火墙设置是否允许以下流量： SQL Server的端口。在排除 Profiler 特定问题之前，请使用 ping 和 telnet 测试基本连接。

11.2 Profiler 的性能问题

跟踪执行缓慢表明跟踪配置开销过大。请检查所选事件并删除不必要的事件。添加筛选器以减少捕获的事件数量。考虑使用服务器端跟踪来减少客户端处理负载。

高资源消耗会影响 SQL Server 以及 Profiler 客户端。在跟踪执行期间监控服务器 CPU 和内存。如果服务器资源受限，请提高过滤器的选择性或减少捕获时长。客户端资源问题需要关闭其他应用程序或升级客户端硬件。

11.3 跟踪文件和表问题

损坏的跟踪文件无法打开 SQL Server 分析器。损坏通常由非正常终止跟踪或磁盘错误造成。请尝试在文本编辑器中打开该文件，以验证其是否完全损坏。有时，可以使用 fn_trace_gettable 将部分数据导入表中来恢复。

尝试从以下位置加载跟踪时出现表访问问题 SQL Server 表。验证您对跟踪表拥有 SELECT 权限。检查该表是否已被删除或重命名。确保您连接到包含跟踪表的正确服务器和数据库。

11.4 缺失事件或不完整数据

过滤器配置错误会导致追踪数据遗漏预期事件。请仔细检查过滤条件，确保它们没有漏掉预期事件。通过运行短追踪数据并验证捕获的数据是否符合预期来测试过滤器。移除过滤器rarily 来确定它们是否是造成问题的原因。

缓冲区溢出发生于 SQL Server 无法快速写入跟踪数据以跟上事件生成的速度。这通常发生在活动高峰期未过滤的跟踪数据中。症状包括丢失事件或“未捕获事件”警告。解决方法是添加过滤器以减少事件量，或提高跟踪文件位置的磁盘 I/O 性能。

11.5 分析器崩溃和错误

常见的错误消息包括“无法创建跟踪”，表示权限问题或资源限制。“跟踪已停止”消息表明服务器端跟踪失败，可能是由于磁盘已满。“跟踪定义无效”错误表示配置问题。

解决策略取决于具体错误。权限错误需要向用户授予 ALTER TRACE 权限。资源错误需要释放磁盘空间或内存。配置错误需要检查并更正跟踪设置。Restart SQL Server 如果它变得无响应。

12。实用 SQL Server 分析器场景和示例

12.1 场景 1：识别数据库中最慢的查询

本演练演示了如何捕获和分析慢查询。

按照以下步骤配置跟踪：

正式上线 SQL Server 分析器并连接到您的 tar获取服务器。
点击文件 -> 新踪迹.
在 轨迹名称 领域。
从我们的数据库中通过 UL Prospector 平台选择 TSQL 来自 使用模板 落下。
点击 活动选择 标签。
点击 列过滤器.
从我们的数据库中通过 UL Prospector 平台选择 修读年限 并在 大于或等于.
从我们的数据库中通过 UL Prospector 平台选择 数据库名称 并输入您的数据库名称喜欢.
点击 OK 关闭过滤器。
启用 保存到文件 并指定文件路径。
点击运行是的tart 捕获。

在高峰业务时段运行跟踪至少 30 分钟，以捕获代表性工作负载。收集足够的数据后停止跟踪。

按照此过程分析结果：

点击 修读年限 列标题按执行时间排序。
确定运行时间最长的前 10 个查询。
对于每个查询，检查 文本数据 列。
复制查询文本并粘贴到 Management Studio 中。
绝大部分储备使用 显示预计执行计划 分析查询。
查找表扫描、缺失索引或低效连接。
评估 中央处理器, 读和写资源消耗模式的列。

12.2 场景 2：调试死锁问题

此示例显示如何捕获和分析死锁。

使用以下步骤配置死锁监控：

创建一个名为“死锁调查”的新跟踪。
点击 活动选择 标签。
点击 显示所有事件.
拓展锁类别。
从我们的数据库中通过 UL Prospector 平台选择 锁：死锁.
从我们的数据库中通过 UL Prospector 平台选择 锁：死锁链.
拓展 错误和警告 类别。
从我们的数据库中通过 UL Prospector 平台选择 阻塞进程报告.
确保 文本数据 列被选中。
点击运行是的tart 监控。

当跟踪执行期间发生死锁时，跟踪网格中会出现 Lock:Deadlock 事件。

按照以下步骤解释死锁信息：

点击 锁：死锁 事件行。
查看 文本数据 底部面板中的列。
从 TextData 复制 XML 内容。
打开 Management Studio 并创建一个新的查询窗口。
将 XML 粘贴到查询窗口中。
使用 .xdl 扩展名保存文件。
在 Management Studio 中打开 .xdl 文件以查看死锁图。
该图显示了所涉及的进程、锁定的资源以及所选择的受害者。
查看两个进程的查询以了解冲突。

解决步骤通常涉及重新排序应用程序代码中的操作以按照一致的顺序访问资源、减少事务范围或实施适当的锁定提示。

12.3 场景 3：跟踪来自特定应用程序的所有查询

此场景演示了特定于应用程序的查询监控。

使用以下步骤配置特定于应用程序的跟踪：

创建一个名为“应用程序查询跟踪”的新跟踪。
点击 标准版 模板。
点击 活动选择 标签。
点击 列过滤器.
从我们的数据库中通过 UL Prospector 平台选择 应用名称.
在喜欢领域。
如果您的应用程序使用连接池，则可能需要通配符匹配。
点击 OK 应用过滤器。
启用 保存到表 以便于查询。
点击运行是的tart 捕获。

查询模式分析揭示了你的应用程序如何与 SQL Server:

收集数据后，停止跟踪。
打开 Management Studio 并使用跟踪表连接到服务器。
查询跟踪表来分析模式。
按类型计数查询以查看操作组合。
识别 most 经常执行的查询。
寻找可以缓存或优化的查询。
检查重复的相同查询，表明缺少连接池。

12.4 场景 4：审核数据访问以确保合规性

此示例展示了安全审计跟踪的创建。

按照以下步骤配置安全审计：

创建一个名为“安全审计跟踪”的新跟踪。
点击 活动选择 标签。
点击 显示所有事件.
拓展 安全审计 类别。
从我们的数据库中通过 UL Prospector 平台选择 审计登录, 审计注销, 审计登录失败.
从我们的数据库中通过 UL Prospector 平台选择 审计数据库对象访问.
拓展 TSQL 类别。
从我们的数据库中通过 UL Prospector 平台选择 SQL：批处理完成.
点击 列过滤器.
筛选条件 对象名 监控特定的敏感表。
启用 保存到表 以便长期保留。
启用服务器端跟踪以实现无人值守操作。
点击运行是的tar审计。

通过查询跟踪表生成审计报告：

创建按用户和时间段汇总访问的查询。
识别不寻常的访问模式或下班后的活动。
记录失败的登录尝试以供安全审查。
将审计数据导出至报告系统，用于合规性文档。
根据保留政策存档已完成的审计跟踪。

12.5 场景 5：捕获性能测试的工作负载

此场景演示了用于测试目的的工作负载捕获。

使用以下步骤创建可重放的跟踪：

创建一个名为“Workload Capture”的新跟踪。
从我们的数据库中通过 UL Prospector 平台选择 TSQL_重放 从模板下拉菜单中。
该模板包括重播所需的所有事件和列。
点击 活动选择 标签。
如果您想捕获特定的工作负载段，请应用过滤器。
启用 保存到文件.
指定具有足够磁盘空间的文件路径。
设置适当的文件大小限制并启用翻转。
点击运行是的tart 捕获。

在代表性业务操作期间进行捕获。为了全面捕获工作负载，请运行跟踪几个小时，涵盖不同的活动模式。收集到足够的数据后停止跟踪。

工作负载分析揭示了系统行为模式：

打开捕获的跟踪文件 SQL Server 探查器。
按类型和时间查看事件分布。
计算总体资源消耗指标。
确定高峰活动期和资源瓶颈。
使用跟踪进行数据库引擎优化顾问分析。
针对测试系统重放跟踪以验证更改。

13. 数据库损坏检测 SQL Server 探查

13.1 使用 SQL Server 腐败预警信号分析器

数据库损坏是ost 数据完整性和系统可靠性面临严重威胁。虽然 SQL Server Profiler 并不是一个专门的损坏检测工具，但它可以捕获表明潜在损坏问题需要立即调查的关键警告信号。

13.2 指示潜在损坏的严重错误事件

严重性 24 错误（823、824、825）：硬件和媒体故障。
错误 605：页面检索尝试失败
错误 8928 和 8929：对象损坏

13.3 可疑数据库行为和警告模式

特定对象上的重复查询超时
访问冲突和应用程序崩溃
异常错误聚类

13.4 根据 Profiler 发现运行 DBCC CHECKDB

If SQL Server 如果 Profiler 发现可疑损坏，您可以使用 DBCC CHECKDB 对数据库进行完整检查。如果确认损坏，则执行修复。我们已编写如何完成这些任务的综合指南.

如果 DBCC CHECKDB 无法修复数据库，则损坏情况严重。在这种情况下，您可以采取第三方 SQL 恢复工具.

14. 常见问题解答

问：是吗 SQL Server Profiler 仍然支持 SQL Server 2022？

答：是的， SQL Server Profiler 仍然包含在 SQL Server 2022和 SQL Server Management Studio，尽管自 SQL Server 2016年。微软继续在当前版本中提供该工具，但建议迁移到扩展事件以实现新的监控实现。该工具仍然有效，并广泛用于故障排除和临时分析。

问：有什么区别 SQL Server 分析器和 SQL 跟踪？

A: SQL Server Profiler 是一个图形用户界面工具，它连接到 SQL 跟踪引擎，该引擎在 SQL ServerSQL Trace 是实际捕获事件的底层技术。您可以使用 Profiler 的界面或直接通过 T-SQL 存储过程（例如 sp_trace_create）创建跟踪。Profiler 提供更简单的配置，而 T-SQL Trace 提供更多自动化可能性。

问：性能开销是多少 SQL Server 分析器添加？

答：性能影响因跟踪配置而异。经过良好过滤的跟踪（仅捕获特定事件）可能会增加 1-5% 的开销。配置不当且未使用过滤器的跟踪可能会增加 20-50% 甚至更高的开销，尤其是在繁忙的系统上。服务器端跟踪的影响小于客户端跟踪。请务必使用过滤器以最大程度地减少事件量，并首先在非生产环境中测试跟踪。

问：我可以跑步吗 SQL Server 生产服务器上的分析器？

答：可以跑 SQL Server 在生产服务器上使用 Profiler，但务必谨慎。使用选择性较高的筛选器，限制跟踪时长，并优先使用服务器端跟踪，以最大程度地降低影响。尽可能在活动较少的时段运行生产跟踪。对于持续的生产监控，请考虑使用扩展事件或查询存储，因为它们的开销更低。

问：我需要使用什么权限 SQL Server 分析器？

答：您需要 ALTER TRACE 权限才能创建和运行跟踪。sysadmin 固定服务器角色的成员自动拥有此权限。对于非 sysadmin 用户，请显式授予 ALTER TRACE 权限。此外，您还需要根据配置获得适当的权限才能将跟踪数据保存到文件或表中。

问：为什么我看不到我的跟踪中的所有事件？

答：事件丢失通常是由于过滤器限制过多或缓冲区溢出造成的。请检查您的过滤器配置，确保其没有排除所需的事件。缓冲区溢出发生在以下情况： SQL Server 无法足够快地写入事件，通常是在繁忙的系统上出现未过滤的跟踪信息。添加过滤器可以减少事件量或提高磁盘 I/O 性能。检查是否有指示未捕获事件的错误消息。

问：如何使用 SQL Server 分析器？

答：创建一个包含“锁”类别中的“锁：死锁”和“锁：死锁链”事件的跟踪记录。确保选中“文本数据”列，因为它包含死锁图 XML。发生死锁时，从“文本数据”列复制 XML 文件，以 .xdl 扩展名保存，然后在 SQL Server Management Studio 查看图形死锁图。

问：将跟踪保存到文件和表中有什么区别？

答：文件在跟踪执行期间提供更好的性能，因为它们绕过了 SQL Server 存储引擎。文件跟踪将数据直接写入磁盘，开销极小。表跟踪则通过存储引擎写入，这会增加开销，但可以立即对跟踪数据进行 T-SQL 查询。对于性能敏感的场景，以及需要在捕获期间或捕获后立即查询数据的表，请使用文件跟踪。

问：我可以实现自动化吗？ SQL Server 分析器跟踪收集？

答：是的，使用 T-SQL 存储过程创建的服务器端跟踪来自动收集跟踪信息。使用 sp_trace_create 和相关过程编写脚本，然后通过 SQL Server 代理作业。此方法可按指定计划实现无人值守的跟踪收集。PowerShell 脚本为更复杂的场景提供了另一种自动化选项。

问：我应该运行跟踪多长时间？

答：跟踪时长取决于您的目标。对于特定问题的故障排除，请在问题重现的同时运行跟踪，通常需要 5-30 分钟。对于性能分析，请在活动高峰期至少捕获一小时的数据。对于工作负载分析或容量规划，请在不同时间段收集数小时的数据。监控完成后，请务必停止跟踪以释放资源。

问：如果我的跟踪文件太大，我该怎么办？

答：在追踪属性中启用文件滚动功能，可以创建多个较小的文件，而不是一个大文件。请根据您的磁盘空间和分析需求设置最大文件大小。使用筛选器来减少捕获的事件量。对于较大的追踪数据，请考虑分段分析数据，而不是一次性加载整个追踪数据。定期归档或删除旧的追踪文件以节省磁盘空间。

问：如何找到导致 CPU 使用率高的查询？

答：创建包含 SQL:BatchCompleted 和 RPC:Completed 事件的跟踪。包含 CPU、Duration 和 TextData 列。按 Duration 过滤，仅捕获超过阈值（例如 1000 毫秒）的查询。收集数据后，按 CPU 列降序排序。顶部的查询消耗的资源最多。ost 处理器时间。检查这些查询是否存在优化机会，例如缺少索引或逻辑效率低下。

问：可以 SQL Server 分析器捕获查询执行计划？

A: SQL Server Profiler 可以通过“性能”类别中的“Showplan XML”事件捕获执行计划信息。选择“Showplan XML”或“Showplan XML Statistics Profile”事件可捕获完整的执行计划。“TextData”列包含 XML 计划数据。但是，对于常规执行计划分析， SQL Server Management Studio 的图形执行计划功能或查询存储提供了更简单的替代方案。

问：最好的模板是什么tar是否适合一般监控？

答：标准模板提供了良好的tar常规监控的要点。它包含常见的查询执行事件、存储过程调用和错误跟踪，并具有均衡的开销。对于专注于查询性能的低影响监控，请使用 TSQL 模板。了解基础知识后，您可以根据特定需求自定义模板，例如添加筛选器和调整事件选择。

问：如何仅追踪特定的应用程序或用户？

答：使用列筛选器来隔离特定的应用程序或用户。对于应用程序，请使用连接字符串中指定的名称按 ApplicationName 列进行筛选。对于用户，请使用 LoginName 列进行筛选 SQL Server 登录名或 Windows 帐户名。组合多个过滤器可进一步缩小范围，例如同时按应用程序名称和数据库名称进行过滤，以监控某个应用程序在特定数据库中的活动。

15. 结论和后续步骤

15.1关键要点

SQL Server 尽管 Profiler 已被弃用，但它仍然是临时数据库故障排除的宝贵工具。其直观的界面和全面的事件捕获功能使其成为快速诊断的理想选择。ost当您需要立即获得结果时，可以使用 ic 会话。使用 Profiler 可以排除特定问题故障、分析应用程序行为以及进行安全审计。

最佳实践包括积极使用过滤器以最大程度地降低性能影响，在生产环境中优先使用服务器端跟踪，并将跟踪时长限制在必要的范围内。仅选择必要的事件和列以减少开销。将跟踪保存到文件而不是表中，以提高捕获性能。

15.2 前进：拥抱现代工具

过渡自 SQL Server 从 Profiler 到 Extended Events，打造长期监控解决方案。Profiler 仍然能够正常工作，但投入时间学习 Extended Events 可以让你在未来 SQL Server 版本。Start 使用简单的扩展事件会话来复制常见的 Profiler 跟踪。

在生产数据库上启用查询存储，即可实现自动性能监控，无需手动配置跟踪。查询存储会持续捕获查询计划和执行统计数据，为性能分析提供基准数据。将查询存储与 tar获取扩展事件会话以进行全面监控。

15.3 其他资源

以下资源将帮助你加深你的 SQL Server 分析器知识并及时掌握监控最佳实践：

微软官方文档

SQL Server 分析器文档 – 事件、专栏和程序的综合参考
SQL 跟踪系统存储过程 – 用于服务器端跟踪创建的 T-SQL 参考
扩展事件文档 – 迁移指导和现代监控方法
查询存储文档 – 自动查询性能跟踪参考
性能监控和调优工具 – 概览 SQL Server 监控选项

社区资源

SQL Server Central – 面向数据库专业人员的文章、论坛和脚本
堆栈溢出 SQL Server 标签 – 针对特定故障排除问题的社区问答
Reddit r/SQLServer – 讨论论坛 SQL Server 主题和建议
SQLServerCentral.com 论坛 – 关于分析和性能的活跃社区讨论
MSDN SQL Server 论坛 – Microsoft-hosted 社区支持论坛

博客和技术文章

SQL Server 性能监视器 – 专门的性能监控和优化内容
Brent Ozar Unlimited 博客 – 性能调优和监控最佳实践
SQLSkills.com – 专家级 SQL Server 来自行业领袖的内容
Microsoft SQL Server 博客 – 官方产品更新和功能公告
简单谈话 – 实用 SQL Server 教程和案例研究

培训和认证

微软学习 – 免费在线培训模块 SQL Server
Microsoft 认证：Azure 数据库管理员助理 – 官方认证路径
Pluralsight SQL Server 课程——关于分析和性能调优的视频培训
LinkedIn学习 SQL Server 培训——专业发展课程
Udemy SQL Server 表演课程——实用的实践培训选项

书籍

SQL Server 查询性能调优——全面的性能优化指南
专业版 SQL Server 内部——深入探究 SQL Server 建筑
SQL Server 执行计划——理解查询优化
专家绩效指数 SQL Server – 索引设计和优化
SQL Server 高级故障排除和性能调整 – 高级诊断ost集成电路技术

工具和实用程序

SQL Server 管理工作室 – 主要接口 SQL Server 探查
Azure数据工作室 – 现代跨平台数据库工具
sp_WhoIsActive – 流行的社区创建的监控存储过程
SQL Sentry Plan Explorer – 免费执行计划分析工具
DBForge Studio – 第三方 SQL Server 开发和管理工具

关于作者

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

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

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

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

SQL Server Profiler：跟踪、分析和故障排除 SQL Server [2026指南]

1. 介绍 SQL Server 探查

1.1什么是 SQL Server 分析器以及我们为什么需要它？

1.2 SQL Server 2025 年的 Profiler：现状与替代方案

1.3 本指南的适用对象