【深入解析】DRM和read-mostly locking

【原理】11g的DRM引入了read mostly locking的机制，它会基于对象的global operation历史。

read mostly locking机制，能减少读访问的消息传递和CPU消耗，但是写访问就会比传统的cache fusion locking机制消耗更多的IO。

oracle的cache层记录着每个对象上的S lock和X lock的数量，如果某个节点打开了大量的S lock并且很少了的X lock，并且block传输的比较少，那么这个对象在这个节点上就是read mostly了。当read mostly发生的时候，对象的共享就停止了，并且block不再通过interconnect进行传输（除非block被修改）。

当一个对象被定义成read mostly，他会被master node授予在所有节点上的S affinity lock，这意味着所有的节点都被“提前”授予了该block的读访问权限，因此，减少了在各个节点间互相传递S lock的消息量。

Oracle使用一种特殊的叫anti-lock，来控制read mostly对象上的X锁。当x lock被申请时，所有的节点会被广播通知到要打开anti-lock，，在anti-lock的淫威之下，所有的对那个块的访问（不管是S lock还是X lock）都会变成标准的cache fusion locking，即使该对象本身还是read-mostly。广播会在分配X lock之前完成，仅当block上没有anti-lock打开的时候。anti-lock将会在read-mostly消失的时候，或者脏块写入磁盘的时候清除掉，并且X lock会降级。

为read-mostly的对象打开x lock是非常昂贵的操作，在分配x lock之前，master node需要广播anti-lock给所有的节点。在x lock关闭之前，anti-lock不能被移除。另外，在节点加入集群的时候，他也会创建anti-lock，anti-lock只是在LE上标记KCLL_F_ANTI，并且在有anti-lock的情况下，read-mostly lock不能被分配。

【性能优势】在读居多的情况下，由于减少了消息传递，因此"gc cr grant 2-way", "gc current block 2-way" and "gc current block 3-way"的等待大大减少，但是你会看到"db file sequential read"的等待有所增多，因为不在内存间传输block块，而改成去物理文件读取了。GCS消息传递和block transfer的统计值也大大减少了。

在写居多的情况下，X lock的请求会增加，anti-lock广播的次数也会增多，此时"gc current grant busy"的等待就会增加，因为GCS的消息传递增加了。 另外，由于打开anti-lock的block的行为都会变成传统的cache fusion的行为，你将又能看到一些2-way grant和block transfer的等待了。

由于减少分配S lock，只要在读居多的情况下（即X lock申请量不多的情况下），cluster还是很能从read-mostly特性中得到好处的。

这是因为在节点数多的情况下，远程分配的机会将会大大增加。这意味着利用read-mostly将能减少消息传递。另一方面，当节点增加时，X lock的请求将会增多，这是因为X lock的请求会传播到每个节点，当节点数增加的时候，消息传递的成本也增加了。

总而言之，clsuster将会在节点数多，且X lock请求少的情况，因为read-mostly特性而收益。但是当X lock请求增加的事情，性能会急剧的降低。从另一方面说，如果你的节点数比较少，那么或许你从read mostly特性那里得不到很多好处。

而由于read mostly会消耗比较多的IO，这个时候你就要估计你一下你的IO情况了，如果你的块和消息传递的收益小于IO负载变重的情况，或者你已经处于IO压力很大的情况下，那么，就不建议你开启read mostly的特性了，你可以禁用read mostly的特性。设置方式是：_gc_read_mostly_locking=FALSE

因此，read-mostly的特性是给那些读很多，写很少的系统来启用比较合适。

【read-mostly的过渡】

oracle的cache层保留着每个object的x/s lock的请求统计信息，他会根据统计信息，自动初始化或者舍弃read-mostly。这种过渡和affinity很相像，通过标准DRM协议。当cache层看到太多anti-lock的时候，read-mostly将会被舍弃。当read-mostly的负载突然变成大量的写的负载的时候，大量的anti-lock增加的时候，这种过渡就会发生了。举例来说，就是当一个大量被read-mostly的表，进行了大量的update操作的时候，这种过渡就发生了。

说实在的，我一直不知道affinity这个词该怎么翻译，亲和力？吸引力？我们姑且把它叫做对象吸引吧。

在默认的情况下，即当没有吸引机制或者read-mostly策略生效的情况下，buffer cache的资源master权限是会被均匀分发到每个active的节点，也就是说，某个数据库节点成为master的概率是N分之一，N为active的节点数。

吸引机制能通过master节点上被访问最多的buffer cache资源，来减少消息传递和CPU的负载。吸引机制是在10gR1版本引入的，但是只是针对datafile级别，如果某个datafile被某个instance经常访问，所有属于这个datafile的buffer都会remaster到这个节点上。从10gR2版本开始，吸引机制是基于object级别了。某个对象会在某个实例上特别的受欢迎，因此该节点上对应的global cache资源也会变成master。

吸引机制能通过减少代码路径的长度和GCS的消息传递，从而达到优化性能的效果。当一个block是在远端节点是master，GCS信息就要从请求者处发送到master处。用来接收锁分配和读权限。如果这个block remaster到了请求者的节点上，那么消息传递的过程就免了。其他类似的操作也会免了，如写或关闭操作。

一旦吸引完成，请求者节点就基本上能“廉价”的affinity (b)locks，从而大量的减少代码路径。

undo的吸引和对象吸引类似，只不过它发生在undo block上，也就是说，所有的global cache资源的undo segment，都将master在某个实例上。

undo吸引发生在如下的情况下：

undo_management设置成auto时，发生在instance启动的时候，在undo_tablespace里面指定的undo segment，或者当undo_tablespace发生变化时候。

undo_management设置成manual是，发生在instance启动时，在rollback_segments中指定的rollback_segments，或者运行“alter rollback segment…online”，致使rollback_segments变化。

当instance crash时，recovering instance会暂时master crash instance的undo block，当recover完成之后，所有的undo buffer会flush到disk上，用来优化remaster在crash instance再次启动的时候。

 GCS会追踪每个节点、每个对象上的锁请求和锁类型，有3个进程执行DRM的功能：LCK0，LMD0和LMON。

一旦DRM请求开启，它先会将请求加入到请求队列中，接着，LMD0会为DRM请求检查请求队列，如果LMD0找到了一个请求，消息将在各个节点间交换，然后set DRM为freeze状态。  

当所有节点都成功的完成此操作后，LMON进程将发起和LMS进程一起进行remaster操作。

remaster的步骤和LMON进程的reconfiguration类似，remaster会在一个所谓的“窗口”完成，（“窗口”的大小原来由_lm_drm_window确定，在11g中由_lm_num_pt_bucket/_gc_latches决定。）这项技术由于只是冻结部分的资源，因此可用性得到了增强。

它的步骤包含以下几个状态：

QUIESCE - 这个状态是发生在相关的block刚刚完成transfer的情况下，没有新的OPENS和CONVERTS发生在remaster的资源上。

FREEZE - LMON进程等待所有节点都确认当前“窗口”已经被冻结。

CLEANUP - 老的master清理remote lock，并且删除需要remaster的所有对象的resource。

REPLAY - 将本地的lock信息传送到新的master上。 

FIXWRITES - 重建新master节点上的资源的写状态。 

END - 解冻当前“窗口”，移动到下一个窗口。 

SYNC –发生在上述的步骤中。本地的节点等待其他节点完成他们之前的DRM操作。

1. _gc_policy_time (Oracle10g: _gc_affinity_time), default=10

表示检查对象是否进行吸引或read mostly的时间间隔。

2. _gc_affinity_ratio (Oracle10g: _gc_affinity_limit), default=50

表示某节点上的对象访问比其他节点多50倍（2015-11-30 15:40更新，注意是50倍，不是50次。），就认为是满足吸引的条件。

3. _gc_policy_minimum (Oracle10g: _gc_affinity_minimum) default=600 in Oracle10g, 1500 in Oracle11g

表示在发生affinity之前，每分钟每个CPU访问文件/对象的次数。当默认的超过每分钟每个CPU 600次时，触发吸引或read-mostly。 

4. _gc_undo_affinity and _gc_undo_affinity_locks, both default to TRUE

决定undo吸引是否进行。这个参数不建议改动。

5. _gc_transfer_ratio defaults to 2 (which means 50%)

如果block在内存间传输量少于从磁盘读取的block的量的50%，那么read mostly将会被允许进行。

6. _gc_affinity_locking and _gc_affinity_locks, both default to TRUE

决定对象吸引是否开启。

7. _gc_read_mostly_locking, defaults to TRUE

决定read mostly特性是否启用。

8. _lm_drm_max_requests, default=100

在一次DRM中，DRM请求能被处理的数量。