必须指出跟踪会影响系统的性能这是不可完全避免的。当然可以通过一些方式我们能将这种代价降到最小。很多人往往以跟踪会影响现网性能为理由而拒绝跟踪。其实这是不对的还有一些人平时也做跟踪不过他们喜欢在系统不繁忙的时候跟踪。这样的做法都是有问题的。前者往往会出现突然间你的系统出现问题而你完全没有任何预兆后者往往会出现你错过捕获问题的最佳时机这样在不繁忙时的跟踪等于白费。 那什么时候对生产环境进行跟踪呢正确的做法应该是每时每刻的收集系统信息为对系统性能整体分析提供信息来源。二、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 查看到你正在跟踪的会话。四、如何反跟踪有时候我们不希望自己的sql被人跟踪。比如我们不希望别人能看到我们程序中写的sql。方法有很多这里介绍一种简单的方法。思路就是强迫SQLServer停止跟踪。具体存储过程如下/*---------------------------------------------------------------------------------------------------------------------------------------* 名称: [DBO].[Performance_Trace_StopAll]* 功能: 防止反跟踪* 作者: junling* 创建时间: 2011-02-09* 项目名称: XXXX* -----------------------------------------------------------------------------------------------------------------------------------------* 历史记录* 编号 日期 作者 备注* 1.0 2011-02-09 junling 创建------------------------------------------------------------------------------------------------------------------------------------------*/create proc [dbo].[Performance_Trace_StopAll]ASdeclare traceCursor cursor for select id from sys.traces where id 1open traceCursordeclare curid intfetch next from traceCursor into curidwhile(fetch_status0)beginexec sp_trace_setstatus curid,0exec sp_trace_setstatus curid,2fetch next from traceCursor into curidendclose traceCursordeallocate traceCursor具体什么时候调用就是看你具体的情况了。五、SQL Trace跟踪原则这里主要列出我们在跟踪时应该注意的事项或者说按照下面的原则会降低跟踪对生产环境的影响。1、不要使用Profiler GUI跟踪如果使用了尽量不要运行在跟踪的SQLServer所在服务器2、不要把跟踪数据直接写入表我们可以采用系统不是很繁忙时才把跟踪信息导入表中除非你想立刻分析数据3、跟踪会有大量的I/O操作尽量把跟踪文件单独放在物理磁盘中4、只选择自己感兴趣的事件多选一个事件都会带来开销除非你多选的事件不发生那样也就没有选择的必要5、过滤你的跟踪信息比如你只对某数据库感兴趣你只对某些列感兴趣注意这里仅仅是减少了架构图中的I/O提供者的开销想想为什么6、像XXXXXXStarting之类的事件往往没有太大意义7、要注意你跟踪的sql中是否使用了标量函数对这些sql的跟踪会严重影响性能每个标量函数每处理一行都会触发事件如果表很大这是件很恐怖的事件)8、只给需要跟踪的用户指定跟踪权限。六、结尾今天主要和大家讨论了SQLServer的跟踪方面的知识其中的知识还有很多值得我们去挖掘比如事件的分类、SQL Trace目录视图的每个列的意义、如何把trc格式文件导入表中分析统计、跟踪的安全性问题、跟踪的性能优化等等。 在这些方面多花点时间你会到SQLServer有更好的理解的。今天分析就到此结束文中如有描述不当的地方欢迎指出。共同进步才是硬道理。