SQL Server有一个非常有用的用户界面的工具，这个工具可以用来创建、操作及管理跟踪。SQL Server性能分析器对于大多数跟踪活动来说都是最主要的切入点，它的简易性，用户不仅可以用它启动和运行跟踪，还可以用来快速排查数据库问题的最重要的SQL Server组件。SQL Server性能分析器也在工具集中添加了一些SQL跟踪本身无法实现的特性。
性能分析器的基本原理
性能分析器的启动，在性能工具中可以找到SQL Server Profiler工具。启动后跳出一个空白的屏幕。点击File，New Trace，连接实例。然后看到一个Trace Properties对话框，上面有两个标签页，分别是General和Events Selection。
General标签页允许控制用户处理跟踪的方式。默认设置是使用行集提供者，实时地在SQL Server性能分析器窗口中显示事件。还有的可用选项可以保存事件至某个文件（在服务器或在客户机上）或某个表。但通常建议不要在一台忙碌的服务器上使用这些选项。
当要求性能分析器将事件保存至一个服务器端文件时（通过选择服务器进程跟踪数据来完成），它实际上会启动两个等价的跟踪—一个是使用行集提供者，另一个是使用文件提供者。两个跟踪意味着双倍的开销，这不是一个好方法。保存至一个客户端文件完全不会用到文件提供者。数据经由行集提供者传送至性能分析器工具，然后才被保存到一个文件中。这比使用性能分析器写入一个服务器端文件更高效，但由于用到了行集提供者，会遇到网络带宽的问题，并且也享受不到文件提供者的无损保证。
看到“保存至表”这个选项，那为什么说它并非SQL跟踪可用的特性。事实上，SQL跟踪并不显示表输出提供者。当使用该选项时，SQL Server性能分析器工具反而会使用行集提供者，并将数据传回一个表里。如果要保存至的哪个表正好在相同的跟踪服务器上，就会导致极大的服务器开销和带宽使用，因此，如果必须使用该选项，建议将数据保存至另一台不同的服务器的表中。SQL Server性能分析器也提供跟踪执行后将数据保存至一个表中的选项，这在大多数情况下都是更为可行的选择。
Event Selection标签页是SQL Server 性能分析器中配置跟踪时耗时最多的地方。这个标签页允许选择想要跟踪的事件及关联的数据列。默认选项收集4种情况下存在的任何连接的相关数据，这4种情况分别是跟踪启动时（ExistingConnection事件）、登录和登出发生时（Audit Login和Audit Logout事件）、远程过程调用完成时（RPC:Completed事件）及Transact-SQL批处理启动和完成时（SQL:BatchCompleted和SQL:BatchStarting事件）。默认情况下，事件和可用数据列的完整列表都是隐藏的。选中“Show all events”和“Show all columns”复选框，可以将可用选择加到用户界面中。
DBA通常使用SQL跟踪来解答最简单的为难题，它们以查询代价或时间消耗为依据的。哪些查询最长，或者哪些查询用掉了最多的资源？默认选择可以帮助回答这类问题，但在一台运行服务器上就必须要收集大量的数据。这不仅使用户需要完成更多的工作，也使服务器必须相应收集和分配足够多的数据。
阈值跟踪
为了缩小范围并保证跟踪不会造成性能问题，SQL跟踪提供了基于不同标准过滤事件的功能。过滤操作通过事件选择标签页上的列过滤器按钮在SQL Server性能分析器中显示。点击该按钮会弹出一个编辑过滤的对话框。
在这里，我选择只查看生存期大于或等于500毫秒的事件。这个数字为任何指定值。当形成有关特定应用程序的跟踪需求的概念时，应当反复探讨最好的选择。持续增大这个数字，直到大多数时候从跟踪里接收到的只有感兴趣的事件（这里指的是那些生存期长的事件）。以这种方式运作，可以方便、快捷地隔离系统中最慢的查询。
如果选择了事件并且定义好过滤，就可以启动跟踪了。点击Trace Properties对话框上的运行按钮。由于性能分析器使用行集提供者，因此数据会立即开始回流。如果发现数据进来得太快而影响读取，可以考虑使用SQL Server性能分析器任务栏上的自动滚动窗口按钮来取消自动滚动功能。
关于过滤应当重点注意的是，默认情况下，如果一个跟踪为某一特定列定义了过滤器，那么部位该列生成数据的事件将不会被过滤。例如，SQL:BatchStarting事件不产生生存期数据—我们通常认为提交到服务器的批处理基本上都会立刻启动。
上图显示了在Duration列上加入了一个值大于500的过滤器的跟踪。注意尽管ExistingConnection和SQL:BatchStarting这两个事件没有生存期输出这一列，但它们仍被返回了。要想修改这种操作行为，可以选中编辑过滤器对话框中的“Exclude rows that do not contain values”复选框，以更改相应的列设置。
保存和重演跟踪
这个功能在SQL Server性能分析器中实现了，它仅仅是封装了SQL跟踪所提供的各种功能。首先要考察下SQL Server性能分析器所提供的特性，这些特性使SQL Server性能分析器并不只对SQL跟踪特性的一个简单用户界面封装。
默认事件是如何设置的呢？它们被包含在与产品一起封装的标准事件模板中。一个模板就是一个集合，其中含有事件和列选择、过滤器及其他可以保存来创建可重用的跟踪定义的设置。如果要进行大量的跟踪，这将是一个十分有用的特性，因为每次使用时都重新配置这些选项浪费了大量时间。
重放跟踪模板
除了保存自己的模板这个功能之外，性能分析器还提供了8个预先定义的模板。除了已经介绍的标准事件模板，最重要的一个就是TSQL_Replay模板。该模板为15个不同的事件选择大量不同的列，且每个事件都要求性能分析器能够重演随后的一个收集跟踪。通过使用该模板启动一个跟踪，并在收集结束时及时保存跟踪数据，就可以将一个跟踪当作测试工具，当按正确顺序调用某些存储过程时可能会重新生成特定的故障。
一旦跟踪数据被收集完毕，就必须将其保存而后在重演启动之前重新打开。
只要收集到一个重演所需要的所有事件和列（使用TSQL_Replay模板时已经保证了这一点），那么这些格式中的任何一个都可用来作为一个重演跟踪的基础。通常建议采用二进制文件格式作为出发点，而且，如果有必要使用T-SQL进行操作就保存至一个表中。
如果数据被保存至一个文件或表里，初始的跟踪窗口就可以关闭了，并且该文件或表将通过SQL Server性能分析器的文件菜单被重新打开。如果一个跟踪以这种方式被重新打开，性能分析器工具栏上就会出现一个重演菜单，允许用户开始重演这个跟踪、停止重演或设置一个断点，如果只测试较大跟踪里的一个小的部分时，这个很有用。
点击“开始”后，用户将被要求连接至一台服务器（收集数据时用的服务器或另一台服务器以便重演同一个跟踪）。基本重演选项标签页除允许修改跟踪重演的方式之外，还允许用户保存跟踪的结果。
无论选择哪个选项，跟踪都将在多个线程上重演，线程数对应于指定重演线程的最大数量。然而，“按跟踪顺序重演事件”选项保证了所有事件重演时将严格按照发生的顺序进行，如同基于EventSequence列一样。多线程依然会被用来模拟多spid。另一方面，“使用多线程重演事件”选项允许SQL Server性能分析器重排每个spid开始执行事件时的序列，以便提高重演性能。但在一个给定的spid里，事件的顺序将和EventSequence保持一致。
如果要重演大量的相互独立的spid之间的跟踪数据，那么多线程选项就十分有用了。例如，在一台测试服务器上，为了模拟从一套产品系统获取的工作负荷，可能需要做这样的重演。另一方面，如果要保证可以复制跟踪期间出现的特殊情况，那么按序选项就是很好的选择。例如，当调试由于多个线程同时访问同一数据时的特定交互而导致的一个死锁或阻塞状况时，这就很有用。
SQL Server性能分析器是一个功能齐全且能同时为跟踪和简单处理跟踪数据提供广泛支持的工具。但是，如果不管收集的数据而去做高级查询，或者不管产品系统活动频繁的事实而运行跟踪，SQL Server性能分析器就会因为缺乏必需的条件而无法运行。SQL Server性能分析器不过是数据库引擎所提供功能的一个封装，而且除了使用查看跟踪的所有生存状态之外，某些情况下还可以直接使用服务器端工具以增加灵活性。
本文转自UltraSQL51CTO博客，原文链接： http://blog.51cto.com/ultrasql/1586334，如需转载请自行联系原作者
