这几天看了下范伟主演的<<跟踪孔令学>>，再一次欣赏了范伟精湛的演技特别是那种憨厚的表情。看完后，让我想起了SQLServer中的跟踪与反跟踪技术。觉得这部分内容值得写一篇文章和大家分享分享。了解SQLServer跟踪技术能让我们比较简单的在运行时实时的获取SQLServer的内部运作。这种获取方式比我们去使用跟踪标志、动态管理视图等来的方便简单的多。说到跟踪，很多人会想起SQL Profiler。SQL Profiler仅仅是一个GUI，SQL Trace才是本质。SQL Trace是构建服务器跟踪和Profiler的基础。如果你了解到这点，那你就会毫不犹豫的在生产环境使用服务器跟踪。下面从五个方面介绍SQL Trace，一、SQL Trace跟踪的代价；二、SQL Trace架构；三、具体跟踪例子；四、如何反跟踪；五、SQL Trace跟踪原则

　　一、SQL Trace跟踪的代价

　　必须指出，跟踪会影响系统的性能这是不可完全避免的。当然可以通过一些方式我们能将这种代价降到最小。很多人往往以跟踪会影响现网性能为理由而拒绝跟踪。其实这是不对的，还有一些人平时也做跟踪，不过他们喜欢在系统不繁忙的时候跟踪。这样的做法都是有问题的。前者往往会出现突然间你的系统出现问题，而你完全没有任何预兆，后者往往会出现你错过捕获问题的最佳时机这样在不繁忙时的跟踪等于白费。 那什么时候对生产环境进行跟踪呢？正确的做法应该是每时每刻的收集系统信息，为对系统性能整体分析提供信息来源。

　　二、SQL Trace架构

　　如果你想理解SQL Trace，那最好的方式莫过于用你自己的系统去对比。一般情况下我们都会在系统中记录一些日志，根据我们关注的点来区分记录日志的级别。典型的日志组件就是

　　Log4net之类的日志组件。这样我们就能够通过日志来分析系统的运行情况。知道这点，那理解SQL Trace就容易了。在SQLServer中，跟踪信息由一系列的事件组成。既然有事件，那谁触发事件呢。数据库引擎中的各个组件都是事件的生产者。下面看看SQL Trace的架构图：

　　如上图所示：整个SQL Trace架构有三个部分组成，数据库引擎、跟踪控制器、跟踪会话。数据库引擎是事件生成者，跟踪控制器负责事件的分发以及事件的过滤，跟踪会话负责对事件的列过滤以及跟踪事件的终点。下面简单描述下整个过程，跟踪控制器通过一个位图让数据库引擎的其他组件知道跟踪器请求了哪些事件，这个位图是所有跟踪的事件集合。一旦数据库引擎生成一个事件后，就把事件信息保存在跟踪控制器中的队列中。然后跟踪控制器把完整的事件信息传递给每个要求这个事件的跟踪会话。跟踪会话接收到自己关注的事件信息时，先经过过滤器（主要是过滤掉不感兴趣的列与行），过滤掉后发送给跟踪的I/O提供者。这里面的队列只是起缓冲作用。I/O提供者有很多种，比如Profiler、服务器跟踪、SQLServer自己的跟踪。

　　三、具体跟踪例子

　　这里的例子不想用SQL Profiler进行举例，因为我觉得它仅仅是方便我们跟踪而已。但是它在跟踪时既会把输出写入目标文件或者表（然后选择保存文件中保存表）还有把跟踪信息写入运行Profiler的客户端。把跟踪信息写入到运行Profiler客户端，这个比直接写入文件往往会慢。大家可以想想为什么？不过倒是可以用Profiler图形化方式定义跟踪，然后导出生成的跟踪SQL。具体如下：

　　一旦你开启了跟踪后，你可以通过：

　　select * from sys.traces 查看到你正在跟踪的会话。