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…
7614
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
