锁管理与锁定位问题

1、RAC 锁管理与锁问题的定位（一）(第二篇，实践篇已经整理出来：         从我一到公司，主要工作就是维护我们的一套大RAC。主库5个节点，备库最多时曾有4个节点，后来备库减至单实例了。主、备一共8套存储，总间共300T空间。内部互联采用业内最快的InifiniBand。也算是豪华配置了。最高峰时，主库数据130T左右，每天归档量巅峰时接近6T，是我见过的最大、最忙的数据库。         库一大，很多本来不是问题的问题，就会变成问题。比如数据字典维护，Oracle在

2、这一块上做的很好，因为这是Oracle的根本。这一块上罕有问题的。但是，当数据库中有几百万个段时呢！其实就算有几百万个段，Oracle也运行的好好的，在极偶然的情况下，会遇到问题。还有控制文件，通常也就几十M，但当它接近1G呢，它就会像一个活火山一样，偶而爆发。另外，还有更容易想到的，如备份的问题，搭建备库的问题等等。如果一个库只有1T，搭建个备库只需要几个小时，但是上百T呢！不但是时间问题，选择合适的方法是另一个需要考虑的问题。         平时工作太忙，现在有时间了，慢慢和大家分享，总比烂在我的肚子里强。  

3、0;      开始今天的正题，聊一聊RAC中的锁管理。         大家一般对RAC中的CacheFusion比较熟悉，而对锁管理，讨论的不多。其实，锁管理更为基础，因为块，或者更准确点，Buffer cache中的Buffer，也是锁管理的对象之一。好，下面我们开始。一、         首先，了解一下RAC中要管理的锁的类型：（一）、你在V$LOCK中看到的全部锁，这一部分我们可以称之为高级队列锁。（二）、Library ca

4、che lock/pin，还有Row cache lock，这一部分我们称之为中级内存锁。（中级内存锁还有一个，就是Buffer pin，它导致的竞争，就是我上遍文章中所讲的buffer busy waits。注意啊，想降低buffer busy waits吗，哪就使用更快速的设备存放Redo File吧。详在中的第一遍日志，或在上个帖子中参加讨论：（三）、还有，就是针对Buffer cache中的块的锁了，Oracle为它定义的类型为BL。         上面这些，就是RAC锁的全部了。也就是说，RAC的数据库在运行期间，只有这些

5、东西，需要在节点间同步。         下面提个问题，猜猜看哪种锁数量最多？         你一定会说针对Buffer的BL锁，但不是。大多数情况下，是Row cache lock的数量最多（这里不讨论极致情况）。         但是Row cachelock通常是静止的，很少修改。数据字典，元数据吗，改动当然不多。而Buffer的BL锁就不一样的，修改频繁。因此，Oracle在普通的锁管理机制之外，针对BL又

6、搞了个Cache Fusion。好，这里就不讨论它了，以后我会再详细讨论Cache Fusion的。二、         资源池与主节点         和单实例中的队列锁一样，RAC中的锁，也分为两部分：资源结构和锁结构。         在共享池中，还有一个资源结构池，审请锁的第一部，就是到这个池中审请一个Free的资源结构。         可以把资源

7、池想像一块内存，其时，它就是一大块内存，在实例启动时分配。如下图：在资源池中，内存又被分成一个个小块，每个小块，就是上图中的一行，Oracle称为一个Slot。每个Slot，就叫做一个资源结构（Resource struct）。每个资源结构中的主要信息如下：资源名（RESOURCE_NAME）转换者队列地址（ON_CONVERT_Q）持有者队列地址（ON_GRANT_Q）主节点（MASTER_NODE）         可以进一步把资源池想像成如下的表格：我们把其中重要的东西解释一下。      

8、;   1、资源名：和单实例中的队列锁一样。资源名由资源类型加两个参数构成。比如TM锁的资源名，一般写为TM-ID1-ID2，TM是资源类型（也就是锁类型）。参数ID1是DBA_OBJECTS中的对象编号，ID2为0。假设有个表，对象编号是195，它的TM资源（或称为TM锁）的资源名为：TM-195-0。这点对于单实例、多实例来说，是一样的。         再来找个不一样的，比如一个Buffer。资源类型是BL，两个参数ID1、ID2分别是从块地址计算出来的（计算规则我会在Cache Fusion中详细描述）。这

9、个BL-ID1-ID2锁，在单实例中，绝对不会出现。        2、转换者队列和持有者队列：这分别是两个链表，记录有多个进程持有锁，或正在等待锁。RAC认为每个实例中的每个进程都可以获得空锁，所以，如果进程想获得独占锁，但没有成功，那么它是要从空锁转换成独占锁而没有成功。所以这里没有等待者队列，只有转换者队列。我们可又把转换者队列，理解为等待者队列，记录所有正在等待进程信息。        3、主节点：这个信息，是单实例中资源结构所没有的。RAC中，每个锁都有一个主节点。

10、或者，准确点说，每个资源结构都有一个主节点。         主节点的计算方式，是用资源名作HASH。这里的HASH算法，可以理解为根据资源名的一串字符，求得一个数字，再用这个数字除以节点数，取余数。比如有个这样的资源名，TM-1234-0，求得的HASH值为3，它的主节点就是3。         某个节点的进程，如果想对某个资源加锁，第一步就是根据资源名计算出HASH值，根据HASH值找到资源的主节点。注意：锁，或者队列锁，也叫资源。它包含两部分信息，资源结构和锁结构。资源

11、结构有主节点，锁结构没有主节点。千万不要被资源结构、锁结构这样的名称所误导。这两个东西，就是锁的两部分信息。三、资源结构的查找         各节点的进程想要加锁，第一步就是定位资源结构。如何定位，HASH算法。Oracle内部，只要涉及在内存中查找东西，比如要Buffer Cache中找某个Buffer，在共享池中找某条SQL，等等，全部用的是HASH。资源结构的查找定位也不例外。         比如，有个表叫MythData，节点1的进程程想在MythData表上加锁

12、，此表的对象编号为1234，那么资源名为TM-1234-0，根据此资源名，计算HASH值，得到主节点为2号节点。节点1向节点2发送加锁请求。接到加锁请求，节点2根据TM-1234-0这个资源名，再次计算HASH值，这次不再是为了求主节点了，是为了在自己的内存中定位此资源的资源结构。         如下图：接下来，节点2在自已的内存中定位资源TM-1234-0：四、锁结构         如果节点1可以持有TM-1234-0，接下来Oracle会如何处理呢？在资源结构上加锁结

13、构。         我们再一次强调，千万不要被资源结构、锁结构这样的名称所误导。这两个东西，就是锁的两部分信息。         同样的，共享池中也有一个锁池，如下图：再进一步的，锁池内存也被分为一个个的小块，每一块称为一个Slot，就是图中的一行。每一行我们就称之为一个锁结构。         锁结构中的信息比较多，有资源名、加锁的节点、加锁的进程、锁结构所在队列、状态等信息。下面把重要的说一下：  &

14、#160;      加锁的节点：锁结构没有主节点，锁结构只会隶属于某个资源结构。而资源结构是有主节的。         锁结构所在队列：如果请求进程可以加锁，锁结构会被加入资源结构的持有者队列。否则，如果有其他人以不兼容的方式持有锁，请求进程将被挂在资源结构的转换者队列，也就是说，请求被阻塞了。         也就是说，锁池的形式如下：好，下面我们来详细说一下完整的锁的获取过程。接着上面第10点。五、完整的锁的获取过程 

15、       上面第10步，已经说到，主节点2中，TM-1234-0的资源结构显示，无人持有此资源，持有者队列为空。转换者队列也为空。哪么节点1可以持有此资源。         接下来再看下面这些图：注意，下面的图，和上面的图的区别，多了个箭头。第15步的目的，就是建立资源结构和锁结构的联系。更通俗点说，就是将锁结构挂到对应资源结构的持有者队列中。         至此，节点1的操作完毕。主节点（节点2）也会有类似操作。主节点

16、上的操作不再详述，大至如下：（1）、如果TM-1234-0在节点2上还没有资源结构，节点2会在自已的共享池中的资源池中审请一个Slot，并填入信息（2）节点2在共享池的锁池中审请一个锁结构，并填入信息。（3）、将锁结构挂在资源结构的持有队列中。具体如下：也就是说，主节点和审请节点，都会有锁的相关信息。再次强调，“锁的相关信息”指的就资源结构和锁结构。六、实际操作         理论先说这么多吧，下面来点实验。我们的最终目的，是要从理论中学习如果RAC出现了锁问题，如何定位。我们研究理论，也要和实践挂钩，要不然，理论就成了虚无飘渺的东

17、西。但是，有时研究内部、研究理论，不是马上就能有成果，往往需要潜心研究一段时间才可。         总之，我的观点，研究内部，一定不能满足于听一听、或看一看别人的成果，这样的研究，毫无意义。一定要自己动手，反复测试、验证别人的理论，这样才会进步。         好，闲言少叙，开始。1、测试环境         两节点RAC，有表T3，对象号为12566，16进制为3136。我分别在两个节点进行如下操作：节点2，会

18、话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');     &

19、#160;   同上。节点1： lock   table   t3  in   exclusive   mode ;         在TM-3136-0上，加独占锁。         每做完一步，用视图观察资源结构和锁结构。步1：在节点2执行：SQL> insert into t3 values(1,'a'); 1 row creat

20、ed.步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- - -0x31160x0,TM

21、60;                       0          1           0RESOURCE_NAME：资源名，就是TM-3116-0。ON_CONVERT_Q：转换者队列中锁结构的数量。现在为0，也就是没有人补阻塞。ON_GRANT_Q： 持有者队列中锁结构的数量。现在为1，有进程的

22、锁结构在持有者队列中。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_G

23、RANT_QMASTER_NODE- - -0x31160x0,TM                        0          1           0         和在节点2查看一样。（3）、在节点2查看锁结构：SQL&g

24、t; set linesize 1000SQL> col STATE for a15SQL> 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   BLOC

25、KER- - - - - - -KJUSERCW KJUSERCW   29079    1      1 GRANTED             0          0GRANT_LEVEL： 锁的类型，我只记得最后两个字母的意义，CW是共享，EX为独占，NL为空锁。REQUEST_LEVEL：请求的锁的类型。PID：进程号。OWNER_NODE：审请并持有锁的节点。此处为

26、1，即节点2.WHICH_QUEUE：锁结构被挂在资源结构的哪队列中。此处是1，即持有者队列。为0则为转换者队列，共表正在等待。STATE：状态。BLOCKED：是否被阻塞。BLOCKER：是否阻塞别人。         根据这些列的信息，我们可以知道，29079号进程，在节点2上审请TM-3116-0资源。请求的模式为共享，得到的模式也为共享，没有被阻塞。（4）、在节点1观察锁结构：SQL> set linesize 1000SQL> col STATE for a15SQL> select GRANT_LEVEL

27、, 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  &

28、#160;     1 GRANTED              0          0         显示结构同在节点2中看到的基本一样。有一列不同，就是PID列，此处为0。步3：再在节点2执行一条DML语句：另外在节点2上打开个一会话，执行：SQL> insert into t3 values(2,'b');

29、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- - -0

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

31、。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  

32、;12870          1           1 GRANTED         0          0KJUSERCW KJUSERCW  29079          1        

33、0;  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   

34、0;              ON_CONVERT_Q ON_GRANT_QMASTER_NODE- - -0x31160x0,TM                        0          1         

35、60; 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- - - - -

36、 - -KJUSERCW KJUSERCW   0          1        1 GRANTED          0          0         锁结构的显示结果就不一样了。在节点2（1号节点）上，已经有两个锁了（也就是有两个锁结构），但在主节点上，只显示一

37、行。         这是Oracle为了节省内存做的优化。主节点没有必要知道其他节点持有的全部锁，只需要知道某个节点持有的最高级别的锁即可。现在，1号节点也就是节点2，持有的最高级别的锁是共享锁。步5：在节点1上执行DML：SQL> insert into t3 values(3,'c');1 row created.步6：查看信息（1）、资源结构中的信息，在两个节点中都没有变化。（2）、锁结构的信息，节点2没有变化。因为节点2不是主节点，并且新的操作也不是在节点2上产生的。所以节点2上的锁结构完全没有变化。（

38、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 KJUSER

39、CW   30873       0           1 GRANTED          0          0KJUSERCW KJUSERCW    0          1        

40、0;  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上

41、资源结构：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- - -0x31160x0,TM     

42、0;                  1          1           0ON_CONVERT_Q列变为了1。证明有进程被阻塞、放进了转换者队列。（3）、节点1上锁结构：SQL> select GRANT_LEVEL, REQUEST_LEVEL,PID, OWNER_NODE,WHICH_QUEUE,STATE,BL

43、OCKED,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      

44、60;    1 GRANTED        0          1KJUSERCW KJUSERCW      0         1           1 GRANTED         0 

45、;        0KJUSERNL KJUSEREX    10897          0           2 OPENING        1         0         第三行，PID为10

46、897的，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 GRA

47、NT_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   

48、;       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

49、 like '0x3116%TM%'GRANT_LEV REQUEST_L  PID OWNER_NODE WHICH_QUEUE STATE    BLOCKED   BLOCKER- - - - - - -KJUSERCW KJUSERCW   30873          0           1 GRANTED     &

50、#160; 0          1KJUSERCW KJUSERCW      0          1           1 GRANTED        0          0KJUSERNL KJUSEREX 

51、60; 10897          0           2 OPENING        1         0没有变化，虽然有一个事务提交了。原因是什么，你可以自己考虑一下，很简单的哦。步11：将节点1中的DML事务提交：SQL> commit;Commit complete.步12：观察信息：（1）、节点1和节点2中的资源

52、结构都没有变化。（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

53、60;  BLOCKER- - - - - - -KJUSERCW KJUSERCW       0         1           1 GRANTED       0         0KJUSERNL KJUSEREX    10897     &

54、#160;   0           2 OPENING        1         0主节点上的事务提交了一个，BLOCKER为1的行已经不在了，但10897还在被阻塞，因为另一个节点上仍有事务。步13：提交节点2上最后一个DML：SQL> commit;Commit complete.步14：观察信息：（1）、节点2上资源结构变化如下：SQL> sele

55、ct 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- - -0x31160x0,TM         

56、60;              0          0           0也没有太大的变化，就是ON_GRANT_Q变为0。代表持有者队列已经空了。（2）、节点2上锁结构视图为空。因为锁提交了。（3）、节点1上资源结构：SQL> select RESOURCE_NAME, ON_CONVERT_Q,ON_GRANT_Q, MASTER_NODE from

57、 V$DLM_RESS where resource_name like '0x3116%TM%'RESOURCE_NAME                  ON_CONVERT_Q ON_GRANT_QMASTER_NODE- - -0x31160x0,TM                      

58、60;0          1           0ON_CONVERT_Q列变为0，ON_GRANT_Q变为1。也就是说，刚才在等待的进程，已经从转换者队列，变到了持有者队列。（4）、节点1锁结构：GRANT_LEV REQUEST_L   PID OWNER_NODE WHICH_QUEUE S      BLOCKED   BLOCKER- - - - - - -KJU

59、SEREX KJUSEREX    10897         0           1 GRANTED       0          0KJUSERNL KJUSERNL      0           1&#

60、160;          1 GRANTED       0          0第二行显示，节点2上的锁，现在已经变成空锁。第一行显示，10897进程，请求独占锁，已持有独占锁。在上一篇中，我们讲述了RAC下锁的管理模式。本篇中，我们总结下出现锁问题后的定位。有上节的基础，你会发现在RAC下查找锁问题，是如此的简单。（如果还没有阅读前一篇，最好先看前一篇，再看本篇。前一篇链接：（另外，PPT有点简单了，大家凑合着看，后面我

61、慢慢再整理稍微深入点的东西）我们这次以TX锁为例，TX锁的竞争最为常见。我们的语句：update t3 set id=id+0 where id=3;我在两个节点执行如下语句，肯定会被HANG住一个。下面，我们来说一下RAC下锁问题定位的一般步骤。一、查找资源名在被HANG住的节点中执行如下语句，查找请求模式为6、锁类型为TX的行：select * from v$lock where type='TX' and REQUEST=6;ADDR     KADDR         &

62、#160; SID TY        ID1        ID2      LMODE    REQUEST      CTIME      BLOCK- - - - - - - - - -320CBB30 320CBB44        193 TX 

63、  1048616        291          0          6       1410          0其实，我们要找的，是正在等待的TX锁的资源名：TX-1048616-291，化成16进制，TX-100028-123。变成V$DLM_RESS、V$GES_ENQUEUE视图中的格式

64、：0x1000280x123,TX。下面这条语句，直接输出资源名：SQL> select '0x'|lower(trim(to_char(id1,'xxxxxxxx')|'0x'|lower(trim(to_char(id2,'xxxxxxxx')|','|type|''  from v$lock where type='TX' and REQUEST=6;'0X'|LOWER(TRIM(TO_CHAR(ID1,'-0x1000280

65、x123,TX二、定位主节点找到资源名后，就可以在V$DLM_RESS中，以资源名为条件，查找此资源的主节点：SQL> select RESOURCE_NAME, ON_CONVERT_Q,ON_GRANT_Q, MASTER_NODE from V$DLM_RESS where resource_name like '0x1000280x123,TX%'RESOURCE_NAME                  ON_CONVERT_Q ON_GRA

66、NT_Q MASTER_NODE- - - -0x1000280x123,TX                    1          0           1此资源的主节点是1，也就是第二个节点。上面两条语句，还可以合在一起：select RESOURCE_NAME, ON_CONVERT_Q,ON_GRANT

67、_Q, MASTER_NODE from V$DLM_RESS where resource_name like (select '0x'|lower(trim(to_char(id1,'xxxxxxxx')|'0x'|lower(trim(to_char(id2,'xxxxxxxx')|','|type|''  from v$lock where type='TX' and REQUEST=6)|'%'三、定位持有锁的节点仍在审请锁被阻塞的节点，

68、查询GV$GES_ENQUEUE视图，语句如下：col STATE for a10select inst_id,GRANT_LEVEL, REQUEST_LEVEL,PID, OWNER_NODE,WHICH_QUEUE,STATE,BLOCKED,BLOCKER from GV$GES_ENQUEUE where  resource_name1 like (select '0x'|lower(trim(to_char(id1,'xxxxxxxx')|'0x'|lower(trim(to_char(id2,'xxxxx

69、xxx')|','|type|''  from v$lock where type='TX' and REQUEST=6)|'%'结果如下：   INST_ID GRANT_LEV REQUEST_L        PID OWNER_NODE WHICH_QUEUE STATE         BLOCKED    BLOCKER- - - - - - - - -         1 KJUSERNL