原文作者：Riyaj Shamsudeen 原文链接：http://orainternals.wordpress.com/2010/03/25/rac-object-remastering-dynamic-remastering/ 译者注：如果您对本文章有兴趣，请一定先去阅读Riyaj的原文，在万不得已时可以使用这篇译文校对一下自己的理解。译文中的master, mastering, remastering, affinity lock都翻译的不满意，甚至有些词左思右想还是保留了原文。IT技术从业者应该以英文为母语。 感谢Yong Huang，从跟他的邮件往来中得到了很多帮助。 ***********以下为译文全文***********。 RAC Object Remastering (Dynamic Remastering) by Riyaj Shamsudeen 在RAC环境中，每个数据块都被一个实例所掌控(mastered)。掌控一个数据块意思是主实例(master instance)始终监控这个数据块的状态，直到下一次重配置事件发生（因为实例重启或者其它原因）。 Hash 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结合了xkjbl和xle表来获得资源名称。如果你对于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…