Oracle DRM技术的变迁 (八)

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.askmaclean.com/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。

 

未完待续…

Comment

*

沪ICP备14014813号

沪公网安备 31010802001379号