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

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


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

SQL Profiler可以在生产环境中实际使用吗？

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

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

有人在生产中使用SQL事件探查器吗？

评论

如果您知道要查找的内容，则可能甚至不需要跟踪，例如dba.stackexchange.com/questions/756/…

#1 楼

使用Sql Server Profiler（GUI工具）跟踪生产服务器不是一个好主意。但这取决于负载。使用服务器端sql跟踪（请参见sp_trace_XXX过程）代替。我还发现了以下文章：性能影响：Profiler跟踪与服务器端SQL跟踪，

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

避免导致Profiler出现问题

也许会引起兴趣和有用。

在线预订说：


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


评论

为了最大程度地减少影响过滤器，可以通过sp_trace命令跟踪到文件。远程运行的GUI会产生最大的影响，但是您可以使用它轻松地生成包含所有过滤器的脚本，您可以对其进行快速修改以转储到文件中。适当设置文件数和文件大小。

– AndrewSQL
2011年1月24日17:07

#2 楼

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

#3 楼


是的，监视行为将需要一些资源。在过载的服务器上运行它可能会杀死它。
您实际上将监视实际负载：您的操作可能会因负载的噪音而丢失。

我们有时在生产环境中运行它。主要使用用于特定代码的文本过滤器，或使用CPU /持续时间过滤器来捕获运行时间较长的查询。而且，我们不会尝试捕获XML执行计划或某些类似的问题。

关键是要知道您在寻找什么：我们不会倾向于使其运行并捕获所有内容。

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

#4 楼

事件探查器将始终对性能产生影响。

如果使用的是SQL Server 2008R2 +，则可以使用扩展事件。这为您提供了在性能分析器中看到的许多信息，而性能却受到了影响。

在线书籍简介
http://technet.microsoft.com/zh-cn/library/ bb630354（v = sql.105）.aspx

此功能在SQL Server 2012中得到了重大更新，现在包括SSMS中的GUI。