RAC 锁管理与锁问题的定位（一）(有图有真相）

2020-06-22 00:00:00 节点队列结构资源持有者

RAC 锁管理与锁问题的定位（一）

(第二篇，实践篇已经整理出来：http://www.itpub.net/thread-1596447-1-1.html）

从我一到公司，主要工作就是维护我们的一套大RAC。主库5个节点，备库多时曾有4个节点，后来备库减至单实例了。主、备一共8套存储，总间共300T空间。内部互联采用业内快的InifiniBand。也算是豪华配置了。高峰时，主库数据130T左右，每天归档量时接近6T，是我见过的大、忙的数据库。

库一大，很多本来不是问题的问题，就会变成问题。比如数据字典维护，Oracle在这一块上做的很好，因为这是Oracle的根本。这一块上罕有问题的。但是，当数据库中有几百万个段时呢！其实就算有几百万个段，Oracle也运行的好好的，在极偶然的情况下，会遇到问题。还有控制文件，通常也就几十M，但当它接近1G呢，它就会像一个活火山一样，偶而爆发。另外，还有更容易想到的，如备份的问题，搭建备库的问题等等。如果一个库只有1T，搭建个备库只需要几个小时，但是上百T呢！不但是时间问题，选择合适的方法是另一个需要考虑的问题。

平时工作太忙，现在有时间了，慢慢和大家分享，总比烂在我的肚子里强。

开始今天的正题，聊一聊RAC中的锁管理。

大家一般对RAC中的CacheFusion比较熟悉，而对锁管理，讨论的不多。其实，锁管理更为基础，因为块，或者更准确点，Buffer cache中的Buffer，也是锁管理的对象之一。好，下面我们开始。

一、首先，了解一下RAC中要管理的锁的类型：

（一）、你在V$LOCK中看到的全部锁，这一部分我们可以称之为队列锁。

（二）、Library cache lock/pin，还有Row cache lock，这一部分我们称之为内存锁。（内存锁还有一个，就是Buffer pin，它导致的竞争，就是我上遍文章中所讲的buffer busy waits。注意啊，想降低buffer busy waits吗，哪就使用更快速的设备存放Redo File吧。详在www.mythdata.com中的遍日志，或在上个帖子中参加讨论：http://www.itpub.net/thread-1583811-1-3.html）

（三）、还有，就是针对Buffer cache中的块的锁了，Oracle为它定义的类型为BL。

上面这些，就是RAC锁的全部了。也就是说，RAC的数据库在运行期间，只有这些东西，需要在节点间同步。

下面提个问题，猜猜看哪种锁数量多？

你一定会说针对Buffer的BL锁，但不是。大多数情况下，是Row cache lock的数量多（这里不讨论情况）。

但是Row cachelock通常是静止的，很少修改。数据字典，元数据吗，改动当然不多。而Buffer的BL锁就不一样的，修改频繁。因此，Oracle在普通的锁管理机制之外，针对BL又搞了个Cache Fusion。好，这里就不讨论它了，以后我会再详细讨论Cache Fusion的。

二、资源池与主节点

和单实例中的队列锁一样，RAC中的锁，也分为两部分：资源结构和锁结构。

在共享池中，还有一个资源结构池，审请锁的部，就是到这个池中审请一个Free的资源结构。

可以把资源池想像一块内存，其时，它就是一大块内存，在实例启动时分配。如下图：

在资源池中，内存又被分成一个个小块，每个小块，就是上图中的一行，Oracle称为一个Slot。每个Slot，就叫做一个资源结构（Resource struct）。每个资源结构中的主要信息如下：

资源名（RESOURCE_NAME）转换者队列地址（ON_CONVERT_Q）持有者队列地址（ON_GRANT_Q）主节点（MASTER_NODE）可以进一步把资源池想像成如下的表格：

我们把其中重要的东西解释一下。

1、资源名：和单实例中的队列锁一样。资源名由资源类型加两个参数构成。比如TM锁的资源名，一般写为TM-ID1-ID2，TM是资源类型（也就是锁类型）。参数ID1是DBA_OBJECTS中的对象编号，ID2为0。假设有个表，对象编号是195，它的TM资源（或称为TM锁）的资源名为：TM-195-0。这点对于单实例、多实例来说，是一样的。再来找个不一样的，比如一个Buffer。资源类型是BL，两个参数ID1、ID2分别是从块地址计算出来的（计算规则我会在Cache Fusion中详细描述）。这个BL-ID1-ID2锁，在单实例中，不会出现。 2、转换者队列和持有者队列：这分别是两个链表，记录有多个进程持有锁，或正在等待锁。RAC认为每个实例中的每个进程都可以获得空锁，所以，如果进程想获得独占锁，但没有成功，那么它是要从空锁转换成独占锁而没有成功。所以这里没有等待者队列，只有转换者队列。我们可又把转换者队列，理解为等待者队列，记录所有正在等待进程信息。 3、主节点：这个信息，是单实例中资源结构所没有的。RAC中，每个锁都有一个主节点。或者，准确点说，每个资源结构都有一个主节点。主节点的计算方式，是用资源名作HASH。这里的HASH算法，可以理解为根据资源名的一串字符，求得一个数字，再用这个数字除以节点数，取余数。比如有个这样的资源名，TM-1234-0，求得的HASH值为3，它的主节点就是3。某个节点的进程，如果想对某个资源加锁，步就是根据资源名计算出HASH值，根据HASH值找到资源的主节点。注意：锁，或者队列锁，也叫资源。它包含两部分信息，资源结构和锁结构。资源结构有主节点，锁结构没有主节点。千万不要被资源结构、锁结构这样的名称所误导。这两个东西，就是锁的两部分信息。三、资源结构的查找各节点的进程想要加锁，步就是定位资源结构。如何定位，HASH算法。Oracle内部，只要涉及在内存中查找东西，比如要Buffer Cache中找某个Buffer，在共享池中找某条SQL，等等，全部用的是HASH。资源结构的查找定位也不例外。

比如，有个表叫MythData，节点1的进程程想在MythData表上加锁，此表的对象编号为1234，那么资源名为TM-1234-0，根据此资源名，计算HASH值，得到主节点为2号节点。节点1向节点2发送加锁请求。接到加锁请求，节点2根据TM-1234-0这个资源名，再次计算HASH值，这次不再是为了求主节点了，是为了在自己的内存中定位此资源的资源结构。

如下图：接下来，节点2在自已的内存中定位资源TM-1234-0：

四、锁结构

如果节点1可以持有TM-1234-0，接下来Oracle会如何处理呢？在资源结构上加锁结构。

我们再一次强调，千万不要被资源结构、锁结构这样的名称所误导。这两个东西，就是锁的两部分信息。

同样的，共享池中也有一个锁池，如下图：

再进一步的，锁池内存也被分为一个个的小块，每一块称为一个Slot，就是图中的一行。每一行我们就称之为一个锁结构。锁结构中的信息比较多，有资源名、加锁的节点、加锁的进程、锁结构所在队列、状态等信息。下面把重要的说一下：加锁的节点：锁结构没有主节点，锁结构只会隶属于某个资源结构。而资源结构是有主节的。锁结构所在队列：如果请求进程可以加锁，锁结构会被加入资源结构的持有者队列。否则，如果有其他人以不兼容的方式持有锁，请求进程将被挂在资源结构的转换者队列，也就是说，请求被阻塞了。也就是说，锁池的形式如下：

好，下面我们来详细说一下完整的锁的获取过程。接着上面第10点。

五、完整的锁的获取过程上面第10步，已经说到，主节点2中，TM-1234-0的资源结构显示，无人持有此资源，持有者队列为空。转换者队列也为空。哪么节点1可以持有此资源。接下来再看下面这些图：

注意，下面的图，和上面的图的区别，多了个箭头。

第15步的目的，就是建立资源结构和锁结构的联系。更通俗点说，就是将锁结构挂到对应资源结构的持有者队列中。至此，节点1的操作完毕。主节点（节点2）也会有类似操作。主节点上的操作不再详述，大至如下：（1）、如果TM-1234-0在节点2上还没有资源结构，节点2会在自已的共享池中的资源池中审请一个Slot，并填入信息（2）节点2在共享池的锁池中审请一个锁结构，并填入信息。（3）、将锁结构挂在资源结构的持有队列中。具体如下：

也就是说，主节点和审请节点，都会有锁的相关信息。再次强调，“锁的相关信息”指的就资源结构和锁结构。

六、实际操作理论先说这么多吧，下面来点实验。我们的终目的，是要从理论中学习如果RAC出现了锁问题，如何定位。我们研究理论，也要和实践挂钩，要不然，理论就成了虚无飘渺的东西。但是，有时研究内部、研究理论，不是马上就能有成果，往往需要潜心研究一段时间才可。总之，我的观点，研究内部，一定不能满足于听一听、或看一看别人的成果，这样的研究，毫无意义。一定要自己动手，反复测试、验证别人的理论，这样才会进步。好，闲言少叙，开始。

1、测试环境

两节点RAC，有表T3，对象号为12566，16进制为3136。我分别在两个节点进行如下操作：节点2，会话1： insert into t3 values(1,'a'); 插入为DML，在T3对象上要加TM锁。也就是要在资源名为TM-3136-0的资源上，加共享型的锁。节点2，会话2：insert into t3 values(2,'b'); 也在TM-3136-0上加共享型的锁。节点1，会话1：insert into t3 values(3,'c'); 同上。

节点1： lock table t3 in exclusive mode ;

在TM-3136-0上，加独占锁。

每做完一步，用视图观察资源结构和锁结构。

步1：在节点2执行： SQL> insert into t3 values(1,'a'); 1 row created. 步2：查看锁情况：（1）、在节点2查看资源结构： SQL> select RESOURCE_NAME, ON_CONVERT_Q,ON_GRANT_Q, MASTER_NODE from V$DLM_RESS where resource_name like '[0x3116%TM%'; RESOURCE_NAME ON_CONVERT_Q ON_GRANT_QMASTER_NODE ------------------------------ ---------------------- ----------- [0x3116][0x0],[TM] 0 1 0

RESOURCE_NAME：资源名，就是TM-3116-0。

ON_CONVERT_Q：转换者队列中锁结构的数量。现在为0，也就是没有人补阻塞。 ON_GRANT_Q：持有者队列中锁结构的数量。现在为1，有进程的锁结构在持有者队列中。 MASTER_NODE：资源的主节点。此处为0，即主节点为0，也就是节点1。

（2）、在节点1查看资源结构：

SQL> select RESOURCE_NAME, ON_CONVERT_Q,ON_GRANT_Q, MASTER_NODE from V$DLM_RESS where resource_name like '[0x3116%TM%'; RESOURCE_NAME ON_CONVERT_Q ON_GRANT_QMASTER_NODE ------------------------------ ---------------------- ----------- [0x3116][0x0],[TM] 0 1 0

和在节点2查看一样。

（3）、在节点2查看锁结构： SQL> set linesize 1000 SQL> col STATE for a15 SQL> select GRANT_LEVEL, REQUEST_LEVEL,PID, OWNER_NODE,WHICH_QUEUE,STATE,BLOCKED,BLOCKER from V$GES_ENQUEUE whereRESOURCE_NAME1 like '[0x3116%TM%';

GRANT_LEV REQUEST_L PID OWNER_NODE WHICH_QUEUE STATE BLOCKED BLOCKER

-------- --------- ---------- --------------------- --------------- ---------- ---------- KJUSERCW KJUSERCW 29079 1 1 GRANTED 0 0

GRANT_LEVEL：锁的类型，我只记得后两个字母的意义，CW是共享，EX为独占，NL为空锁。

REQUEST_LEVEL：请求的锁的类型。 PID：进程号。 OWNER_NODE：审请并持有锁的节点。此处为1，即节点2. WHICH_QUEUE：锁结构被挂在资源结构的哪队列中。此处是1，即持有者队列。为0则为转换者队列，共表正在等待。 STATE：状态。 BLOCKED：是否被阻塞。 BLOCKER：是否阻塞别人。根据这些列的信息，我们可以知道，29079号进程，在节点2上审请TM-3116-0资源。请求的模式为共享，得到的模式也为共享，没有被阻塞。（4）、在节点1观察锁结构： SQL> set linesize 1000 SQL> col STATE for a15 SQL> select GRANT_LEVEL, REQUEST_LEVEL,PID, OWNER_NODE,WHICH_QUEUE,STATE,BLOCKED,BLOCKER from V$GES_ENQUEUE whereRESOURCE_NAME1 like '[0x3116%TM%'; GRANT_LEV REQUEST_L PID OWNER_NODE WHICH_QUEUE STATE BLOCKED BLOCKER --------- --------- ---------- --------------------- --------------- ---------- ---------- KJUSERCW KJUSERCW 0 1 1 GRANTED 0 0 显示结构同在节点2中看到的基本一样。有一列不同，就是PID列，此处为0。步3：再在节点2执行一条DML语句：另外在节点2上打开个一会话，执行： SQL> insert into t3 values(2,'b');

1 row created.

步4：查看锁情况（1）、在节点2查看资源结构与锁结构： SQL> select RESOURCE_NAME, ON_CONVERT_Q,ON_GRANT_Q, MASTER_NODE from V$DLM_RESS where resource_name like '[0x3116%TM%';

RESOURCE_NAME ON_CONVERT_Q ON_GRANT_QMASTER_NODE

------------------------------ ---------------------- ----------- [0x3116][0x0],[TM] 0 1 0

ON_GRANT_Q仍然为1，但其实TM-3116-0资源的持有者队列中，已经有两个共享锁结构了。这说明ON_GRANT_Q只是说明有锁结构在持有者队列中，至于有多少锁，此列并不显示。

SQL> select GRANT_LEVEL, REQUEST_LEVEL,PID, OWNER_NODE,WHICH_QUEUE,STATE,BLOCKED,BLOCKER from V$GES_ENQUEUE whereRESOURCE_NAME1 like '[0x3116%TM%'; GRANT_LEV REQUEST_L PID OWNER_NODE WHICH_QUEUE STATE BLOCKED BLOCKER --------- --------- ---------- --------------------- --------------- ---------- ---------- KJUSERCW KJUSERCW 12870 1 1 GRANTED 0 0 KJUSERCW KJUSERCW 29079 1 1 GRANTED 0 0 锁结构又多了一个，PID为12870。（2）、在节点1上显示资源结构与锁结构 SQL> select RESOURCE_NAME, ON_CONVERT_Q,ON_GRANT_Q, MASTER_NODE from V$DLM_RESS where resource_name like '[0x3116%TM%'; RESOURCE_NAME ON_CONVERT_Q ON_GRANT_QMASTER_NODE ------------------------------ ---------------------- ----------- [0x3116][0x0],[TM] 0 1 0 资源结构的显示结果，与在节点2上显示的一样。 SQL> select GRANT_LEVEL, REQUEST_LEVEL,PID, OWNER_NODE,WHICH_QUEUE,STATE,BLOCKED,BLOCKER from V$GES_ENQUEUE whereRESOURCE_NAME1 like '[0x3116%TM%'; GRANT_LEV REQUEST_L PID OWNER_NODE WHICH_QUEUE STATE BLOCKED BLOCKER --------- --------- ---------- --------------------- --------------- ---------- ---------- KJUSERCW KJUSERCW 0 1 1 GRANTED 0 0 锁结构的显示结果就不一样了。在节点2（1号节点）上，已经有两个锁了（也就是有两个锁结构），但在主节点上，只显示一行。这是Oracle为了节省内存做的优化。主节点没有必要知道其他节点持有的全部锁，只需要知道某个节点持有的别的锁即可。现在，1号节点也就是节点2，持有的别的锁是共享锁。步5：在节点1上执行DML： SQL> insert into t3 values(3,'c'); 1 row created. 步6：查看信息（1）、资源结构中的信息，在两个节点中都没有变化。（2）、锁结构的信息，节点2没有变化。因为节点2不是主节点，并且新的操作也不是在节点2上产生的。所以节点2上的锁结构完全没有变化。（3）、节点1的锁结构信息： SQL> select GRANT_LEVEL, REQUEST_LEVEL,PID, OWNER_NODE,WHICH_QUEUE,STATE,BLOCKED,BLOCKER from V$GES_ENQUEUE whereRESOURCE_NAME1 like '[0x3116%TM%'; GRANT_LEV REQUEST_L PID OWNER_NODE WHICH_QUEUE STATE BLOCKED BLOCKER --------- --------- ---------- --------------------- --------------- ---------- ---------- KJUSERCW KJUSERCW 30873 0 1 GRANTED 0 0 KJUSERCW KJUSERCW 0 1 1 GRANTED 0 0 多了一个PID为30873的锁。OWNER_NODE节点为0，0号结构也就是节点1。步7：在节点1产生一个独占锁请求： SQL> lock table t3 in exclusive mode ; 步8：观察锁信息（1）、节点2上资源结构和锁结构没有变化。（2）、节点1上资源结构： SQL> select RESOURCE_NAME, ON_CONVERT_Q,ON_GRANT_Q, MASTER_NODE from V$DLM_RESS where resource_name like '[0x3116%TM%'; RESOURCE_NAME ON_CONVERT_Q ON_GRANT_Q MASTER_NODE ------------------------------ ---------------------- ----------- [0x3116][0x0],[TM] 1 1 0 ON_CONVERT_Q列变为了1。证明有进程被阻塞、放进了转换者队列。（3）、节点1上锁结构： SQL> select GRANT_LEVEL, REQUEST_LEVEL,PID, OWNER_NODE,WHICH_QUEUE,STATE,BLOCKED,BLOCKER from V$GES_ENQUEUE whereRESOURCE_NAME1 like '[0x3116%TM%'; GRANT_LEV REQUEST_L PID OWNER_NODE WHICH_QUEUE STATE BLOCKED BLOCKER --------- --------- ---------- --------------------- --------------- ---------- ---------- KJUSERCW KJUSERCW 30873 0 1 GRANTED 0 1 KJUSERCW KJUSERCW 0 1 1 GRANTED 0 0 KJUSERNL KJUSEREX 10897 0 2 OPENING 1 0 第三行，PID为10897的，BLOCKED为1，代表，代表被别人阻塞了。REQUEST_LEVEL中，请求的锁类型为EX，也就是独占。GRANT_LEVEL列中，获得的锁类型为NL，也就是空锁。注意，行BLOCKER为1，Oracle想表达此行阻塞了其他事务，其实，还有第二行对应的节点2中的事务，也阻塞了其他事务。

步9：在节点2中，提交一个DML：

SQL> commit; Commit complete. 步10：观察信息（1）、节点1和节点2中的资源结构都没有变化。（2）、节点2中的锁结构：

SQL> select GRANT_LEVEL, REQUEST_LEVEL,PID, OWNER_NODE,WHICH_QUEUE,STATE,BLOCKED,BLOCKER from V$GES_ENQUEUE whereRESOURCE_NAME1 like '[0x3116%TM%';

GRANT_LEV REQUEST_L PID OWNER_NODE WHICH_QUEUE STATE BLOCKED BLOCKER --------- --------- ---------- --------------------- --------------- ---------- ---------- KJUSERCW KJUSERCW 29079 1 1 GRANTED 0 1 少了一行，因为一个事务已经提交。其他没啥变化。（3）、节点1中的锁结构： SQL> select GRANT_LEVEL, REQUEST_LEVEL,PID, OWNER_NODE,WHICH_QUEUE,STATE,BLOCKED,BLOCKER from V$GES_ENQUEUE whereRESOURCE_NAME1 like '[0x3116%TM%'; GRANT_LEV REQUEST_L PID OWNER_NODE WHICH_QUEUE STATE BLOCKED BLOCKER --------- --------- ---------- --------------------- --------------- ---------- ---------- KJUSERCW KJUSERCW 30873 0 1 GRANTED 0 1 KJUSERCW KJUSERCW 0 1 1 GRANTED 0 0 KJUSERNL KJUSEREX 10897 0 2 OPENING 1 0 没有变化，虽然有一个事务提交了。原因是什么，你可以自己考虑一下，很简单的哦。步11：将节点1中的DML事务提交： SQL> commit; Commit complete. 步12：观察信息：（1）、节点1和节点2中的资源结构都没有变化。（2）、节点2的资源结构无变化。因为提交的事务在主节点，和节点2没有关系。 SQL> select GRANT_LEVEL, REQUEST_LEVEL,PID, OWNER_NODE,WHICH_QUEUE,STATE,BLOCKED,BLOCKER from V$GES_ENQUEUE whereRESOURCE_NAME1 like '[0x3116%TM%'; GRANT_LEV REQUEST_L PID OWNER_NODE WHICH_QUEUE STATE BLOCKED BLOCKER --------- --------- ---------- --------------------- --------------- ---------- ---------- KJUSERCW KJUSERCW 0 1 1 GRANTED 0 0 KJUSERNL KJUSEREX 10897 0 2 OPENING 1 0 主节点上的事务提交了一个，BLOCKER为1的行已经不在了，但10897还在被阻塞，因为另一个节点上仍有事务。步13：提交节点2上后一个DML： SQL> commit; Commit complete. 步14：观察信息：（1）、节点2上资源结构变化如下： SQL> select RESOURCE_NAME, ON_CONVERT_Q,ON_GRANT_Q, MASTER_NODE from V$DLM_RESS where resource_name like '[0x3116%TM%'; RESOURCE_NAME ON_CONVERT_Q ON_GRANT_QMASTER_NODE ------------------------------ ---------------------- ----------- [0x3116][0x0],[TM] 0 0 0 也没有太大的变化，就是ON_GRANT_Q变为0。代表持有者队列已经空了。（2）、节点2上锁结构视图为空。因为锁提交了。（3）、节点1上资源结构： SQL> select RESOURCE_NAME, ON_CONVERT_Q,ON_GRANT_Q, MASTER_NODE from V$DLM_RESS where resource_name like '[0x3116%TM%'; RESOURCE_NAME ON_CONVERT_Q ON_GRANT_QMASTER_NODE ------------------------------ ---------------------- ----------- [0x3116][0x0],[TM] 0 1 0 ON_CONVERT_Q列变为0，ON_GRANT_Q变为1。也就是说，刚才在等待的进程，已经从转换者队列，变到了持有者队列。（4）、节点1锁结构： GRANT_LEV REQUEST_L PID OWNER_NODE WHICH_QUEUE S BLOCKED BLOCKER --------- --------- ---------- --------------------- --------------- ---------- ---------- KJUSEREX KJUSEREX 10897 0 1 GRANTED 0 0 KJUSERNL KJUSERNL 0 1 1 GRANTED 0 0 第二行显示，节点2上的锁，现在已经变成空锁。行显示，10897进程，请求独占锁，已持有独占锁。

相关文章