SQLSERVER2012里的扩展事件初尝试（下）
我们继续文章扩展事件在Denali CTP3里的新UI（二）里的这个实验
脚本文件下载：http://files.cnblogs.com/lyhabc/instnwnd.rar
我们打开上篇创建的blogtest扩展事件会话的属性
检查一下sql_statement_starting事件和sql_statement_completed事件的谓词是不是database_name=’Northwind’
运行workload
大家可以看到instnwnd.sql这个文件是比较大的，执行的时候会产生一些workload
我们启动blogtest会话
然后执行instnwnd.sql脚本
如果你的机器运行这个脚本很长时间，你可以点击工具栏的“停止数据反馈”，SSMS会停止继续显示实时数据
实时数据窗口可能只有两个列name和timestamp，这是仅有的2个所有扩展事件共有的列
你可以选择工具栏上的选择列按钮，添加/删除需要显示的列
我增加了3个列database_name，duration和statement
我们要找到Northwind数据库里平均执行时间最长的query，首先我们可以过滤不必要的事件
上篇曾提到过谓词可以在SQL Server端避免不需要的事件被产生，我们同时也支持客户端的过滤器，这可以帮助你做各种分析
点击工具栏上的筛选器按钮，这将打开筛选器对话框
这里我们设置两个条件name=sql_statement_completed And database_name=Northwind
为了避免输入错误，你可以从事件列表里拷贝粘帖，你还可以右键点击某个单元格，然后选择Filter by this Value，
这将自动为你添加一个子句并And到原有条件上
设置完毕之后点击确定
过滤掉不必要的事件后我们按照statement来做分组，点击工具栏上的分组按钮
把statement移动到右边，点击确定
分组的目的是为了计算每个分组上duration的平均值，下面可以点击工具栏上的聚合按钮
我们在duration上聚合类型选择AVG
然后选择在duration(AVG)上按降序排序
这样duration平均值最大的分组将被显示在第一行
我执行instnwnd.sql的workload里duration最大的分组是“exec master.dbo.sp_MSdbuserpriv N'serv'”
它的duration是13610微秒，这样我们就找到了平均开销最大的query
我们用单位换算器换算一下
你可以通过 打开-》合并扩展事件文件-》来打开生成的xel文件
总结
大家一定会好奇，为什麽在创建事件会话的时候会有筛选器，在SSMS工具栏又有筛选器
其实扩展事件是属于SQLSERVER端的，把SQLSERVER profiler的功能搬到SQLSERVER端，当然不是简单的搬到SQLSERVER端
而SSMS的工具栏只是提供一些分析xel文件的工具，这些跟SQLSERVER profiler是差不多的
比如人家给你一个xel文件，你需要SSMS的扩展事件工具栏的工具去分析
而以前SQLSERVER profiler是属于客户端的（是一个客户端工具），profiler获取SQLSERVER端的各种事件，然后传送回客户端，
在SQLSERVER profiler界面上显示给大家
所以大家可以理解为扩展事件就是把SQLSERVER profiler的功能集成到SQLSERVER端，反正我是这样理解的，不过这个集成不是简单的集成
扩展事件读取的三种方法对比
这一章节介绍三种审计日志分析方法的对比，我们将会从以下几个角度来衡量这三种方法：
DMF
sys.fn_xe_file_target_read_file是SQL Server本身内置的对象，所以使用这种方法分析审计日志信息，无需过多的编程处理，门槛较低，甚至可以直接使用SSMS都可以分析审计日志文件。这些是使用DMF分析审计日志的优点。当然，这个方法的缺点也很明显：使用DMF方式读取审计日志，需要连接到SQL Server服务，所以要求SQL Server服务本身是启动的，因为这个是使用SQL Server内置的动态管理函数来实现的；而且这种分析方法需要使用SQL Server对XML操作技术来解析event_data，解析XML是一个CPU密集型操作，非常消耗系统CPU资源。在我之前的测试案例中，使用DMF方法分析审计日志详情导致了50%多的额外CPU开销。如下截图所示：
XEReader API
使用SQL Server XEReader提供的API读取审计日志文件的方法，完全是基于审计日志文件的操作方式，可以独立于SQL Server的服务。换句话说，不管SQL Server是处于关闭还是启动状态，对我们审计日志的分析不会受到任何影响。这些是使用XEReader API分析审计日志的优点。而这个方法也有它的缺点：当我们分析当前（正在被Extend Event Session对象写入的日志文件）审计日志文件时，我们不知道（或者很难知道）哪些记录是我们分析过的，哪些是还未分析的？如果这个问题解决不了的话，很可能就会导致审计日志记录的重复或者丢失。当然，我们也可以采用XE循环写入审计日志文件的方法，每次读取Archive出来的审计日志文件，跳过当前文件的读取，等待当前文件写满固定大小，Archive出来以后，再来读取分析。这个改进方法会引入另外一个问题是，可能会导致审计日志的分析延迟，而且延迟的时间还不确定。比如：用户查询在10分钟后才写满当前审计日志文件，那么延迟是10分钟；如果用户查询在1个小时之内才写满当前审计日志文件，那么延迟将是1个小时。
事件流读取
基于用户查询事件流式分析审计日志的方法，优点也特别明显：延迟非常小，可以控制在秒级内，实时性表现良好，它解决了XEReader API查询事件延迟的问题。然而缺点是：也需要依赖SQL Service的启动状态，否则会报告异常；在大量查询瞬间（短时间内）执行的时候（比如用户不小心写了一个死循环查询），重启SQL Service或者Extend Event Session状态时，根据我测试的情况来看，这种场景会导致审计日志记录丢失，可靠性得不到保证。
最后总结
基于以上三种审计日志分析方法的优缺点总结来看，我们综合打分汇总如下：
DMF：对SQL Service有依赖，得分0；延迟取决于Offset的移动效率，得分80；稳定性有保证，得分100；对SQL Server CPU影响较大，得分为0；
XEReader API：对SQL Service无依赖，得分100；延迟取决于查询产生的速度，得分50；稳定性有保证，得分100；对SQL Server 影响很小，得分为0；
XEReader Stream：对SQL Service有依赖，得分0；延迟非常低，得分100；有不稳定的场景存在，得分50；对SQL Server 影响较小，得分为100；
阿里云内核月报：http://mysql.taobao.org/monthly/2017/08/08/
如有不对的地方，欢迎大家拍砖o(∩_∩)o