星期三 五月 08, 2013

RAC 中锁的管理—Buffer Lock

本文是前一篇文章《RAC 中锁(排队)的管理》的继续,在这篇文章中,我们会介绍RAC

中buffer lock(也称为PCM lock)是如何工作的。


首先,在数据库中,当我们需要访问一个buffer的时候,我们需要在对应的buffer上面加一个锁,而当一个进程持有这个buffer的lock时,其他的进程如果以不兼容的方式访问相同的buffer,就需要等待,对应的等待事件是’buffer busy wait’(不同的版本等待事件可能不同)。在RAC 数据库中,事情变得更加复杂了,由于所有实例访问相同的数据文件,我们需要在多个实例之间保证数据的一致性,所以, 在RAC 环境下buffer lock的结构更加的复杂。


RAC下的buffer lock 由3部分构成:

锁模式(lock mode):对于buffer lock,只有三种 N(空), S(共享)和X(独占)模式。下面的表格说明了各种模式的兼容性。  



锁角色(lock role):本地或共享。本地表示对应的块只在本地被修改过,全局表示对应的块在一个或多个远程缓存中被修改过。

旧镜象(past image):这部分的值为1 或 0。1 表示对应的块存在PI(past image), 0表示不存在。 PI的存在主要是加快RAC 介质恢复,在今后的文章我们会详细的介绍PI的功能。


另外,和RAC中的排队(enqueue)类似,每一个buffer lock都有一个主(master)节点,每个块的主节点是通过hash算法决定的(具体的算法在本文中不作讨论)。主节点包含了对应lock 的全局信息,而每个访问过对应块的节点都包含了本实例的锁信息。


接下来,我们通过下面的的例子说明在RAC 数据库中访问某个block时会发生什么事情。

1. 节点C要求读取块1008。



1)1008块的主节点被hash到D节点,之后节点C向主节点发送请求,要求以S模式锁定块1008。这时buffer lock的模式是SL0(S?hared ,L?local, 0?没有PI)。

2)主节点把对应的锁赋予节点C。

3)节点C 从数据文件中读取块108。

4)读取完成,节点C 以 获得对应的锁,属性为SL0。


2.节点B要求读取块1008。



1) 节点B向主节点D发出请求,要求以S模式锁定块1008。

2) 主节点D发现节点C已经以S模式获得了对应的锁,而且S锁之间是可兼容的,所以,不需要锁的转换,主节点D要求实例C发送块1008 给实例B。

3) 节点C发送对应的块给节点B。

4) 节点B通知主节点D,已经获得了块1008上的S 锁,属性为SL0。


3.节点B要求修改块1008 中的信息。



1) 节点B向主节点D发出请求,要求以X模式锁定块1008。

2) 主节点D发现节点C已经以S模式获得了对应的锁,而且S锁于X锁之间是不兼容的,所以,需要锁的转换,主节点D要求节点C将对应的锁级别降低为N,所得属性为NL0

3) 节点B将自己的所降级,并且将本地的块1008 标识为CR。之后,节点B将块1008 修改为块1009,同时将通知主节点锁的属性为XL0。

4.节点A要求修改块1009。


 1) 节点A向主节点D发出请求,要求以X模式锁定块1009。

2) 节点D发现节点B已经以X模式持有了对应的锁,而且X模式的锁是不能兼容的,所以,主节点D 要求节点B降级锁到N模式,同时由于块在节点A和B都被修改,所以,锁的角色变为全局(Global),而且节点B上的块会变成一个PI。也就是说这时,节点B上的锁的属性为NG1(模式—> N, 角色—>G, 存在PI—>1)。

3) 节点B完成锁的降级之后,把块1009传递给节点A。

4) 节点A修改块1009 为1013,同时将自己节点的锁设置为XG0,并且通知主节点。


5. 节点C 查询块1013。



1) 节点C发送请求给主节点D,要求以S模式锁定块1013.

2) 主节点发现节点A拥有最新的块1013,而且这个节点以X模式锁定了这个块,因为X和S锁是不兼容的,主节点发送请求给节点A,要求降级锁。

3) 节点A降级锁为S模式,同时,由于最新的块会发送给节点C,所以在节点A上的块1013变为PI。接下来,节点A把块1013发送给节点C。这是节点A上的锁为SG1。

4) 节点C收到最新的块1013,并且以S模式锁定块,并把自己的锁更新为SG0。最后,通知主节点D。


根据以上的说明,我们能够看到,对于RAC系统,当一个进程需要访问一个块时,一定要首先获得块上对应的锁,之后才能对块进行相应的操作。而且,在RAC系统中,无论数据库包含多少个节点,当访问一个buffer时,最多会有3个节点参与其中,他们是主节点,持有者节点和申请者节点。而且,每一次访问的时候,都要有消息在节点间不断的传递。另外,我们能看到,如果锁的角色是全局,那么我们要做的事情更多,也意味着我们要访问的代码深度也越多。这也从一个角度解释了为什么oracle 会在RAC中推出DRM,read mostly,reader bypass等新特性(关于后两个新特性,我们会在今后的文章介绍)。



最后,对于PCM lock,以上过程都是由 lms进程完成的。而对于enqueue,是由lmdj进程完成的。


以上的描述,希望对大家理解RAC数据库中锁的管理的机制有所帮助。在接下来的文章中,我们会通过详细的例子对以上的内容进行讲解。


参与此主题的后续讨论,可以访问我们的中文社区,跟帖“共享:RAC 中锁的管理—Buffer Lock��。

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
   
       
今天