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

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

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

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

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

我首先关心的是它将降低性能。

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

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

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

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

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

避免引起Profiler问题

也许它将是有趣和有用的。

在线预订说：

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

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

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

2. 您实际上将监视现实生活中的负载：您的动作可能会因负载的噪音而迷失。

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

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

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

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

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

联机丛书简介 http://technet.microsoft.com/zh-cn/library/bb630354(v=sql.105).aspx

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