使用Extended Events诊断SQL Server 2012

Extended Events是SQL Server 2012自带的轻量型诊断工具。如果你已经熟悉Profiler和SQL Trace这样的工具，那么基于当前的监视，你就熟悉下面的例子：解决阻塞和死锁、发现长时间运行的查询、追踪DDL操作、记录缺失的列统计。发掘Extended Events更为高级的功能时，你会看到它很容易追踪如下事件：长时间运行的物理I/O操作、引起特定wait sats发生的语句、SQL Server内存压力及AlwaysOn Availability Groups事件。

Extended Events会收集和存储特定事件相关的额外信息，其相关术语如下：

Sessions

Extended Events session是用户自定义的events、actions,、filters和targets的组合，存放在SQL Server实例中。你可以使用T-SQL或SSMS的GUI创建一个session。图13-2显示了SSMS中它的位置及一些已经配置的对话。右击某个会话，可以看到其相关的选项。

Events

Events是SQL Server中发生的事情。为了存储事件定义及内部代码，Extended Events引擎使用自带的叫做包的容器。如果你想知道有些什么样的包，你可以使用如下查询：
select name, description from sys.dm_xe_packages

事件自身也可以通过DMV查看，查询语句如下：select name, description from sys.dm_xe_objects where object_type = 'event' order by name

Extended Events对等的Profiler事件，可通过如下查询查看：

select t.trace_event_id as 'Trace Event ID', t.name as 'Trace Event Name',
x.xe_event_name as 'XE Event Name'
from sys.trace_events t
join sys.trace_xe_event_map x
on t.trace_event_id = x.trace_event_id

Event Fields
你可以从Extended Event DMV中查询一个事件的时间栏位列表，例如下面的查询：

select c.name, c.description
from sys.dm_xe_object_columns c
join sys.dm_xe_objects o on o.name= c.object_name
where o.name = 'sql_statement_starting'

Actions
当你配置一个对话要监视一个事件发生时，事件自身不大可能提供你解决问题所需的所有数据。Actions就是Extended Event为你提供额外数据的途径。SQL Server 2012有48个Actions或全局栏位。你可以通过如下SQL查询可用的Action：

SELECT name, description FROM sys.dm_xe_objects WHERE object_type ='action' and capabilities_desc is null ORDER BY name

Action抓获到所需的额外数据后，会以异步形式将其写入日志文件，因此它不会影响用户查询的性能。

Filters

 Filters在Extended Events上下文中也称为判断，两个术语都描述了它们的用意，因为定义session时它们的行为像WHERE语句，仅仅满足特定标准的事件才执行。Filters能够深入数据库内部对象，及SQL Server实例的、查询的运行时属性。因此，你开始时，最常使用的filters是用于查询的运行时期间，锁或对象ID。定义的过滤常被认为是一个布尔表达式，这意味着你应该把焦点放在使用=,>,<及<>操作符上。下面是定义session时filter的例子：

• 所有用户数据库的事件：sqlserver.database_id > 4
• 所有用户数据库中非系统任务执行的事件：sqlserver.database_id > 4 and sqlserver.is_system = 0
• 耗时超过10秒的查询：duration > 10000

可用的过滤（判断源）可以通过如下查询获取：

select name, description from sys.dm_xe_objects where object_type = 'pred_source'

Extended Events使用一个称之为short circuiting（短路）的方式来评估一个session的过滤，目的是控制开销，因此它比其他工具都高效。

Targets

Target是所有Extended Events抓取的信息的目的地。

Event Files：  驻留在OS驱动器的平面文件，事件数据就是被写入到这里。它们会保留，直到你手动去删除。事件文件自身有默认的扩展名.xel，存放二进制数据，没有像SSMS这样的工具是不可读的。SSMS能够打开这些文件，即使是从其他服务器上获得的。它能够把数据导出到一个数据库表中，或一个CSV文件中。Extended Event引擎首先把数据写入内存缓存区，然后由第二个进程把它从内存写入磁盘，这种行为也被视为异步的。

Memory Buffer Size：  可配置，FIFO策略。

Event Retention：  如果内存缓存区填满了，也可以配置一个称之为Event Retention的选项。有3种选项来决定内存缓存区满了后该如何响应：no event loss、single event loss（默认选项）和multiple event loss。

Maximum Dispatch Latency：  要确保内存缓存区从不填满，有两个方案，设置一个很大的memory buffer size，或配置maximum dispatch latency。默认值是30秒。

Ring  Buffer：  类似event file target。两者最大的差异是SSMS不会把XML内容翻译成可读的数据。另一个差异是ring buffer不会使用任何物理存储，纯粹是一个内存结构，很像memory buffer。因此，里面的数据在填满时、及空间被新的事件占用时，或SQL Server停止时会丢失。

Event  Counter：  它不会存储任何事件数据，而是对事件发生的次数进行计数。它类似ring buffer，是一个in-memory structure。

Histogram（直方图）：在你识别数据趋势时非常有用，它能够让你聚焦事件细节的一个特殊类型，它也是内存结构，其内容不会写入到事件文件。如图13-4所示，wait stats 796和131发生最频繁，但需要DMV查询来获知它们是什么：select map_key, map_value from sys.dm_xe_map_values where name = 'wait_types' order by map_key

 

Pair Matching：  是另一个事件数据处理target，不是存储target，使你能够舍弃结果集中的2套相关的事件数据。

Event  Tracing for Windows(ETW)： 硬核端的target。使用ETW使SQL Server能够把事件数据和外部Windows调试软件集成起来，以便获取一张完整的系统性能图。