Oracle RAC Cache Fusion 系列十二：Oracle RAC Enqueues And Lock Part 3

旧城等待， 2021-10-19 21:32 228阅读 0赞

**死锁检测**

Oracle RAC的死锁检测在多层完成，并且是由超时机制驱动。

\- ksq解决本地死锁问题。

\- kjd解决全局死锁问题。

\- 消息流量控制器（TRFC）预防消息的死锁问题。

在生产环境中涉及的资源和锁的数量非常多，因此查找是否存在死锁可能非常耗时消耗系统资源。 因此，当有进程发生长时间的等待时，系统会认为很大概率是存在锁死问题，Oracle内核会使用“when needed”方法来检查死锁。

下图显示了经典的死锁场景。 我们常说的有问题的资源可以是任何对象。 在服务器中，可以是行，表，ITL事务槽或library cache和dictionary cache lock。 这种死锁的情况也可能发生在RAC集群中，即进程位于不同的节点上也会有死锁情况的发生，因为他们要访问修改共同的资源。

![aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X3BuZy85UmpScnZPNjN6ZElxU2FzN2p6OVlNN2UzY1BncGx4eHZLaFBwWkw0d2NmTWZFQWNTdzBxNUY1WldLcFcycTNoTUpOd1ZyZ1NQSmw5eWtuaWJ6Q2FoaWFnLzY0MD93eF9mbXQ9cG5nJnRwPXdlYnAmd3hmcm9tPTUmd3hfbGF6eT0xJnd4X2NvPTE][]

在这种情况下，两个进程在不同的节点上，资源以主和影子方式分布在不同节点。 很明显，在多节点环境中，死锁检测需要跟踪集群中所有节点间锁的转换和阻塞者。 由前面系列文章我们可以知道这个动作由LMD进程执行。

只要进程共享资源，就可能存在发生死锁的情况。 当用户A以独占模式持有资源Y，用户B以独占模式持有资源Z，并且两个用户都在申请对方持有的资源并且都不愿意放弃对所持资源的独占锁，简单的死锁就发生了。 每当请求转换锁并且锁无法在短时间内完成授权时，锁管理器都会执行死锁检测。

![aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X3BuZy85UmpScnZPNjN6ZElxU2FzN2p6OVlNN2UzY1BncGx4eEhQa1ZHMkNhc1RUaFp6VG9qZ25lTk85Mm4zWWNQU2QxMDdETzNHSFRhMmljd0hWemRXa1JxVXcvNjQwP3d4X2ZtdD1wbmcmdHA9d2VicCZ3eGZyb209NSZ3eF9sYXp5PTEmd3hfY289MQ][]

**Timeout-Based死锁检测**

如果发生锁转换，则每个可能会变成死锁的锁都会挂在死锁计时队列中。

当转换超时后，死锁检测开始。

超时由\_lm\_dd\_interval参数决定（11g 12c为10s）。

LMD每次只进行一个锁的检测动作。

生成死锁跟踪trc和排队信息。

dd\_ts\_server【ddTS】资源(DI,0,0)必须保持在EX模式下才能执行死锁搜索。

死锁检测搜索尝试查找等待环。 它通过阻塞进程和正在等待的锁构建转换锁的图。 在RAC环境下，这个等待环可能跨越多个节点。 如果找到循环，则解决方案是将错误返回到等待环中的其中一个进程。 如果死锁环只发生在本地节点，则死锁环中的最后一个进程是获取错误的进程。 如果死锁环跨越节点，则启动搜索的进程会收到错误。 启动死锁检测的超时是current\_time +（60 + number\_of\_nodes / 2）秒。

![20190816093515926.gif][]![aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X3BuZy85UmpScnZPNjN6ZElxU2FzN2p6OVlNN2UzY1BncGx4eFNjZzZzTmVPd0tRYXV5bWlid1VEVEF3T05pYWM4U1VVZWwwMng0OFhzSHVJdGlidFRBU2ljeGVsZncvNjQwP3d4X2ZtdD1wbmcmdHA9d2VicCZ3eGZyb209NSZ3eF9sYXp5PTEmd3hfY289MQ][]

当数据库启动后，每个实例的LMD0进程都会以NULL模式锁定资源(DI,0,0)。 每个实例依次通过将此锁从NULL转换为X模式来执行死锁检测。 每个死锁检测都受到时间限制（number\_of\_nodes\_in\_cluster / 2）min。 如果在此期间未找到死锁，则中止死锁检测以避免花费太多时间跟踪死锁构造死锁信息。 需要注意的是死锁检测也是分布式的。

当锁被移动到资源的转换队列时，此锁会被加到死锁队列的末尾并且这个锁将成为死锁检测的候选者。

死锁检测涉及以下三个步骤：

1.Deadlock search： 构建等待图表（WFG）。 如果死锁是跨多节点的，则多节点均会参与等待图的构建。

2.Deadlock Validation： 如果发现死锁，则涉及死锁的节点都会搜证各自子等待图中的每个锁。

3.Wait-for graph printing： 如果上一步成功，则整个WFG会被打印输出。

**锁死处理流**

当入队锁进入转换队列并且它可能成为死锁（TM，TX或UL）时，锁信息也会被置于死锁队列中。 然后开始计算死锁检测的时间，LMD0每五秒检查一次死锁队列，如果死锁队列不为空，并且死锁队列头部的锁在队列中的时间超过time\_to\_dd，则启动死锁搜索。 否则，LMD0将死锁队列头部的锁定移动到尾部并返回到正常活动。

如果在节点1上开始死锁检测，则LMD0将其对DI，0,0的锁定从NULL转换为EXCLUSIVE; 在整个集群中，只允许一个节点启动DD。

![aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X3BuZy85UmpScnZPNjN6ZElxU2FzN2p6OVlNN2UzY1BncGx4eE9yaWNYM1RraDhCSFdRcWcxTUZOeXcxbVJpY2dONm5NODR6Q2ZUQmpheUlhQVN4elZjQzllNTFRLzY0MD93eF9mbXQ9cG5nJnRwPXdlYnAmd3hmcm9tPTUmd3hfbGF6eT0xJnd4X2NvPTE][]

**死锁流： 单节点**

当锁死检测在本地节点找到死锁时，或者未找到死锁或找到远程实例死锁发生在远程节点，WFG生成结束。

死锁图说明：

•（R1）具有锁L1的资源，该资源由X1拥有并处于R1的转换队列中。

•（X11，X12，X13）表示Grant队列上锁的所有者的XID或者与L1锁有冲突的处于R1的转换队列上的锁所有者。

•（R132）资源是X13的一个锁并且挂在转换队列中。

•（X1）X1是Grant队列上的锁的所有者或者与转换队列上的锁R132有冲突的锁所有者

•（黄色三角形）此处发现死锁。

![aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X3BuZy85UmpScnZPNjN6ZElxU2FzN2p6OVlNN2UzY1BncGx4eFlOemljcUxaaWI2cG5lWkNzSWVRbUxUVFB4WFVXVnpuaWNNS0MwYnBkaWI1bHhsR3ZvNE1VZU5KZ0EvNjQwP3d4X2ZtdD1wbmcmdHA9d2VicCZ3eGZyb209NSZ3eF9sYXp5PTEmd3hfY289MQ][]

**死锁流： 两个节点**

在发现远程资源之后并且在LMD0结束其循环消息处理，在节点1上构建的WFG结束。

死锁图：

•虚线资源是其他节点拥有的队列的影子队列。

•在节点1处，执行前面介绍到的WFG构造流程，直到它检查锁R132的持有者并发现X1在另一个节点上。

•节点1死锁检测将消息KJX\_DEADLOCK\_IND发送到节点2以继续死锁检测。

•节点2构建相同的WFG。

•X1是Grant队列上锁的所有者或转换队列上的锁R132有冲突的锁所有者。

•发现死锁。

其他情况：

节点2检测得出没有死锁的结论： 如果示例中X1没有持有与其他用户相冲突的锁，在这种情况下，它向节点1发送BACKTRACK消息，要求进一步搜索或没有死锁得出结论。

节点2可能会发现有资源存在于其他实例（如节点3）上，在这种情况下，它会发送KJX\_DEADLOCK\_IND消息以进行进一步的远程处理。

![aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X3BuZy85UmpScnZPNjN6ZElxU2FzN2p6OVlNN2UzY1BncGx4eFM3eUNEb290c2oxMGR5RHM3SzBiQzlOMUtpY3hLdnRkVnM5UmxpYkJ6b2cwdWRDRUh1cjhzUGJnLzY0MD93eF9mbXQ9cG5nJnRwPXdlYnAmd3hmcm9tPTUmd3hfbGF6eT0xJnd4X2NvPTE][]

**并行DML死锁**

由事务标识符（XID）标识的锁可能无法检测具有相同XID的PDML操作的死锁。 当申请锁并发现其涉及PDML时，API会通知IDLM（执行全局DD---kjd）。 PDML事务的协调器使用CGS名称服务发布跨区集（spanning set），Oracle使用CGS名称服务来创建生成集标识（spanning set）。 事务的跨区域集（spanning set）是发生此事务的节点进程列表。 name =TX的<XID>  ， value = <spanning set>.

[aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X3BuZy85UmpScnZPNjN6ZElxU2FzN2p6OVlNN2UzY1BncGx4eHZLaFBwWkw0d2NmTWZFQWNTdzBxNUY1WldLcFcycTNoTUpOd1ZyZ1NQSmw5eWtuaWJ6Q2FoaWFnLzY0MD93eF9mbXQ9cG5nJnRwPXdlYnAmd3hmcm9tPTUmd3hfbGF6eT0xJnd4X2NvPTE]: /images/20211019/f6839078f3ad4422a0c179877c82ce20.png
[aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X3BuZy85UmpScnZPNjN6ZElxU2FzN2p6OVlNN2UzY1BncGx4eEhQa1ZHMkNhc1RUaFp6VG9qZ25lTk85Mm4zWWNQU2QxMDdETzNHSFRhMmljd0hWemRXa1JxVXcvNjQwP3d4X2ZtdD1wbmcmdHA9d2VicCZ3eGZyb209NSZ3eF9sYXp5PTEmd3hfY289MQ]: /images/20211019/fc8e07b419714d098adecb0bc27c0df7.png
[20190816093515926.gif]: https://img-blog.csdnimg.cn/20190816093515926.gif
[aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X3BuZy85UmpScnZPNjN6ZElxU2FzN2p6OVlNN2UzY1BncGx4eFNjZzZzTmVPd0tRYXV5bWlid1VEVEF3T05pYWM4U1VVZWwwMng0OFhzSHVJdGlidFRBU2ljeGVsZncvNjQwP3d4X2ZtdD1wbmcmdHA9d2VicCZ3eGZyb209NSZ3eF9sYXp5PTEmd3hfY289MQ]: /images/20211019/3fc40dbc301c44689bf2a3c4b7a8207a.png
[aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X3BuZy85UmpScnZPNjN6ZElxU2FzN2p6OVlNN2UzY1BncGx4eE9yaWNYM1RraDhCSFdRcWcxTUZOeXcxbVJpY2dONm5NODR6Q2ZUQmpheUlhQVN4elZjQzllNTFRLzY0MD93eF9mbXQ9cG5nJnRwPXdlYnAmd3hmcm9tPTUmd3hfbGF6eT0xJnd4X2NvPTE]: /images/20211019/5457835ca1114fc6814f4768423427f5.png
[aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X3BuZy85UmpScnZPNjN6ZElxU2FzN2p6OVlNN2UzY1BncGx4eFlOemljcUxaaWI2cG5lWkNzSWVRbUxUVFB4WFVXVnpuaWNNS0MwYnBkaWI1bHhsR3ZvNE1VZU5KZ0EvNjQwP3d4X2ZtdD1wbmcmdHA9d2VicCZ3eGZyb209NSZ3eF9sYXp5PTEmd3hfY289MQ]: /images/20211019/854cea36b1ab4a148c8770d4ca454d1f.png
[aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X3BuZy85UmpScnZPNjN6ZElxU2FzN2p6OVlNN2UzY1BncGx4eFM3eUNEb290c2oxMGR5RHM3SzBiQzlOMUtpY3hLdnRkVnM5UmxpYkJ6b2cwdWRDRUh1cjhzUGJnLzY0MD93eF9mbXQ9cG5nJnRwPXdlYnAmd3hmcm9tPTUmd3hfbGF6eT0xJnd4X2NvPTE]: /images/20211019/07293b060bc34d81a5a365a47ee311b0.png