Oracle DRM技术的变迁 (三)

原文连接: http://www.dbaleet.org/the_evolution_of_oracle_rac_drm_season_3/

DRM是Oracle文档没有记录的特性,因为Oracle的架构师认为这个优化应该对于用户来说是透明的,用户没有必要去知道这些细节, 所以故意不不公开的。但是由于10g这个版本由于采取的策略过于激进,导致10g因为DRM导致的宕机和节点驱逐的概率远远高于早期的版本。所以从11g开始,Oracle决定为DRM进行了大量的代码重写,并且重新优化了其架构,当然这一切还是在“偷偷摸摸”下进行的。这些架构中最重要的两个就是read-mostly locking以及reader bypass。

Read-mostly locking

Read-mostly locking是为读多写少的业务进行的优化,也就是说Read-mostly是在牺牲写性能的方式来换取读性能的一种方式,只有在绝大多数操作都是读操作才能起到很好的优化效果。为什么这么说呢?一旦某一个object被定义成read mostly,那么同时在master节点就会授予其它所有节点的S affinity lock,也就是说,所有的节点都被“预先”授予了这个object的读权限,如果此时其它节点需要读取这个object的信息,就不再需要进行单独的授权。那么与授权相关的等待例如我们熟悉的gc cr grant 2-way,gc current block 2-way/3-way等待事件将会大幅度的减少。与此同时,我们会看到db file sequential read的等待事件有所上升,因为原来的共享current block 转移将会被物理磁盘读操作所取代。

我们知道如果需要修改一个object,按照cache fusion的基本原理首先需要向这个object的master节点申请一个X锁(排他锁), 然后才能进行修改。而read-mostly locking则需要先加一个特殊的锁:anti-lock。当一个节点需要申请X锁时,它会向其它所有的节点发送一条广播消息,告诉这些节点打开一个anti-lock。如果所有节点都打开了anti-lock锁,则对于这个object上所有的S/X锁请求都将转换为标准的cache fusion的锁定机制。只有当read-mostly locking被解除(例如写操作的请求明显增加)或者脏块被写会到磁盘并且X锁被降级以后,anti-locks才将被清理。

以上说了一堆非常绕口的话,当然可以用更简洁的话语来描述read-mostly locking的机制:read-mostly就是对于读较多的object预先加上一层锁,大幅减少了读操作所需的授权信息。对于写操作, 则需要先加一个“反锁”进行解锁,然后再按照基本的cache fusion机制完成剩余部分的工作。

 reader bypass

reader bypass与read-mostly locking是互斥的,主要是为读少写多的业务进行的优化。这里说的互斥是object级别的,而非database或者instance级别的,也就是说一个object不能同时既是read-mostly又是reader bypass。

与read-mostly相对,reader bypass同样引入了一种新的锁模式weak X lock(又称xw锁)。有了xw锁,我们就可以在S锁没有释放以前,立刻为一个block加上一个xw锁,加上xw锁以后,可以对这个block进行修改,但是不允许立刻commit,直到所有的的S锁都关闭或者降级到N锁,当所有的S锁都已关闭或者降级为N锁时, LMS就会向xw锁的持有者发送一条信息可以进行commit了。

read bypass 会大量减少gc current grant busy这样的等待,但是明显对于commit比较频繁的应用有较大的负面影响。

 

未完待续

To Be Continued…

Comment

*

沪ICP备14014813号-2

沪公网安备 31010802001379号