RAC 中锁的管理—Buffer Lock

ALLSTARS_ORACLE

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��。