关于如何判断与解决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"如下：

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

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现象。