上一篇，我们讲述了配置文件中与性能计数器相关的PerfmonCollector元素；这一篇我们将讲述与跟踪数据相关的ProfilerCollector元素。
在上一篇中使用SD_Detailed.XML配置文件在我本地收集5分钟跟踪数据文件为7Mb，当时没有做任何其他操作，试想如果在一个繁忙的生产环境，生成的跟踪文件大小将会更大。
跟踪数据，与添加的跟踪事件，系统繁忙程度有关。SQLdiag数据收集的大小不成比例地膨胀或捕获诊断数据时目标SQL Server性能降低的主要原因，是由于大量冗余或不相关的Profiler事件被添加到数据收集配置中。Profiler跟踪收集到目前为止是SQLdiag中最消耗资源的数据收集组件。
ProfilerCollector
本节将按照下面步骤测试：
1>禁用EventlogCollector、BlockingCollector、CustomDiagnostics元素收集器；PerfmonCollector、SqldiagCollector、ProfilerCollector元素保持启用
2>启用ProfilerCollector元素中的以下事件(类)，其他事件全禁用
<EventType name="Database" enabled="true"> <Event name="Data File Auto Grow" enabled="true" id="92" /> <Event name="Log File Auto Grow" enabled="true" id="93" /> <EventType name="Stored Procedures"> <Event name="RPC:Completed" enabled="true" id="10" /> <EventType name="TSQL"> <Event name="SQL:BatchCompleted" enabled="true" id="12" />
事件类别添加方针可参考《SQL Server 2012 深入解析与性能优化(第3版)》11.5.2 过滤噪音，分析问题不能一劳永逸，要针对具体情况适当启用/禁用事件。
我们使用SQLDiagPerfStats_Detailed_Trace2008new.XML配置文件收集5分钟数据：
cd D:Program FilesMicrosoft SQL Server100ToolsBinn SQLdiag /I F:TroubleShootingSQLdiaginputSQLDiagPerfStats_Detailed_Trace2008new.XML /O F:TroubleShootingSQLdiagLocalOutput /E +00:05:00
待它出现绿色字体"Collection started"后，参考RML Utilities for SQL Server分析一个.trc文件
ReadTrace -I"F:TroubleShootingTraceHighDuration20151212.trc" -o"F:TroubleShootingTraceoutput" -S"127.0.0.1,7777" -d"PerfAnalysis_CL" -E
由于已有的HighDuration20151212.trc文件比较小，RML很快就分析完成。在自动打开的Reporter中，我们随便点击查看。只是为了模拟应用程序使用数据库的情形，SQLdiag收集5分钟后会自动结束。
我们仔细回想一下，在配置文件的ProfilerCollector元素中，我们只能启用/禁用事件(类)，不能操作事件列！默认应该会添加事件对应的所有可用事件列，而且不会编辑列筛选器！
我们可以打开收集结束的跟踪文件，查看跟踪文件属性。如前所料，大部分事件列都被勾选，没有列筛选，5分钟跟踪文件中的记录数有833行：
但是生产环境中，我们可能期望加上必要的筛选。我们可能只想监控某个程序、或者某个登录名、或者TextData含某个关键字、或者CPU/Duration/Reads满足某条件的语句。
为SQLdiag配置添加跟踪过滤器
通过情况下，Profiler跟踪过滤器被添加到SQL Server数据收集中以减少由SQLdiag收集的诊断数据的数据量。请注意，文本过滤器会给数据收集增加CPU的开销，因为评估基于文本的过滤器会有显著的CPU开销，而整数型的过滤器不会有。如果使用SQLdiag的XML配置文件收集Profiler跟踪，需要遵循以下步骤：
1>启动服务器中的SQLdiag
2>使用fn_trace_getinfo函数或sys.traces视图找到Profiler跟踪的跟踪ID
3>使用sp_trace_setstatus停止跟踪，而不必删除定义
4>使用从第2步获得的跟踪ID，并使用sp_trace_setfiler存储过程来设置过滤器
5>使用fn_trace_getfilterinfo函数验证过滤器是活跃的
6>当你对过滤器是活跃的感到满意时，使用sp_trace_setstatus开始跟踪数据收集
为了测试，我们重新开启SQLdiag，使用下面脚本添加跟踪CPU>10的语句：
-- 获取跟踪文件的跟踪ID declare @TraceID int select @TraceID=id from sys.traces where [path] LIKE '%sp_trace.trc' -- 停止功能 exec sp_trace_setstatus @TraceID, 0 -- Set the Filters declare @intfilter int declare @bigintfilter bigint --Get trace_column_id --select * from sys.trace_columns tc --set @bigintfilter = 1000000 --exec sp_trace_setfilter @TraceID, 13, 0, 4, @bigintfilter--Duration>=1s --set @bigintfilter = NULL --exec sp_trace_setfilter @TraceID, 13, 0, 1, @bigintfilter--排除不包含值的行 set @intfilter = 10 exec sp_trace_setfilter @TraceID, 18, 0, 4, @intfilter--CPU>10 set @intfilter = NULL exec sp_trace_setfilter @TraceID, 18, 0, 1, @intfilter--排除不包含值的行 -- 启动功能 exec sp_trace_setstatus @TraceID, 1
我们同样分析一个.trc跟踪文件，并查看Reporter数据，5分钟后打开Profiler跟踪数据：
我们可以看到，跟踪文件中有Trace Stop/Start，在Stop之前有CPU=0的记录，Stop之后只有满足CPU>=10(ms)的才被跟踪到。同时注意5分钟跟踪文件中的记录数只有81行。实际操作中我们可以根据情况调整前面的过滤筛选值，其实我们可以将它保存到名为SQL_2008_SetFilters.sql的文件中，再将它添加到自定义收集器，那样就不用每次启动SQLdiag后再手动为跟踪数据添加过滤器。
SQL Nexus下的跟踪数据报表
我们使用SQL Nexus导入收集的SQLdiag数据，此时主界面的Perfmon Summary(性能计数器)、ReadTrace Reports(跟踪文件)都是可用的。点击ReadTrace Reports出现的页面是否很熟悉？对，它就是我们在RML中所看到的界面。
首先我们来看总界面Performance Overview：
然后点击Application Name，按Duration的总数排序：
我们可以直接点击Application Name，跳转到相关AppName下的Top Unique Batches，或者返回到Performance Overview页面，点击Unique Batches：
滚动鼠标滑轮，下面是Top Unique Batches按CPU排序的语句信息：
实际操作感觉SQL Nexus中的ReadTrace Reports没有单独使用RML全面，Parameters在SQL Nexus中貌似不起作用，不知是自己电脑有问题还是其他原因。
--10:53 2016/1/11
前天添加过滤器的跟踪在2016-01-09 13:42:20.250 Start，在2016-01-09 13:42:21.543 Stop，应用筛选后在2016-01-09 13:42:21.547重新Start，最后在2016-01-09 13:47:37.033 Stop
将跟踪用RML或SQL Nexus导入，开始时间-结束时间(1:42:20PM-1:42:22PM)只有两秒钟，只能导入sp_trace_setstatus停止跟踪前的数据
查看RML输出日志(日志保存于-o参数的路径下)、或者查看Nexus Log会提示ReadTrace参数(一般在C:UsersAdministratorAppDataLocalTempRML)，说是Reached the end of the trace; found [TRACE_STOP_EVENT]
前面的Stop是为了添加过滤器，从跟踪结果看过滤器是应用上了，但是使用RML导入分析却被TRACE_STOP_EVENT"提前"结束，如何用RML分析Stop后的跟踪文件？