本帖最后由 vage 于 2012-5-23 18: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的资源结构。 可以把资源池想像一块内存，其时，它就是一大块内存，在实例启动时分配。如下图：
pic1.jpg (30.95 KB, 下载次数: 172)
下载附件
2012-3-7 22:38 上传
在资源池中，内存又被分成一个个小块，每个小块，就是上图中的一行，Oracle称为一个Slot。每个Slot，就叫做一个资源结构（Resource struct）。每个资源结构中的主要信息如下：资源名（RESOURCE_NAME）
转换者队列地址（ON_CONVERT_Q）
持有者队列地址（ON_GRANT_Q）
主节点（MASTER_NODE）
可以进一步把资源池想像成如下的表格：
pic2.jpg (34.14 KB, 下载次数: 172)
下载附件
2012-3-7 22:41 上传
我们把其中重要的东西解释一下。 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值，这次不再是为了求主节点了，是为了在自己的内存中定位此资源的资源结构。 如下图：
pic3.jpg (39.04 KB, 下载次数: 165)
下载附件
2012-3-7 22:44 上传
接下来，节点2在自已的内存中定位资源TM-1234-0：
pic4.jpg (58.39 KB, 下载次数: 162)
下载附件
2012-3-7 22:44 上传
四、锁结构 如果节点1可以持有TM-1234-0，接下来Oracle会如何处理呢？在资源结构上加锁结构。 我们再一次强调，千万不要被资源结构、锁结构这样的名称所误导。这两个东西，就是锁的两部分信息。 同样的，共享池中也有一个锁池，如下图：
pic5.jpg (45.72 KB, 下载次数: 157)
下载附件
2012-3-7 22:47 上传
再进一步的，锁池内存也被分为一个个的小块，每一块称为一个Slot，就是图中的一行。每一行我们就称之为一个锁结构。
锁结构中的信息比较多，有资源名、加锁的节点、加锁的进程、锁结构所在队列、状态等信息。下面把重要的说一下：
加锁的节点：锁结构没有主节点，锁结构只会隶属于某个资源结构。而资源结构是有主节的。
锁结构所在队列：如果请求进程可以加锁，锁结构会被加入资源结构的持有者队列。否则，如果有其他人以不兼容的方式持有锁，请求进程将被挂在资源结构的转换者队列，也就是说，请求被阻塞了。
也就是说，锁池的形式如下：
pic6.jpg (42.46 KB, 下载次数: 161)
下载附件
2012-3-7 22:47 上传
好，下面我们来详细说一下完整的锁的获取过程。接着上面第10点。
五、完整的锁的获取过程
上面第10步，已经说到，主节点2中，TM-1234-0的资源结构显示，无人持有此资源，持有者队列为空。转换者队列也为空。哪么节点1可以持有此资源。
接下来再看下面这些图：
pic7.jpg (50.76 KB, 下载次数: 171)
下载附件
2012-3-7 22:53 上传
pic8.jpg (52.93 KB, 下载次数: 162)
下载附件
2012-3-7 22:53 上传
pic9.jpg (57.97 KB, 下载次数: 161)
下载附件
2012-3-7 22:53 上传
注意，下面的图，和上面的图的区别，多了个箭头。
pic10.jpg (56.25 KB, 下载次数: 170)
下载附件
2012-3-7 22:55 上传
第15步的目的，就是建立资源结构和锁结构的联系。更通俗点说，就是将锁结构挂到对应资源结构的持有者队列中。
至此，节点1的操作完毕。主节点（节点2）也会有类似操作。主节点上的操作不再详述，大至如下：
（1）、如果TM-1234-0在节点2上还没有资源结构，节点2会在自已的共享池中的资源池中审请一个Slot，并填入信息
（2）节点2在共享池的锁池中审请一个锁结构，并填入信息。
（3）、将锁结构挂在资源结构的持有队列中。
具体如下：
pic11.jpg (59.27 KB, 下载次数: 165)
下载附件
2012-3-7 22:55 上传
也就是说，主节点和审请节点，都会有锁的相关信息。再次强调，“锁的相关信息”指的就资源结构和锁结构。
六、实际操作
理论先说这么多吧，下面来点实验。我们的最终目的，是要从理论中学习如果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 t3in 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_LPID OWNER_NODE WHICH_QUEUE STATEBLOCKED BLOCKER-------- --------- ---------- --------------------- --------------- ---------- ----------
KJUSERCW KJUSERCW 2907911 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_LPID OWNER_NODE WHICH_QUEUE STATE BLOCKED BLOCKER
--------- --------- ---------- --------------------- --------------- ---------- ----------
KJUSERCW KJUSERCW 011 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_LPID OWNER_NODE WHICH_QUEUE STATEBLOCKED BLOCKER
--------- --------- ---------- --------------------- --------------- ---------- ----------
KJUSERCW KJUSERCW12870
1 1 GRANTED 0
0
KJUSERCW KJUSERCW29079
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_LPID OWNER_NODE WHICH_QUEUE STATE BLOCKED BLOCKER
--------- --------- ---------- --------------------- --------------- ---------- ----------
KJUSERCW KJUSERCW 0
11 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_LPID OWNER_NODE WHICH_QUEUE STATE BLOCKED BLOCKER
--------- --------- ---------- --------------------- --------------- ---------- ----------
KJUSERCW KJUSERCW 30873 0 1 GRANTED
0
0
KJUSERCW KJUSERCW0
1 1 GRANTED
0
0
多了一个PID为30873的锁。OWNER_NODE节点为0，0号结构也就是节点1。
步7：在节点1产生一个独占锁请求：
SQL> lock tablet3 in exclusivemode ;
步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 GRANTED0
1
KJUSERCW KJUSERCW0 1 1 GRANTED 0 0
KJUSERNL KJUSEREX10897
0 2 OPENING1 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_LPID OWNER_NODE WHICH_QUEUE STATEBLOCKED 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_LPID OWNER_NODE WHICH_QUEUE STATEBLOCKED BLOCKER
--------- --------- ---------- --------------------- --------------- ---------- ----------
KJUSERCW KJUSERCW 30873
0 1 GRANTED 0
1
KJUSERCW KJUSERCW0
1 1 GRANTED0
0
KJUSERNL KJUSEREX10897
0 2 OPENING1 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 KJUSEREX10897 0 2 OPENING1 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 SBLOCKED BLOCKER
--------- --------- ---------- --------------------- --------------- ---------- ----------
KJUSEREX KJUSEREX10897 0 1 GRANTED 0
0
KJUSERNL KJUSERNL0 1 1 GRANTED 0
0
第二行显示，节点2上的锁，现在已经变成空锁。
第一行显示，10897进程，请求独占锁，已持有独占锁。
|
