使用默认system_health分析死锁(Deadlock)

在2008之前我们分析死锁须要用profiler trace或者trace flag 1222,1204.在2008中引入了一个新功能:Extended
Events(扩展事件)。能够监控Deadlock事件,而且性能更好。 

并且2008自带了一个默认扩展事件会话system_health,假设你执行在2008或者之上版本号能够执行以下查询: 

select
* from sys.dm_xe_sessions

当中system_health会收集非常多重要的信息,之后出现故障能够用来分析。system_health会话收集信息參考http://msdn.microsoft.com/en-us/library/ff877955.aspx。当中一项内容是:Any
deadlocks that are detected. 

也就是SQL Server会自己主动收集deadlock的信息。并记录在ring_buffer。

通过分析ring_buffer就能够找到死锁原因,这样就不须要使用profiler或者Trace
Flag收集信息。

使用以下的代码查看deadlock_report的内容:

SELECT    xed.value(‘@timestamp‘,‘datetime‘)as Creation_Date,

         xed.query(‘.‘)AS Extend_Event

 FROM    (   SELECT   CAST([target_data]ASXML)AS Target_Data

             FROM    sys.dm_xe_session_targetsAS xt

                     INNER JOIN sys.dm_xe_sessionsAS xs

                     ON xs.address= xt.event_session_address

             WHERE    xs.name=N‘system_health‘

                     AND xt.target_name=N‘ring_buffer‘)

 AS XML_Data

 CROSS APPLY Target_Data.nodes(‘RingBufferTarget/event[@name="xml_deadlock_report"]‘)AS XEventData(xed)

 ORDER BY Creation_DateDESC

默认的system_health在不影响性能的情况下将一些重要事件记录下来,方便我们后期做分析,这是一个很好的功能。避免了之前可能因为没有及时监控而找不到原因的状况。

时间: 2024-10-09 22:36:20

使用默认system_health分析死锁(Deadlock)的相关文章

通过SQL Server Profiler来监视分析死锁

在两个或多个SQL Server进程中,每一个进程锁定了其他进程试图锁定的资源,就会出现死锁,例如,进程process1对table1持有1个排它锁(X),同时process1对table2请求1个排它锁(X),进程process2对table2持有1个排它锁(X),同时process2对table1请求1个排它锁(X) 类似这种情况,就会出现死锁,除非当某个外部进程断开死锁,否则死锁中的两个事务都将无限期等待下去. Microsoft SQL Server 数据库引擎死锁监视器定期检查陷入死锁

Java死锁范例以及如何分析死锁(转载自ImportNew)

本文由 ImportNew - 范琦琦 翻译自 journaldev.欢迎加入翻译小组.转载请见文末要求. 死锁是两个甚至多个线程被永久阻塞时的一种运行局面,这种局面的生成伴随着至少两个线程和两个或者多个资源.在这里我已写好一个简单的程序,它将会引起死锁方案然后我们就会明白如何分析它. Java死锁范例 ThreadDeadlock.java 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

sqlserver 抓取所有执行语句 SQL语句分析 死锁 抓取

原文:sqlserver 抓取所有执行语句 SQL语句分析 死锁 抓取 在多人开发中最头疼的是人少事多没有时间进行codereview,本来功能都没时间写,哪有时间来开会细细来分析代码.软件能跑就行,但是一些影响性能的语句写出来,有可能本人都不知道.找就更 麻烦了.幸亏sqlserver提供了工具可以导出执行语句进行分析.可以看看是哪些语句影响整体性能.工具叫sql server profiler,这玩意可以抓取实例上执行的所有语句\死锁\事物,为分析提供帮助. 开始->sqlserver目录-

SQL SERVER性能分析--死锁检测数据库阻塞语句

工作中数据库经常出现内存,找了篇文章 参照CSDN,中国风(Roy)一篇死锁文章 阻塞:其中一个事务阻塞,其它事务等待对方释放它们的锁,同时会导致死锁问题. 整理人:中国风(Roy) 参照Roy_88的博客 http://blog.csdn.net/roy_88/archive/2008/07/21/2682044.aspx 日期:2008.07.20 ************************************************************************

详细分析死锁产生的条件与原因

一.定义 死锁:集合中的每一个进程都在等待只能由本集合中的其他进程才能引发的事件,那么该组进程是死锁的. 由于资源占用是互斥的,当某个进程提出申请资源后,使得有关进程在无外力协助下,永远分配不到必需的资源而无法继续运行,这就产生了死锁这一特殊现象. 二.产生死锁的必要条件 1)互斥条件:指进程对所分配到的资源进行排它性使用,即在一段时间内某资源只由一个进程占用.如果此时还有其它进程请求资源,则请求者只能等待,直至占有资源的进程 用毕释放. 2)请求和保持条件:指进程已经保持至少一个资源,但又提出

一个 Linux 上分析死锁的简单方法

转自:https://www.ibm.com/developerworks/cn/linux/l-cn-deadlock/ 简介 死锁 (deallocks): 是指两个或两个以上的进程(线程)在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力作用,它们都将无法推进下去.此时称系统处于死锁状态或系统产生了死锁,这些永远在互相等待的进程(线程)称为死锁进程(线程). 由于资源占用是互斥的,当某个进程提出申请资源后,使得有关进程(线程)在无外力协助下,永远分配不到必需的资源而无法继续运行,

[Android Pro] 通过Android trace文件分析死锁ANR

转载自: http://blog.csdn.net/oujunli/article/details/9102101#reply 对于从事Android开发的人来说,遇到ANR(Application Not Responding)是比较常见的问题.一般情况下,如果有ANR发生,系统都会在/data/anr/目录下生成trace文件,通过分析trace文件,可以定位产生ANR的原因.产生ANR的原因有很多,比如CPU使用过高.事件没有得到及时的响应.死锁等,下面将通过一次因为死锁导致的ANR问题,

jQuery EasyUI Datagrid组件默认视图分析

在Datagrid基础DOM结构的一文中,我对Datagrid组件的骨架做了很详细的描述.有了骨架还并不完整,还得有血有肉有衣服穿才行.强大的Datagrid组件允许我们自己定义如何在基础骨架上长出健壮诱人的身体,我们只要定义Datagrid的视图就可以实现. 在大多数情况下,我们并无特别要求,Datagrid给我们提供了默认的视图,默认视图被使用在90%以上的场景,所以对默认视图的分析显得非常有必要.注意视图里面定义了哪些接口,哪些方法,如果要自己写视图的话,最好把这些接口和方法都写齐全.话不

iOS学习笔记-死锁deadlock理解

1.首先看一下官方文档的解释,这个block的队列是同步执行的,不像异步,这个方法直到block执行完毕才会返回 2.主线程一旦开启,就要先把自己的代码执行完成之后,才去执行加入到主队列中的任务 死锁原因: a)       dispatch_sync这个方法要等到block的执行完之后,才返回 b)      主线程一旦开启,就要先把自己的代码执行完成之后,才去执行加入到主队列中的任务 c)       这样主线程想要执行block,先要下去执行下面的代码,但是因为dispatch_sync这