关于如何判断与解决deadlock的问题

当前应用时常会出现deadlock的alert记录,关于如何判断与解决deadlock的问题,有一些介绍性的文章值得阅读。


How to Identify ORA-00060 Deadlock Types Using Deadlock Graphs in Trace (文档 ID 1507093.1)

        当Oracle检测到死锁后,会取消当前检测到死锁的SQL执行,并进行语句级回滚,以释放资源,不会阻塞所有活动。检测到死锁的session仍旧可用,其它的交易也处于active状态。如果重复执行这个session的该SQL,那么会再次检测到死锁。

        当检测到死锁后,会产生一个trace文件,其中包含了“Deadlock Graph”(还有别的有用信息)。

        有时trace中不包含这样的"Deadlock Graph"节信息,这种情况下,建议的操作是采集一些额外的诊断信息(例如10027事件),可参考:Document 1552194.1 ORA-00060 Deadlock Graph Not Matching any Examples: Suggested Next Steps。


"Deadlock Graph“的解释

典型的一个"Deadlock Graph"如下:

关于如何判断与解决deadlock的问题_第1张图片

为了区别不同的类型,可以用锁类型,以及持有者和等待者的持有/等待模式,为每种类型创建一个标识。例如,上述图中展示了如下特征:

1. Deadlock Graph包含超过1行的记录。

2. 所有的锁类型都是TX。

3. 持有者和等待者的锁模式都是X(排它锁,模式6)。

关注图中特殊的一些特征:

关于如何判断与解决deadlock的问题_第2张图片


将会得到如下类型(典型的应用死锁):

TX X X
TX X X

注意:对于死锁类型识别的”关键标识“中最相关的部分就是锁类型和请求的模式。主要的类型如下表:

关于如何判断与解决deadlock的问题_第3张图片

注意:如何判断和诊断不同类型的ORA-00060死锁的相关信息,可以参考:Document 1559695.1 How to Diagnose Different ORA-00060 Deadlock Types Using Deadlock Graphs in Trace。

        以上是最常见的类型与原因,极少有不同原因导致相同现象的情况。如果怀疑特定的非应用死锁类型或者有其它的deadlock graph,可以提交一个Service Request。

        Oracle锁类型有如下几种:

0 - none
1 - null (NULL)
2 - Row Share, also called a subshare table lock  (SS)
3 - Row eXclusive Table Lock, also called a subexclusive table lock (SX)
4 - Share Table Lock (S)
5 - Share Row-eXclusive, also called a share-subexclusive table lock (SSX)
6 - EXclusive (X)

注意:经常可以看到一种混合的deadlock graph:



此时是”Application deadlock“和”Missing Index on Foreign Key (FK) Constraint“的混合。建议先处理非”TX X X“的现象,因为这是一种常见的情况,不常见的FK/ITL/Bitmap可能是根源。

注意:trace文件中会包含不同的信息片段,其中有些是和问题相关的,有些则不是。例如,在”Rows Waited on“节,”dictionary objn“的值能用来明确相关的对象,但有时候,会提供毫不相关的信息。如果信息有用,那么就关注它,否则不要依赖于这些信息。



在当前应用中碰到的死锁问题是属于如下类型:

TX X X
TX X X

How to Diagnose Different ORA-00060 Deadlock Types Using Deadlock Graphs in Trace (文档 ID 1559695.1)中介绍了关于”Signature:TX Lock Requesting Mode X (6)(TX X X)"这种类型的锁:

关于如何判断与解决deadlock的问题_第4张图片


这种类型deadlock graph的问题有如下特征:

1. Deadlock Graph多于一行。

2. 至少有一行是”TX X X“,例如,锁类型是TX,锁的持有者模式是"X",不等待任何。等待者等待"X",不持有任何。

如果deadlock graph包含一些上述未提到的特征,那么先处理这些问题,因为这些问题可能是根源。


从”Rows waited on“节可以找到”dictionary objn“对应的Object ID。

关于如何判断与解决deadlock的问题_第5张图片


也可以使用如下SQL查询Object ID对应的名称和类型:

关于如何判断与解决deadlock的问题_第6张图片


trace文件也应该展示出两个session正在运行的SQL,还有应用的模块信息。在deadlock graph下面的第一部分就是从”Information on the OTHER waiting sessions:"到”End of information on OTHER waiting sessions."之间的部分,展示的是包含于这个deadlock的”Other“ session。

关于如何判断与解决deadlock的问题_第7张图片


可以抽取如下信息:

关于如何判断与解决deadlock的问题_第8张图片关于如何判断与解决deadlock的问题_第9张图片


在这节之后,就是检测到deadlock的session信息。以及SQL和调用栈(上面图中最下方),可以从PROCESS STATE节中得到更多关于操作系统进程的信息。

关于如何判断与解决deadlock的问题_第10张图片


关于应用、SQL以及运行SQL的程序等等。


关于检测到deadlock的Oracle和操作系统信息可以在trace文件头中找到。




利用这些信息可以做什么?

通过上面的分析,可以得到如下信息:

1. deadlock中的object名称。

2. Oracle和操作系统名称。

3. 操作系统终端与程序细节。

4. 对于持有和等待session运行的SQL。

5. PL/SQL调用栈信息提供包的细节。

这些信息可以提供找到包含于deadlock的代码问题。判断为什么会出现deadlock,修改这些代码或者锁存储过程,以至于锁的顺序不会产生deadlock现象。

你可能感兴趣的:(Oracle,文档,MOS)