在SQL Server中，SQL Server Profiler与跟踪功能是最被误解的一部分。

　　SQL Server Profiler是一个应用程序，在SQL Server标准版、企业版和工作组版中都有，它为用户提供了一个接口，用来设置与运行跟踪。(虽然它可以用来从SQL Server Web版和Express版中连接数据，但是这两个版本在安装包中不包含SQL Server Profiler。)

　　跟踪的作用，就是让你可以查看针对数据库服务器所执行的命令。你可以设置一个过滤器，只接收与你问题相关的数据。

　　当跟踪被建立之后，SQL Server Profiler会有大量的列可以被返回。具体列根据监测事件的不同而变化。例如，指定一个查询开始的事件不包含CPU与持续时间值，因为这些值旨在查询完成时才被包含在内。

　　何时使用SQL Server Profiler

　　在很多情况下你都可以使用SQL Server Profiler。

　　第一种情况，当你需要查看一个应用程序针对数据库运行的具体命令和参数。尽管你可以猜测写入数据库的是什么，但除非你就是数据库本身，否则你就无法百分百确定。它的工作方式同嵌入式动态SQL以及参数化存储过程相似。

　　SQL Server Profiler还可以用来确定运行哪些命令占用的资源与时间最多。要做到这一点，你需要在查询的runtime上建立一个过滤器(查询时间持续20秒以上的)。这将帮助你查看最长时间的查询，如果反馈的数据有很多，这就意味着你需要解决的问题也有很多。然后增加过滤器的数量，使用这些长时间运行的查询来决定首先攻击的对象。

　　SQL Server Profiler也可以同SQL Server Service Broker一同使用。 Service Broker不会向ERRORLOG中记录许多错误信息，而且由于所有事都发生在用户连接之外，所以当出现问题时无法反馈信息。对Service Broker事件进行监控，你可以很快就知道哪里出了问题。

　　SQL Server Profiler可以展示什么

　　一个跟踪的例子如图一所示，这个跟踪返回了许多信息。在这个跟踪中，我启动使用的是标准模板，然后我将所有事件都移除，除了RPC:Completed 和SQL:BatchCompleted。下一步，我检查了TextData字段并建立一个过滤器查找值为%1245305%的字符串。

　　正如你所见，这个过滤器返回了几条记录。持续时间列显示有两个查询耗时超过了1秒，这意味着你需要仔细查看这些查询。

　　由于我对生产数据库比较熟悉，我知道第二个查询中有许多复杂的连接，所以1.1秒的运行时间还是可以接受的。

　　而那个2.2秒的查询是个比较小的查询，不应该会占用这么长时间。为得到这一查询的执行计划，可以将它复制粘贴到Management Studio中来运行(你可以在SQL Server Profiler中监控Showplan Text或者Showplan XML时间来获取执行计划的文本)。

　　执行计划运行了许多索引扫描，如下图所示。因为左侧的线比右侧的线要粗很多，所以需要作出索引调整。这意味着一些统计数字也将过期淘汰了。

　　如果不使用SQL Server Profiler，那么你就很难找到这个不良运行的查询。我必须在一个调试器中运行这个ASP.NET程序，查看所有的参数然后将我认为网站正在发送到数据库的部分放在一起。一共有八个存储过程，我需要针对每个过程重复上面的工作，才可以得到正确的参数。而使用了SQL Server Profiler跟踪功能，我就可以再几秒钟之内完成上面的所有工作。

　　虽然在使用SQL Server Profiler时，有些用户毁坏了SQL Server生产数据库，但有办法可以避免这样的情况发生——尽量避免在生产服务器上使用SQL Server Profiler。为避免应用程序的进一步复杂化，在高交易服务器上不要监控所有的事务。这将影响服务器的性能，并可能毁坏运行着SQL Server Profiler的主机。