当前应用时常会出现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"如下:
为了区别不同的类型,可以用锁类型,以及持有者和等待者的持有/等待模式,为每种类型创建一个标识。例如,上述图中展示了如下特征:
1. Deadlock Graph包含超过1行的记录。
2. 所有的锁类型都是TX。
3. 持有者和等待者的锁模式都是X(排它锁,模式6)。
关注图中特殊的一些特征:
将会得到如下类型(典型的应用死锁):
TX X X TX X X
注意:对于死锁类型识别的”关键标识“中最相关的部分就是锁类型和请求的模式。主要的类型如下表:
注意:如何判断和诊断不同类型的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 graph的问题有如下特征:
1. Deadlock Graph多于一行。
2. 至少有一行是”TX X X“,例如,锁类型是TX,锁的持有者模式是"X",不等待任何。等待者等待"X",不持有任何。
如果deadlock graph包含一些上述未提到的特征,那么先处理这些问题,因为这些问题可能是根源。
从”Rows waited on“节可以找到”dictionary objn“对应的Object ID。
也可以使用如下SQL查询Object ID对应的名称和类型:
trace文件也应该展示出两个session正在运行的SQL,还有应用的模块信息。在deadlock graph下面的第一部分就是从”Information on the OTHER waiting sessions:"到”End of information on OTHER waiting sessions."之间的部分,展示的是包含于这个deadlock的”Other“ session。
可以抽取如下信息:
在这节之后,就是检测到deadlock的session信息。以及SQL和调用栈(上面图中最下方),可以从PROCESS STATE节中得到更多关于操作系统进程的信息。
关于应用、SQL以及运行SQL的程序等等。
关于检测到deadlock的Oracle和操作系统信息可以在trace文件头中找到。
利用这些信息可以做什么?
通过上面的分析,可以得到如下信息:
1. deadlock中的object名称。
2. Oracle和操作系统名称。
3. 操作系统终端与程序细节。
4. 对于持有和等待session运行的SQL。
5. PL/SQL调用栈信息提供包的细节。
这些信息可以提供找到包含于deadlock的代码问题。判断为什么会出现deadlock,修改这些代码或者锁存储过程,以至于锁的顺序不会产生deadlock现象。