/*+--------------------------------------------------------------------------------------------------------------------------------------- * 名称: [DBO].[Performance_Trace_StopAll] * 功能: 防止反跟踪 * 作者: junling * 创建时间: 2011-02-09

/*+---------------------------------------------------------------------------------------------------------------------------------------
* 名称: [DBO].[Performance_Trace_StopAll]
* 功能: 防止反跟踪
* 作者: junling
* 创建时间: 2011-02-09
* 项目名称: XXXX
* -----------------------------------------------------------------------------------------------------------------------------------------
* 历史记录
* 编号 日期 作者 备注
* 1.0 2011-02-09 junling 创建
------------------------------------------------------------------------------------------------------------------------------------------+*/
create proc [dbo].[Performance_Trace_StopAll]

AS
declare traceCursor cursor for select id from sys.traces where id <> 1
open traceCursor
declare @curid int
fetch next from traceCursor into @curid
while(@@fetch_status=0)
begin

exec sp_trace_setstatus @curid,0

exec sp_trace_setstatus @curid,2

具体什么时候调用，就是看你具体的情况了。

五、SQL Trace跟踪原则

这里主要列出我们在跟踪时应该注意的事项，或者说按照下面的原则会降低跟踪对生产环境的影响。

1、不要使用Profiler GUI跟踪，如果使用了尽量不要运行在跟踪的SQLServer所在服务器；

2、不要把跟踪数据直接写入表，我们可以采用系统不是很繁忙时才把跟踪信息导入表中（除非你想立刻分析数据）；

3、跟踪会有大量的I/O操作，尽量把跟踪文件单独放在物理磁盘中；

4、只选择自己感兴趣的事件，多选一个事件都会带来开销（除非你多选的事件不发生，那样也就没有选择的必要；

5、过滤你的跟踪信息，比如你只对某数据库感兴趣，你只对某些列感兴趣（注意这里仅仅是减少了架构图中的I/O提供者的开销，想想为什么）；

6、像XXXXXXStarting之类的事件往往没有太大意义；

7、要注意你跟踪的sql中是否使用了标量函数，对这些sql的跟踪会严重影响性能，每个标量函数每处理一行都会触发事件（如果表很大，这是件很恐怖的事件)；

8、只给需要跟踪的用户指定跟踪权限。