SQL Server 跟踪在生产中是否“被认为有害”？

Question

背景：谨慎的 DBA

我们已经被收购了几次，我们最新的霸主拥有 DBA，他们小心地保护他们的生产数据库服务器。

总的来说这是好的。

但是，我们遇到了开发人员和 DBA 之间的一个争论点：他们不会对生产数据库服务器运行跟踪。

我们作为开发人员的经验：SQL Server 跟踪 + RML 实用工具

过去，当应用程序实例运行缓慢时，我们会通过 .sql 脚本运行跟踪，压缩输出，然后使用 Microsoft 的 RML 实用程序对其进行处理。

请注意，我们不运行基于 GUI 的分析器工具，因为这会显着降低性能（数据库需要等待更新 GUI）。这些跟踪只是“记录活动”到数据库服务器的本地文件系统。我们的脚本一次运行指定分钟数（例如 10 分钟）的跟踪。

跟踪和 RML 实用程序的组合效果很好：报告易于使用。它显示热点（见下文），报告提供有用的信息，它们允许深入了解实际执行计划等。它比 Oracle 提供的任何东西（或至少几年前）都要好得多。

（热点：如果一个查询耗时 1/10 秒，但执行了 400,000 次，它会出现在报告中，高于执行一次需要 30 秒的查询。）

这些年来，我做了一些表演工作。我的经验是，从“真实负载下的真实数据库”中捕获“实际数据”胜过程序员“猜测”并模拟他们想象的问题。这就是为什么我认为 SQL Server 跟踪几乎是解决问题的“银弹”。

我的问题

• 在生产中运行 SQL Server 跟踪（填满磁盘、降低性能等）的主要、合理的问题是什么？
• 这些担忧有效吗？如果是这样，我们如何解决它们？
• 跟踪并分析“实际问题”似乎是了解和解决情况的最清晰步骤。有哪些替代方案？

Answer 1

最新版本的 RML 实用程序（截至今天09.04.0051）支持扩展事件跟踪，因此也许您可以与 DBA 合作进行一些受控跟踪。帮助文件中的截图：

然而，它们确实有一点，因为 RML 提供的默认跟踪模板包括语句级事件（SQL:StmtStarting, SQL:StmtCompleted, SP:StmtStarting, SP:StmtCompleted），即每个 proc 中的每个语句。这很容易使服务器在错误的条件下瘫痪，例如SELECT在一个大表上运行的语句中的标量函数。

Extended Events (XE) 在 2012 之前的版本中受到一些限制，但它更轻量级。您仍然需要小心，因为对于非常密集的工作负载（sqlserver.sp_statement_starting、sqlserver.sp_statement_completed、sqlserver.sql_statement_starting、sqlserver.sql_statement_completed），SQL 语句级事件仍然会产生开销。执行计划捕获 ( sqlserver.query_post_execution_showplan) 也可以是密集的。考虑使用提供的XETraceCaptureDefLightWeight.sql模板并且包含较少的事件。

总之，我建议转向 XE 并使用最新版本的 RML 提供的轻量级 XE 定义。