RAC 中锁(排队)的管理

本文会对RAC中锁的管理进行介绍,其中包括以下三部分内容。
1.    RAC 中锁的介绍
2.    RAC如何发现死锁
3.    搜集RAC 中锁的诊断信息

适用范围:9.2 及以上版本。

首先,我们对RAC中锁的基本概念进行一些介绍。对于RAC数据库,我们可以把锁分为两类,第一类我们可以称之为buffer lock, 这种锁针对数据库的buffer,另一种锁就是我们经常提到的排队(enqueue)。本文主要介绍后一种( buffer lock 会在今后的文章中介绍)。
既然是锁,那么就会包含等待者(convert)和 持有者(grant) 队列,类型(用来表示所保护的资源),以及访问的模式。另外,对于RAC系统,由于需要在多个实例间维护访问的一致性,每个锁也会有一个master 节点,在master 节点中会包含这个锁的完整的grant 和convert 队列,而每一个访问过这个锁的节点,也会保存本地的grant 和convert 队列。我们在共享池中看到的’ges resources’ 部分,就包含了锁的master信息,当然,也可以认为master信息是GRD 的一部分。
对于锁,另一个重要的概念就是模式(或级别),针对不同的操作,需要获得不同模式的锁,毕竟锁是一种串行的机制,串行在很多时候意味着等待,而我们并不希望看到等待,所以我们需要锁具有不同的模式,来尽量避免等待。同时,也为了保证数据的一致性,锁的有些模式之间是可以兼容的,而有些是不能兼容的。对于RAC系统,我们可以参照以下的表格,了解锁的模式和兼容性。



当用户进程需要申请锁的时候,会发生以下的过程。
1.    申请进程发送消息给master节点,找到关于锁的全部grant 和 covert 队列信息。
2.    Master 节点通知持有者释放(Down convert)相应模式的锁。
3.    如果持有者不能释放,即申请锁的兼容模式无效(进程不能以申请的模式获得锁,因为其他进程正在以不兼容的方式持有这个锁),申请进程进入等待者队列。
4.    当持有者释放锁之后,master节点通知申请进程能够以所申请的模式获得锁并进入持有者队列,申请请求成功结束。




对于RAC环境中的死锁(对于死锁的概念,本文不做介绍),是由LMD进程处理的。基本的过程是。
1.    LMD进程定期搜索各个实例的锁信息,发现可能的死锁。
2.    在可能的死锁进程被发现之后,LMD会验证死锁。
3.    在得到验证之后,LMD会选择回滚导致死锁的进程的当前SQL语句,来打破死锁。

接下来,我们通过下面的例子,对诊断RAC 中锁相关的问题进行简单的介绍。我们用下面的步骤制造一个DML 死锁。
1.    Session1: update emp set ename='new name' where empno=7934;
2.    Session2 : update emp set ename='new name1'where empno=7902;
3.    Session1 : update emp set ename='new name1'where empno=7902;
4.    Session2: update emp set ename='new name' where empno=7934;

之后我们在数据库实例1的alert log 中会找到死锁的信息。
Sun Apr  7 04:45:39 2013
Global Enqueue Services Deadlock detected. More info in file
 /u01/app/oracle/admin/ONEPIECE/bdump/onepiece1_lmd0_6257.trc

从实例1的lmd 跟踪文件中,我们能够找到类似的信息。
DUMP LOCAL BLOCKER/HOLDER: block level 5 res [0x70022][0x1de6],[TX]
----------resource 0x0x3f969794----------------------
resname       : [0x70022][0x1de6],[TX]
……
GRANTED_Q :
lp 0x3f9714e0 gl KJUSEREX rp 0x3f969794 [0x70022][0x1de6],[TX]
  master 0 gl owner 0x456339e8 possible pid 14942 xid 1D000-0001-000000A6 bast 0 rseq 39 mseq 0 history 0x95
  open opt KJUSERDEADLOCK 
CONVERT_Q:
lp 0x3f9715b4 gl KJUSERNL rl KJUSEREX rp 0x3f969794 [0x70022][0x1de6],[TX]
  master 0 owner 1  bast 0 rseq 8 mseq 0x1 history 0x97ad
  convert opt KJUSERGETVALUE 

以上的信息说明对于enqueue  [0x70022][0x1de6],[TX],它的master 节点为节点1,grant 队列中有一个进程14942,convert队列中包含一个进程,但是这个进程在节点2,不会在节点1的跟踪文件中显示出进程的详细信息,需要到节点2的lmd 跟踪文件中查找。所以,我们能够看到master节点会包含enqueue 的全局信息。

----------resource 0x0x423753fc----------------------
resname       : [0xb0004][0xf8f],[TX]
……
GRANTED_Q :
CONVERT_Q:
lp 0x4488c5b0 gl KJUSERNL rl KJUSEREX rp 0x423753fc [0xb0004][0xf8f],[TX]
  master 1 gl owner 0x456339e8 possible pid 14942 xid 1D000-0001-000000A6 bast 0 rseq 113 mseq 0 history 0x1495149a
  convert opt KJUSERGETVALUE 

以上的信息说明对于enqueue  [0xb0004][0xf8f],[TX],它的master节点为节点2,grant 队列为空,而convert队列中有1个进程14942, 但是,由于节点1并不是这个enqueue的master节点,所以只能显示本地节点的信息。如果要获取这个enqueue的全部信息,需要查看节点2的lmd跟踪文件。

对于RAC中死锁的问题,LMD跟踪文件会描绘死锁的图像。也就是经常提到的WFG。
Global Wait-For-Graph(WFG) at ddTS[0.1] :
BLOCKED 0x4488c5b0 5 wq 2 cvtops x1 [0xb0004][0xf8f],[TX] [1D000-0001-000000A6] 0
BLOCKER 0x5d8512dc 5 wq 1 cvtops x8 [0xb0004][0xf8f],[TX] [16000-0002-00000043] 1
BLOCKED 0x5d88d58c 5 wq 2 cvtops x1 [0x70022][0x1de6],[TX] [16000-0002-00000043] 1
BLOCKER 0x3f9714e0 5 wq 1 cvtops x8 [0x70022][0x1de6],[TX] [1D000-0001-000000A6] 0

以上信息的含义,可以参考Note 242263.1 : Analyzing ORA-60 Deadlocks in a RAC Environment。

最后,对于诊断RAC中锁的问题,我们还可以通过以下的信息进行诊断
查询视图gv$lock, gv$ges_enqueue
搜集 systemstate dump, hanganalyze dump 文件
搜集 lmd 跟踪文件 和产生的用户进程跟踪文件。





评论:

发表一条评论:
  • HTML语法: 禁用
About

本博客由Oracle全球技术支持中国区的工程师维护。为中文用户提供数据库相关的技术支持信息,包括常用的诊断工具、诊断方法、产品新特性、案例分析等。此外,MOS也陆续推出各类中文内容:技术通讯统一发布在Note 1529795.1 中,中文文档列表更新在Note 1533057.1 中,网上讲座请查看MOS文档 1456176.1,在"Archived"中可以下载历史的录音和文档。

Search

Archives
« 四月 2014
星期日星期一星期二星期三星期四星期五星期六
  
1
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
今天