http://www.dbaleet.org/the_evolution_of_oracle_rac_drm_season_8/
在11.2.0.2以上的版本中，DRM的read mostly的功能同样也有一些细微的改进，但是这些改变都是背后“偷偷摸摸”进行的，不大可能能在oracle的官方文档或者支持网站中找到。
首先一大改进叫做persistent read mostly，在以往的版本中， read mostly这个特性并不是可以持续的。换而言之，如果集群彻底的关闭或者重启，那么重启以前的read mostly就复位了，本来read mostly的特性已经根据应用的业务特点做了足够的优化，但是重启以后，所有的优化都消失了。而persistent read mostly就是为了解决这一问题而来。
所以11gR2中引入了一个新的后台进程叫做GEN0， 这个进程其中一部分工作就是与persistent read mostly 相关的，这一部分工作包括:
kcl downconvert object locks GEN0
kcl update persistent read mostly info GEN0
kcl initiate persistent read mostly GEN0
以上GEN0的功能节选来自：Maclean Liu的blog：
http://www.askmac.cn/archives/learning-11g-new-background-processes.html
GEN0平时会把read mostly的对象做一个read mostly的标记，然后更新到对应的seg$条目中去。我们可以通过以下SQL来查询其对应的persistent read mostly的对象：
PROCEDURE list_readmostly
IS
BEGIN
FOR cur IN (select owner, segment_name, partition_name
from sys_dba_segs
where bitand(segment_flags, 268435456) > 0)
LOOP dbms_output.put_line('(SCHEMA, OBJECT_NAME, PARTITION_NAME) = ('
cur.owner || ', ' ||
cur.segment_name || ', ' ||
cur.partition_name || ')');
END LOOP;
END list_readmostly;
其中268435456是一个标志位代表KTSSEGM_FLAG_READMOSTLY，而这个最终是查询seg$基表的信息而获取的。
但是在11.2.0.3这个版本，存在一个Bug 16297327 GEN0 performance issues due to read-mostly requests in RAC
正是因为这个bug可能导致seg$基表的标志位没有及时更新。所以通过
select data_object_id, GC_MASTERING_POLICY from v$gcspfmaster_info where gc_mastering_policy = 'Read mostly';
从内存中看到的read mostly的对象可能跟通过seg$查询到的read mostly的对象数量上存在差异。注意这个bug在11.2.0.4以上已经修复。
在集群彻底重启以后，第一个实例会读取seg$基表中的信息，然后将重启以前的read mostly属性按照重启以前的状况迅速还原。
persistent read mostly这一特性受到隐含参数_gc_persistent_readmostly的控制，默认情况下，这个参数为true，也就是处于开启状态。
如果数据库的对象，或者分区特别多的时候，GEN0初始化persistent read mostly的过程可能相当漫长。因为此时对seg$这个基表会变得非常大，对其进行扫描往往效率很低，因为这个初始化的过程发生在实例启动的过程中，如果这个过程效率很低，会大大增加数据库打开的时间。根据Bug 9876756 : IN RAC ‘ALERT .. SET RESOURCE_MANAGER_PLAN’ HANG, WAITING FOR ‘RELIABLE MESSAGE’的描述，在某些Exadata的环境下，数据库打开的时间可能会超过半个小时。虽然用户可以通过设置隐含参数将这一特性关闭，但是这显然不符合用户的期望值。那么因此有人提了一个enhancement request希望能够提高这一过程的效率。根据Bug 9981399 : PERSISTENT READ MOSTLY INITIAL SEG$ SCAN (KCLIPRM_ACTION) NEED TO BE PARTITIONED的描述，在12c上seg$这个基表被改造为分区表，从而有望彻底解决这个问题。
另外一个值得一提的read mostly的新特性叫做Static Read Mostly Objects。这一特性受到隐含参数_lm_file_read_mostly控制。默认为空。顾名思义，也就是用户可以手工静态设置一个对象的read mostly属性。这个特性对一般用户用处不大，跟之前文章提到的另外一个参数_lm_file_affinity类似，之所以存在这一个特性是因为Oracle内部的一些性能测试和POC的需要。
在正常生产系统中，我们不应该去touch这个参数，请不要在oracle support给出修改建议之前修改这个隐含参数。这个参数并不是太好使，例如已知的bug包括：Bug 8966217 : NEED SUPPORT FOR STATIC FILE READ MOSTLY WITH STATIC FILE AFFINITY。
未完待续…
Leave a Reply