在生产中的数据库上使用 SQL Profiler

Question

作为开发人员，我经常使用 SQL Profiler。这是一个很好的调试工具，既可以跟踪我的代码在做什么，也可以分析性能问题。

但是我一直在我的开发环境中使用它，并且以一种非常可控的方式使用它。

• 启动我的应用程序，并使其进入特定状态
• 在探查器上开始跟踪
• 对我的应用程序执行特定的操作序列
• 停止跟踪并检查结果。

SQL Profiler 能否在生产环境中实际使用？

我首先担心的是它会降低性能。

我的第二个担忧是，因为它正在生产中，您不会触发有趣的操作本身。您必须让分析器长时间运行，然后分析结果。结果集会变得太笨拙吗？（占用太多磁盘空间，查询太难）。

有人在生产中使用 SQL Profiler 吗？

Answer 1

我一直对生产使用 SQL Profiler。如果针对服务器正确完成（过滤以便您取回非常少量的数据），则风险最小。追踪一切将毫无用处。

Answer 2

使用 Sql Server Profiler（GUI 工具）跟踪生产服务器不是一个好主意。但这取决于负载。使用服务器端 sql 跟踪（请参阅sp_trace_XXX过程）而不是它。我还找到了文章：

性能影响：探查器跟踪与服务器端 SQL 跟踪，

在 SQL Server 中自动化服务器端跟踪

避免导致 Profiler 出现问题

也许它会感兴趣和有用。

在线预订说道：

• 远程运行 Profiler 而不是直接在服务器上运行
• 除非绝对需要，否则避免包含频繁发生的事件（例如 Lock:Acquired）
• 仅包含所需的事件类
• 指定限制过滤器以减少事件数量
• 避免冗余数据（例如 SQL:BatchStarting 和 SQL:BatchCompleted）
• 避免使用 Profiler 运行大量跟踪；考虑使用服务器端 SQL 跟踪
• 限制服务器端跟踪文件大小并管理空间使用

Answer 3

1. 是的，监控行为需要一些资源。在过载的服务器上运行它可能会杀死它。

2. 您实际上将监控现实生活中的负载：您的操作可能会在此负载的噪音中迷失。

我们有时在生产中运行它。主要是针对特定代码使用文本过滤器，或者使用 CPU/持续时间过滤器来捕获运行时间较长的查询。我们不会试图捕获 XML 执行计划或一些此类废话

关键是要知道您在寻找什么：我们不会让它运行并捕获所有内容。

在这种情况下，如果您想查看某些操作的结果，您可以在几个小时内完成吗？