ITPub博客

首页 > Linux操作系统 > Linux操作系统 > RAC 锁管理与锁问题的定位(一)(有图有真相)(十几张图,上传比画图还费劲)

RAC 锁管理与锁问题的定位(一)(有图有真相)(十几张图,上传比画图还费劲)

原创 Linux操作系统 作者:vage 时间:2012-03-07 23:29:55 0 删除 编辑
[i=s] 本帖最后由 vage 于 2012-3-7 23:16 编辑

RAC 锁管理与锁问题的定位(一)(一共十几张图,上传真是费劲,大家支持啊)

(图片要是还没显示出来,大家可以到这里下载doc版:

http://space.itpub.net/321157/spacelist-file)

         从我一到公司,主要工作就是维护我们的一套大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的数据库在运行期间,只有这些东西,需要在节点间同步。

         下面提个问题,猜猜看哪种锁数量最多?

         你一定会说针对BufferBL锁,但不是。大多数情况下,是Row cache lock的数量最多(这里不讨论极致情况)。

         但是Row cachelock通常是静止的,很少修改。数据字典,元数据吗,改动当然不多。而BufferBL锁就不一样的,修改频繁。因此,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-ID2TM是资源类型(也就是锁类型)。参数ID1DBA_OBJECTS中的对象编号,ID20。假设有个表,对象编号是195,它的TM资源(或称为TM锁)的资源名为:TM-195-0。这点对于单实例、多实例来说,是一样的。
         再来找个不一样的,比如一个Buffer。资源类型是BL,两个参数ID1ID2分别是从块地址计算出来的(计算规则我会在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,对象号为1256616进制为3136。我分别在两个节点进行如下操作:
节点2,会话1 insert into t3 values(1,'a');
         插入为DML,在T3对象上要加TM锁。也就是要在资源名为TM-3136-0的资源上,加共享型的锁。

节点2,会话2insert into t3 values(2,'b');
         也在TM-3136-0上加共享型的锁。

节点1,会话1insert 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

锁结构又多了一个,PID12870

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
         锁结构的显示结果就不一样了。在节点21号节点)上,已经有两个锁了(也就是有两个锁结构),但在主节点上,只显示一行。
         这是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
多了一个PID30873的锁。OWNER_NODE节点为00号结构也就是节点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

         第三行,PID10897的,BLOCKED1,代表,代表被别人阻塞了。REQUEST_LEVEL中,请求的锁类型为EX,也就是独占。GRANT_LEVEL列中,获得的锁类型为NL,也就是空锁。
         注意,第一行BLOCKER1Oracle想表达此行阻塞了其他事务,其实,还有第二行对应的节点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
主节点上的事务提交了一个,BLOCKER1的行已经不在了,但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列变为0ON_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进程,请求独占锁,已持有独占锁。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/321157/viewspace-718009/,如需转载,请注明出处,否则将追究法律责任。

下一篇: RAC锁管理模式
请登录后发表评论 登录
全部评论

注册时间:2012-02-28

  • 博文量
    14
  • 访问量
    126639