尽管SQL跟踪在设计和测试时都被认为是高效的，但其也会因此承担更多的工作。在一台极其忙碌的服务器上每分钟收集数以百万计的事件对于所有服务器资源来说都十分繁重，即从存储缓冲区的内存到网络带宽（如果使用行集提供者）再到I/O（如果使用文件提供者）。即便在最忙碌的数据库服务器上，SQL跟踪也是很好的跟踪问题的工具。然而，必须制定一些有远见和计划的应用程序，它可以保证跟踪会话成功地回答用户的问题，而不会因出现新故障导致任务不能完成。
SQL Server 性能分析器问题
保证跟踪活动不在忙碌的产品服务器上引发问题最简单的方法就是不使用SQL Server性能分析器工具，除非用它做脚本工具（编辑跟踪定义）或很小的跟踪任务，例如过滤单个spid完成的活动。
虽然不少人建议不在忙碌的系统上使用SQL Server性能分析器，但是我们并不能肯定它到底会有多大的影响。SQL Server MVP和加载测试的专家Linchi Shea用他写的TPC-C基准程序工具进行了一些测试。
最后的结果显示，对于基于性能分析器的跟踪而言，即使模拟用户数很少，事务的每秒吞吐量也会大约减少10%。
由性能分析器跟踪产生的带宽利用消耗了服务器可用的100兆比特的35%，但在它基线情形和服务器端跟踪测试之间完全没有性能差别。这个测试无疑说明了对于已经十分忙碌的产品环境而言，服务器端跟踪才是正确的选择，这样可以避免引发更多的问题。
注意：关于测试的全部信息，请参考Linchi博客中关于该主题的内容。地址如下：http://sqlblog.com/blogs/linchi_shea/archive/2007/08/01/trace-profiler-test.aspx
当收集的数据量增加时，即使是用服务器端跟踪，也一定会出现性能障碍。然而，这个结果说明即便是在一台产品系统上，如果要使用SQL跟踪解决问题，也是可行的。
降低跟踪开销
除了完全不使用SQL Server性能分析器之外，还有很多方法可以用来降低跟踪的开销。服务器端跟踪效率非常高，但是并不意味着用户就可以大量使用。对于用户来说，最重要的就是应当视图避免收集过多的数据给I/O系统造成太大的压力，这将会导致阻塞。
SQL跟踪提供了过滤跟踪的能力，即要确保利用好这个功能。过滤器通过限制收集的数据量很自燃地减少了I/O。在设计跟踪时，作为跟踪定义的一部分，要考虑如何过滤而不是等到把数据加载到跟踪表里之后再补救。
有时过滤跟踪以避免额外开销的最好方法是实际创建多个跟踪，每个跟踪都有不同的过滤器集合。例如，“调试死锁”中所示的跟踪，由于死锁图事件可能被任意数目的系统spid激发，因此不可能对其进行过滤。比起创建一个单独的整体跟踪，还不如另外创建一个包括“RPC:Starting”、“SQL:BatchStarting”、“Locks: Lock:Acquired”、“Lock: Lock:Released”和“Locks: Lock:Escalation”等事件的跟踪。这个跟踪可以基于用户正集中研究的两个spid被过滤。
第2个非过滤的跟踪可以被同时创建，它只包含死锁图事件。捕捉到所需要的数据后，这两个跟踪的事件就会被插入到一个单独的跟踪表里，被当作一个单独跟踪捕捉的事件来进行处理。如果也恰好捕捉到所有有关事件的EventSequence列，那么把这些东西整合起来就更加容易，这两个跟踪的组合不会包含那些不想捕捉的结果。
别把所有的东西都塞进一个单独跟踪，以便更加灵活地使用过滤器，极大地缩小跟踪的焦点。
最大文件容量、滚动和数据收集
另一个I/O相关的考虑是创建服务器端跟踪时可用的最大文件容量参数。当同一个忙碌的新系统合作时，应当谨慎对待服务器端跟踪，因为如果之前没有设置好过滤器，这个跟踪就有可能很快消耗掉用来收集数据的驱动器。有些系统十分忙碌，仅仅是从“RPC:Completed”、“SQL:BatchCompleted”事件的TextData列中就可以每秒捕捉100或更多兆比特。
为避免这个问题并测试一个跟踪，通常从最大文件容量为50兆比特开始，并关闭滚动文件。启动该跟踪并对其进行监视，确保它不会立即消耗掉整个文件并停止。如果这种情况发生了，就应当重新考虑某些事情并重新尝试；如果没有发生，则继续进行，设置一个稍微大一些的最大文件容量或配置滚动文件。
如果想要运行一个长时间的服务器端跟踪，但是收集数据的可见性有延迟，那么滚动文件就能发挥意想不到的用处。要建立一个滚动文件，需要为跟踪配置一个足够小的最大文件容量，以方便其定期滚动（例如每20分钟滚动一次），假定这是为延迟数据设置的时间间隔。同时也要为滚动文件的最大数目配置一个足够大的数值，以支持运行该跟踪的时间长度。
通过查询sys.traces视图的Path列，建立一个SQL Server代理任务来定期获得当前文件的名称。检查正在跟踪的文件夹里的旧跟踪文件（可能用的是xp_cmdshell），并插入到这个跟踪表里，完成这项工作后再删除。
用这种方式运行该跟踪会使用户对数据的可见性延迟，同时也会保持事件的高效性并确保不会遗漏任何事件。要确保监视从跟踪表里收集的数据，且保证插入行为本身并没有占用额外的时间或占用过多的I/O系统。有时在产品数据库的需求和监视所需的条件之间找一个平衡点很困难。
本文转自UltraSQL51CTO博客，原文链接：http://blog.51cto.com/ultrasql/1590187 ，如需转载请自行联系原作者
