RAC Object Remastering (Dynamic Remastering)

本文作者：Riyaj Shamsudeen

翻译：张乐奕（Kamus）

原文链接：http://orainternals.wordpress.com/2010/03/25/rac-object-remastering-dynamic-remastering/

译者注：如果您对本文章有兴趣，请一定先去阅读Riyaj的原文，在万不得已时可以使用这篇译文校对一下自己的理解。译文中的master, mastering, remastering, affinity lock都翻译的不满意，甚至有些词左思右想还是保留了原文。

正文

在RAC环境中，每个数据块都被一个实例所掌控(mastered)。掌控一个数据块意思是主实例(master instance)始终监控这个数据块的状态，直到下一次重配置事件发生（因为实例重启或者其它原因）。

1Hash to the master

这些数据库是根据数据块范围来掌控的。举例来说，数据块范围从file 10，block 1开始到block 128可能是被实例1所掌控，而从file 10，block 129到block 256是被实例2所掌控。当然，在不同的版本10g，11g中都有所不同，只是中心思想都是将数据块均衡地分布在不同实例上，由此Global Cache grants可以在各实例间平衡分布。有趣的是，从10g以后版本数据块范围的长度是128（Julian Dyke提到在9i中是1089，但是我个人还没有测试过）。

技术支持推荐取消db_file_multiblock_read_count初始化参数的设置 ，而使用默认值128，我猜这意味着通过较少的GC消息就可以进行完整的多块读。

Michael Möller指出这种哈希算法可以进一步优化：当通过数据块地址（DBA）初次计算主节点时使用到哈希算法，生成一个“虚拟属主”，然后在通过一个查询表（长度是最大允许的节点数，默认值128）再转化为真实（在线且打开的）属主。这意味着当有一个节点关闭或者启动的时候，RAC不需要为所有数据块再次计算哈希值，而只需要分发新的Hash-to-node表。（这张表在节点发生变化时也同样需要重新分发）

以下SQL有助于显示数据块的属主(master)和拥有者(owner)。这个SQL结合了x$kjbl和x$le表来获得资源名称。如果你对于Oracle锁机制比较熟悉，你可能认识这些缓存融合（cache fusion）锁（以前的PCM锁）的结构。在这里锁类型是BL，id1是block#，id2是file_id。列kjblname2显示的是锁资源的十进制数字格式。

请注意下面的输出： 1． 数据块范围：File 1， block 6360-6376为node 3所掌控同时也属于node 3 2． 数据块范围：File 1,一直到10709数据块为实例0所掌控，属于实例3 3． 从10770开始的下一个数据块范围为实例2所掌控并且属于实例3

还请注意这些输出是从一个还没有remastering操作的数据库中获得的。

REM kjblname2列逗号前第一部分是数据块，第二部分file_id*65536是BL locks

让我们看一下在实例3上运行3种简单SELECT语句的情况： 1．一个会话尝试读取数据块file 1，block 10776，但是这个数据块被实例2掌控同时又被实例2拥有（也就是该块现在存在于实例2的buffer cache中）。这时，实例3将给实例2发送一个PR（Protected Read）模式的BL锁要求读取该块。更加复杂的情况我们先忽略掉，实例2将授予实例3一个PR模式锁并且将数据块传送给实例3。显然，这将会有多个GC消息、锁授予和块传递。统计值‘gc remote grants’也会增加。

2．假设此会话尝试读取数据块file 1, block 6375。此块为实例3掌控同时被实例3拥有，那这时候就不会有额外的GCS/GES过程了，会话直接pin住buffer然后继续工作。

3．考虑第三种情况。会话尝试读取数据块file 1 block 6374。此块不在任何实例的buffer cache中，但是实例3是这个块的属主，所以只需要消耗少量GC消息和等待而获得本节点的affinity locks，然后将数据块从磁盘读到缓存中来。

在上面的情况2和情况3中，请求者实例同时也是数据块或者块范围的属主节点。在这种情况下，统计值‘gc local grants’增加，这些块上获得的本节点的affinity locks代价较低，这样避免了大量的全局缓存消息。

目前为止一切都很好，但是如果有这样一种情况，实例1在频繁读取一个对象（表、索引等），而其他实例则完全不读取该对象呢（某些应用的代码分区策略或者负载策略就会产生这种现象）？频繁读取一个对象的实例需要为每次OPEN该对象数据块的操作向远程实例请求授权，这合理吗？特别是，当数据块被读进buffer cache，但是又很快从buffer cache中消失的时候呢？如果说频繁读取某个对象的实例又恰恰是这个对象的属主，就像我们在情况2和情况3中看到的那样，这岂不是更好吗？ 除此之外，如果数据块即将从缓冲池中移走或者即将被覆盖，就会导致在主实例和其它实例之间的额外消息开销，因为所有权信息需要再被送回块的属主处。

接下来我们认识对象remastering。

2Object Remastering

在10g/11g RAC中有很多新功能。其中一个就是对象remastering。这个特性在10gR1中引入，10gR2中得到提高，11g中的得到进一步增强。我注意到其实在9i中也有相应的参数，不过我认为实际上并不能正常工作。

有了对象remastering特性，如果一个对象被某个实例频繁访问，那么这个实例将会成为这个对象的master，以此来减少gc remote grants从，提高整个应用的性能。

我用到了“访问（accessed）”这个词，但是实际上并不太贴切，更准确的说法是如果某个实例请求了一个对象上的很多BL锁，那么这个对象将remastered。理想情况下，即使应用程序没有完善的分区策略，remastering被某个实例频繁读取的对象这样的举措也会因为获取的是更廉价的本地实例亲和锁（affinity locks），从而使RAC开销降到最小。

但实际上会有几个问题：

1．重启以后实例不会记住之前的属主情况。这意味着每次重新启动实例都需要重新学习对象的属主情况图。我能预计想要记住属主情况是比较复杂的，但是我认为还是有可能实现的。

2．Remastering的代价并不低。在重配置时实例GRD会被冻结(frozen)，而繁忙时这个操作可能需要几秒钟，这将会导致整个实例在这几秒内被冻结。虽然10gR2推出了并行重配置（parallel reconfiguration）（通过_rcfg_parallel_replay初始化参数控制）使用所有LMS进程来完成重配置，但是几秒钟的系统冻结在很多环境中还是完全不能被接受的。

3．我建议将LMS进程保持在较低的个数（最多3-5），但是如果降低LMS进程数目，那么实例重配置的有效并行度也会降低。

4．最后，还有很重要的一点，对于较繁忙的环境来说，触发remastering事件的默认参数值通常过低，因此导致了频繁的对象remastering。在EBS环境中，对于manager的配置稍稍处理不善就可能导致大量的重配置问题。

3Parameters, views and internals

控制remastering行为的有几个参数，这部分的相关文档说明很少。我的测试结果也并不是非常精确。但是，这些参数还是给了我们一个内部到底如何运作的大体概貌。这些在10gR2版本以前是有效的。而对于11g，整套参数都不一样了。

（1）x$object_affinity_statistics

维护对象和对象上的OPENs的统计信息。理解OPEN和Buffer Access之间的区别是重要的。如果缓存中的数据块已经处于适当的模式，就没有必要在数据块上打开BL锁，所以如果会话反复存取同一个数据块而不请求额外的BL锁，那么计数就不会增加，因此所谓OPEN就是某一刻的时间帧内对于BL锁的请求计数。

（2）LCK0进程

维护对象affinity的统计信息。如果一个实例在比另一实例在某一对象上多打开了50个open（由_gc_affinity_limit参数控制）（译者注：实际上在超过2节点的RAC中，该参数的意思是如果一个实例比环境中其它所有实例访问某一个对象的总和还要多50），那么该对象将成为remastering候选者。该对象被放入队列，LMD0进程读取队列，开始GRD冻结。

（3）LMON进程

协同LMS进程一起执行buffer cache locks的重配置。所有的这些动作都可以在LMD0/LMON trace文件中找到。初始化参数_gc_affinity_time控制队列的检查间隔，以确认remastering是否要触发，默认值是10分钟。

我们不希望任何对象都能成为候选者而发生remastering，也就是说，如果仅仅是实例1在某对象上打开了101个BL锁而实例2打开了50个BL锁，那么我们不希望触发该对象的remastering。只有那些有很高的BL锁请求的对象才应该被放入队列并被remastering。此阀值被另一个参数_gc_affinity_minimum控制，只有超过该参数定义的 “每分钟动态affinity活动的最小数量”的对象才会成为候选者而发生remastering。默认值是2500，我认为这在繁忙的系统中有些低。（译者注：在11g中，默认值是1500，更低）

LMD0 trace文件中的以下几行表示LMD0进程正在读取请求队列：

4How bad can it get?

发生Remastering时会影响性能。以下AWR报告显示了DRM重配置问题导致的实例冻结。同样类型的冻结在其它的所有节点上也都可以看见。gc buffer busy等待只是DRM冻结的副作用（不是总有，但是在这个case是这样）。

在同一时刻，DRM大量发生，导致了重复的DRM冻结、实例重配置，从而引发严重的性能问题。

A small test case

我们来看一个测试，观察一下DRM的产生。

使用索引读路径的查询从一个大索引中读取了几乎所有数据块。

session1：

REM 还没有affinity统计信息

select * from x$object_affinity_statistics where object=6099472; no rows selected.

REM 执行高代价的查询语句

:select /*+ index(a WMS_N1) */ count(*) from big_table1 a;

Session #2: 观察DRM表:

REM DRM字段现在是409,我们将持续观察这个数值。在这个视图中还有其它比较有趣的字段。

select drms from X$KJDRMAFNSTATS; DRM ---- 409

REM 观察到自从会话#1开始运行在该索引上已经有23442个OPENs

REM 该对象上还没有发生mastering

select * from v$gcspfmaster_info where object_id=6099472; no rows selected

REM 几秒后，OPENs计数从23442上升到33344

REM该对象上还没有发生mastering

select * from v$gcspfmaster_info where object_id=6099472; no rows selected

REM 让人诧异，会话#1还在运行，OPENs计数忽然清零即使DRM还未发生过。

接下来REM OPENs从0又升到1229因为会话#1还在运行

REM 大约10分钟以后，remastering发生了。DRMS从409上升到411。

select drms from X$KJDRMAFNSTATS; DRM ---- REM

该索引的remastering发生了。现在该对象的属主是0，也就是实例1

REM OPENs还在上升，但是remastering已经发生了。

REM LMON trace文件也指出pkey的传递。注意pkey和object_id是相同的。

REM 几秒后，OPENs被再次重置。

REM 属主仍然是实例1。

我们的测试表明，该索引上发生了大量的BL锁请求，之后对象发生remastering。

5Undo and affinity

回滚段的Mastering和其它段不同。

对于非回滚段而言，一个段上的所有数据块通过哈希算法被分散在各个实例间。只有在经过大量的BL锁请求以后，段才会被mastering。

但是对于回滚段而言，激活了一个回滚段的实例立刻成为该段的属主。这是合乎情理的，因为在大多数情况下回滚段将会被打开这个segment的实例使用。初始化参数_gc_undo_affinity控制这种动态undo remastering动作是否发生。

因为回滚段没有真正的object_id，所以使用4294950912作为虚拟object_ids的基准值。比如说，回滚段1（usn=1）的object_id是4294950913，回滚段2（usn=2）的object_id就是4294950914，依次类推（4294950912 = power(2,32) – power (2,14) = xFFFFC000）。

REM 注意usn 0在两个实例中都存在，这是系统回滚段。

REM 下面结果显示，前10个回滚段被node1掌控，而接下来的3个被实例2掌控。

我没有成功试验出触发下一次回滚段remastering。我创建了一个活动事务在一个节点上产生了200K回滚数据块，然后另外一个节点在读这个表，我观察到在回滚数据块上有大量等待。但是我没有发现这个回滚段上有任何remastering事件。无法确认为什么没有产生，也许是回滚段remastering的条件有所不同吧。

译者注：

回滚段的remastering是不会因为另外一个节点对于回滚段有大量读取而发生的，只有在某个实例失效，然后负责进行实例恢复的另外那个实例会暂时的成为这些回滚段的master，这是为了进行实例恢复的需要，在恢复完毕以后所有的undo buffers都会被flush到磁盘上。

PS：我能够使用后面将描述的lkdebug命令手动remaster回滚段，所以oracle也应该可以自动remaster回滚段，只是可能还有一个其它条件也必须满足。

当然我不是在劝你们去修改这些隐含参数，只是要去理解这些参数，如果你们碰到诸如’gc remaster’, ‘gcs freeze for instance reconfiguration’这样的等待事件，那么应该知道是不是因为默认值太低了。而是否能够修改，则考虑的因素更多。

6Manual remastering

你可以使用oradebug命令来手动remaster一个对象：

这会将一个对象remaster请求放入队列。LMD0和LMON进程会完成这个请求。

当前属主是从0开始计数的。

Summary 总结一下，remarstering是个很棒的功能。不过遗憾的是，这个功能有时候带来的负面影响也很严重。所以，如果你碰到remastering引起的问题，不要直接就禁用它，而是应该去看看能否调优那些参数从而控制remastering事件。

如果你仍然想完全禁用DRM，那么我建议设置_gc_affinity_limit和_gc_affinity_minimum参数到一个较高值，比如说1千万。这样可以完全禁用DRM，但是这也意味着再也无法手工remaster对象了。

另外，Arup也提到如果DRM被禁用那么x$object_affinity_statistics表也不会再被维护。

再次提醒，这些是隐含参数。在你修改这些参数之前确认Oracle Support同意你的举动。

版本变化: 从11g开始，affinity管理更名为policy管理（策略管理）。比如说，x$object_affinity_statistics表改名为x$object_policy_statistics，与之相似的，初始化参数也发生了改变：

（1）参数_gc_affinity_limit改名为_gc_policy_limit；

（2）参数_gc_affinity_time改名为_gc_policy_time；

（3）出现了一个新的视图v$policy_history，其中所有policy_event = ‘initiate_affinity’的记录都是与DRM事件相关的。

除了默认的_gc_policy_limit参数值降低为1500，这意味着，在理论上，11g可能会产生更多的DRM事件。本文涉及到的其他情况在11g中也是成立的。

这篇文章的pdf格式可以此Dynamic_remastering_RAC_orainternals下载.