【www.350.vip】扩展事件,Server扩展事件的使用ring_buffer

三,以文件存款和储蓄Target的数码

大家能够侦查增添事件指标占用的内部存款和储蓄器和DMV中的XML二进制数据攻克的内部存款和储蓄器情形,使用如下查询

拟订输出数据存款和储蓄的对象(target),该tab中列出 Event File target 和 ring
buffer target。

www.350.vip 1

1,以Rollover 格局复用事件文件

  www.350.vip 2

当Target的称呼是 event file 时,Session 输出的数额实际上是储存在Event
file中。

 

SQL Server
扩充事件捕获的信息,叫做Target,使用Target来存款和储蓄伊芙nts,Target
能够把捕获的新闻存款和储蓄到文件中(扩充名是 .xel),或 memoy buffer 中(Ring
Buffer),Target能够以同盟或异步格局管理多少,事件的多寡都以以XML格式存款和储蓄。

实在意况是,事件(event)实际上在就这里,你不能够看出(你预期的平地风波)是因为sys.dm_xe_session_targets
这个DMV的限制。
本条DMV的靶子数据列只好输出大概4 MB的XML数据。
Bob Ward20029年的时候在CSS SQL Server程序猿博客中表达了DMV的4
MB格式XML节制的消息。
为了验证这种范围的结果,让大家来拜见在SQL Server 2013SP1+CU7服务器上的系统常规事件会话中蕴藏的平地风波数量,作者能够运用上边包车型客车查询来查阅音信。

www.350.vip 3

自己发今后繁忙的服务器上面世难题时,sp_server_diagnostics_component_output事件的轻重当先了512KB,
就此当输出XML中满含在那之中贰个风云时,对ring_buffer目的,由DMV再次来到的数量或然会遭遇十分大规模。

www.350.vip 4

CREATE EVENT SESSION [Deadlock_Monitor] ON SERVER
ADD EVENT sqlserver.xml_deadlock_report
ADD TARGET package0.ring_buffer(SET max_events_limit=(5000),max_memory=(4096))
WITH
(MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=10 SECONDS,
MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=ON)

ALTER EVENT SESSION [Deadlock_Monitor] ON SERVER STATE = start;

Step5,选用捕获的字段(Capture Global Fields)

我从SQL Server中心的一篇文章中得到了下面的代码,它不起作用。我遇到的问题是,当我运行代码时,即使我知道应用程序中刚刚发生了一个死锁事件,它也不会显示任何死锁信息。
似乎我只在system_health会话中看到较旧的死锁,但从来没有看到最新的死锁。我打开了Trace 1222并以这种方式获取信息,那么为什么不这样做。

大器晚成,创造扩展事件的对话

 

Target对于扩展事件产生的多少,总是先缓存在内部存款和储蓄器buffer中,等到内部存款和储蓄器buffers储存丰裕数量的数据之后,再将内部存款和储蓄器中的具备数据写入到文件中。文件中的数据滞后于内存buffer,那便是异步写(Async
Write),可以裁减IO的次数,进步IO成效。事件文件类型的taget的扩充名是xel,以XML格式存款和储蓄Target
数据,使用 sys.fn_xe_file_target_read_file
函数查看事件文件中蕴藏的数目。

那是自身透过电子邮件解释有关ring_buffer指标的最广大难点。日常的话,如下是顶级的主题材料陈说:

www.350.vip 5

system_health事件会话极度同情于搜聚最多5000个事件但ring_buffer,DMV实际上只好输出一小部分事变会话。
最有希望的是,sp_server_diagnostics_component_output和xml_deadlock_report具备一定大的风云是(占用的长空),因为那多个事件再次来到的XML的大小决议于它们曾几何时触发的尺度的具体情形。

sys.dm_xe_session_targets
(Transact-SQL).aspx)

没有UI的支持

Realistic troubleshooting example of extended events (XEvent) usage in
SQL Server 2008 – Part
1

  由于sysem_health有八个出口的target,叁个ring_buffer,一个是target_file,无语下从event_file查询捕获的死锁音讯,这里又是没难点的,寻常捕获到了。

2,从 sys.dm_xe_session_targets 中查看target输出

在生育服务器上安顿ring_buffer指标的章程供给丰裕小心,那对本人来讲是默默的。
两周在此之前,Andy Galbraith遭遇一个全体连接报701种类内部存款和储蓄器不足的错误,
经过解析,Andy发以后内部存款和储蓄器16GB,最大内部存款和储蓄器(max server
memory)配置为11000MB的服务器上,MEMO冠道YCLEXC60K_XE memory clerk
占用了10GB的内存,
难点就在于,多个恢弘事件配置了搜罗最大(MAX_EVENTS_LIMIT)1,000,000
个事件,不过尚未布置最大内部存款和储蓄器限定,
于是内部存储器的选取就借助扩展事件采访到的事件个数,何况未有最大的内部存款和储蓄器使用范围,那么它就足以动用无限的内部存款和储蓄器,在内部存款和储蓄器有限的情状下,进而引致服务器上现身难点。

六,查询会话(session)和 target

 

Ring buffer target使用Memory buffer来存款和储蓄Session
Output,假如分配的memory
buffer用完,target会将最老的伊夫nts删除,以包容新的Events,使memory
buffers中积存的是most recent data。

SELECT
    target_data.value('(RingBufferTarget/@memoryUsed)[1]', 'int') AS buffer_memory_used_bytes,
    ROUND(target_data.value('(RingBufferTarget/@memoryUsed)[1]', 'int')/1024., 1) AS buffer_memory_used_kb,
    ROUND(target_data.value('(RingBufferTarget/@memoryUsed)[1]', 'int')/1024/1024., 1) AS buffer_memory_used_MB,
    DATALENGTH(target_data) AS xml_length_bytes,
    ROUND(DATALENGTH(target_data)/1024., 1) AS xml_length_kb,
    ROUND(DATALENGTH(target_data)/1024./1024,1) AS xml_length_MB
FROM (
SELECT CAST(target_data AS XML) AS target_data  
FROM sys.dm_xe_sessions as s
INNER JOIN sys.dm_xe_session_targets AS st 
    ON s.address = st.event_session_address
WHERE s.name = N'system_health'
 AND st.target_name = N'ring_buffer') as tab(target_data)

运用TSQL创制扩大事件的进程相比较复杂,可是,大家能够动用其它风流倜傥种简单的秘诀:使用扩展时间的始建向导。

我已经多次遭遇扩张事件中有关ring_buffer target近似的标题,
本身想小编会写意气风发篇博客随笔,解释了小编教的富有消息有关ring_buffer
target和与之提到的主题素材。
从今sqlserver
2011透露以致扩张事件新UI的更新,作者从此现在坚决不会再利用ring_buffer
target
实际,正如作品标题所言,笔者真正很讨厌ring_buffer
target,那篇作品中本人将会演讲本人讨厌ring_buffer
target的案由,並且期望说性格很顽强在艰难险阻或巨大压力面前不屈应该选用file_target代替。

2,查看会话target的构造

  由此就足以说,系统暗许自带的sysem_health扩张事件,捕获死锁自己是从未难题的,难点出在扩充事件的输出目的ring_buffer上。
  在但是滤全体的强盛事件境况下,从ring_buffer里面剖析出来的多寡还应该有个特点,其不包涵近来风流罗曼蒂克段时间的此外少年老成种事件音信。
  也正是说,ring_buffer中解出来的平地风波音信,是现阶段岁月前豆蔻年华段时间的平地风波消息,并不包涵所有的事件音讯,以至新近后生可畏段事件有所的风浪信息。
  当然你能够说ring_buffer是先进先出的种类模型,那也应有留给新的事件,并非解析不出来最新的风云消息。

Using Xquery to query Extended Events asynchronous file target
results

www.350.vip 6

SQL Server 扩张事件(Extended
伊夫nt)是用于服务器的寻常化事件管理系统,是追踪SQL
Server系统运营境况的神器,同一时间也是贰个日记记录工具,扩大事件完全能够替代SQL跟踪(SQL
Trace),增添事件的宏图功效:

此间大家能够看见,二进制数据占用的内部存款和储蓄器大概为1.7MB,可是假设连串化为XML,文件的朗朗上口就改成大致4.7MB,比二进制数据空间要大
题指标精气神儿就在于,扩充事件生成的风味,决定了她牢牢的二进制格式的,不过连串化的格式化XML会为那一个事件扩大存款和储蓄空间。

www.350.vip 7

错过事件

select s.name as xe_session_name,
    st.target_name,
    st.execution_count,
    st.execution_duration_ms/st.execution_count as avg_execution_ms,
    st.target_data
from sys.dm_xe_session_targets st 
inner join sys.dm_xe_sessions s 
    on st.event_session_address=s.address

那意味要动用数据,您必需展开XML并扫描事件,或编辑XQuery以将XML分析为表格格局,那供给您领略事件会话中接纳的风云,列和操作定义来实在访谈数据。
若果本身正在扩充短期数据搜罗,何况不希望它保存到SQL Server
二〇一二上的文件系统中的文件,作者只需选拔实时视图就足以将数据流式传输回UI的列表中,
在此种情景下,小编不要管理XML并能够高速找到小编感兴趣的音信。
对于其余长时间任务,以致查看system_health事件会话中的音讯,小编都选拔file_target,UI可以读取和处管事人件,无需手动施行别的XQuery。

经过TSQL 脚本获取的Target 输出都以以XML格式显示的,通过View Target
Data能够以 表格 方式查看Target的输出

 

www.350.vip 8

译者注,如下是system_health中ring_buffer
MAX_EVENTS_LIMIT选项设定在5000的值:

2,从 sys.dm_xe_session_targets 中查看事件文件的积累路线

www.350.vip 9

Ring buffer
target将事件数量保存到内部存款和储蓄器中,事件数量以XML格式存款和储蓄。少年老成旦事件数量把分配的内部存储器Buffers
用尽,那么最老的平地风波数量将被免除。

 

二,查看增添事件捕获的音信

 

Step7,钦命会话数据的蕴藏(Specify Session Data Storage)

 

sys.fn_xe_file_target_read_file
(Transact-SQL).aspx)

   如下自定义扩大事件脚本

select s.name as xe_session_name,
    cast(st.target_data as xml) as target_data
from sys.dm_xe_sessions s 
inner join sys.dm_xe_session_targets st 
    on s.address=st.event_session_address
where s.name='xe_session_name'

通常来讲是译文,原来的小说地址:

buffer_policy_desc:用于表述当buffer耗尽时,扩充事件会话是什么管理新触发的事件:

ring_buffer_event_count是RingBufferTarget根成分再次来到的XML文书档案的eventCount属性(译者注:ring_buffer_event_count是RingBufferTarget捕获到的事件的总的数量)
event_node_count是sys.dm_xe_session_targets 那几个DMV中回到的ingBufferTarget/event
nodes中事件的个数(两个的差值正是所谓遗失的平地风波个数)
此地您能够看见ring_buffer
target中总结有5000个事件,(原因是)system_health会话基于二零一二新的MAX_EVENTS_LIMIT选项设定在5000。
唯独,仅只有35七十多个事件被DMV中的XML输出了出去,剩下有14二十七个事件依然不可用(不可以知道,不可能解析出来),固然她们是栖息在内部存款和储蓄器中的。
sys.dm_xe_session_targets
的XML文件优先出口更早的事件,所以大家预料下的那二日爆发的风浪是万般无奈看出的。

select s.name,
    s.total_regular_buffers*s.regular_buffer_size/1024 as total_regular_buffer_kb,
    s.total_buffer_size/1024 as total_buffer_kb,
    s.buffer_policy_desc,
    s.flag_desc,
    s.dropped_event_count,
    s.dropped_buffer_count
from sys.dm_xe_sessions s

 

  • 鉴于扩张事件引擎不识别事件,由此,引擎能够将别的事件绑定到别的目的,因为引擎不受事件开始和结果限制。
  • 事件与事件使用者不一样,前面一个在增添事件中称之为“目的”(Target),约等于说任何指标能够接过任何事件。其他,引发的别的事件均可供指标活动使用,那样能够记下或提供额外的风浪上下文。
  • 事件区别于在事件激发时要施行的操作。因此,任何操作能够与任何事件相关联。
  • 谓词能够动态筛选事件的激情,从而加强了扩充事件基本功构造的灵活性。

总结:  
  以此来看,使用ring_buffer为扩张事件的target,潜在以下难点
  1,解析出来的结果并不保障(完整),恐怕不能分析到近年来的片段事件。
  2,以下译文中还有也许会提到,ring_buffer作为target或许会撑爆内存的状态,所以要严格选取。
  3,相像下文仲提到,SSMS的UI对ring_buffer中的事件帮衬的并不佳,对于ring_buffer的target,UI也唯有是show出来三个XML文件,一定要和睦分析,而不像event_file中那么表格化体现(可读性)
  因而要尽量制止在扩张事件中利用ring_buffer target。

Step8,查看扩张事件会话的集聚音信,开首创办事件会话。

原因分析:
  仿效了sqlskill上的蓬蓬勃勃篇小说,那篇小说深远地分析了那些问题,
  轻易说正是:
  ring_buffer并不曾“错过”事件新闻,至于为啥深入深入分析不出来,要从ring_buffer拆解解析形式起头,ring_buffer扩张事件从sys.dm_xe_session_targets
这么些DMV中深入分析的,
  受到sys.dm_xe_session_targets
那个DMV的靶子数据列target_data字段只可以容纳大概4 MB的XML数据的范围。
  当ring_buffer捕获的事件(内部存款和储蓄器中的二进制数据)调换为XML格式大于(大致)4MB的图景下,超越4MB的其他的平地风波会被被“截断”,
  从sys.dm_xe_session_targets分析出来的XML文件优先出口更早的风浪,所以咱们预料下的近年发出的平地风波是不只怕看见的。
  由此,正如上文中境遇的气象同样:“错失”部分轩然大波音讯,并且未有近些日子的平地风波新闻。

发表评论

电子邮件地址不会被公开。 必填项已用*标注