大话ORACLE RAC 笔记之RAC架构

    RAC下的并发控制

    Real Application Cluster 真正应用集群不是双机热备,一台机器在空闲中等待 。它是Share-Disk的集群架构 。原来在单台机器中的并发，被扩大到多台计算机上的进程并发。 因此一个事务在获取TX锁时，还必须检查其它机器上是否有事务对同样的数据获取TX锁。因此RAC必须 有一个在多台计算机上检测并发的机制，它就是 分布式锁管理器（Distributed Lock Management)。可以把DLM看成是一个“仲裁”，它记录着那个节点正在用哪种方式操作 哪个数据，并负责协调各个节点间的竟争 。任何节点在修改 数据前必须向DLM申请对数据所在的“数据块” 的操作权限。选择数据块是性能方面权衡的结果

     DLM中的资源和锁

    DLM中协调各节点对资源使用的功能叫同步，所有资源访问都是需要同步的，节点间的同步是 为了保证数据一到处性，有得必有失，同步需要 在节点间传输数据及访问DLM ， 这会影响集群的性能。 如果同步非常频繁那么将严重影响集群的性能 。为了将同步活动降到最低又正好满足需要。DLM根据资源 数量、活动密集程度 将资源分成两类。 分别是Cache Fusion Resource 、None-Cache Fusion Resource。Cache Fusion Resource特指数据块资源，包括普通数据块、索引数据块、段头、UNDO数据块。非数据块资源全部都归类为None-Cache Fusion Resource，包括数据文件、控制文件、数据字典视图 、Library Cache、Row Cache等。 对应两种资源，DLM提供的锁也分成两种，PCM LOCK和Non-PCM Lock。 它们都是全局锁（Global Lock）－－PCM means  Parallel Cache Management

    None Cache Fusion 资源

    典型的None-Cache Fusion资源包括Share pool的Row Cache 和Library Cache内容。library cache中存 放的是所有SQL语句、 执行计划、包等对象 ，以及这些对象所引用的对象。当一个语句或包编译时，它们所引用的所有对象都会加一个Library Cache Lock  ，在执行时，所有这些引用的对象都要被加一个Library Cache Pin，以保证 语句在执行时这些对象的结构不会被修改 。编译完成后， 加在引用对象上的Library cache lock会由原来的share或exlusive模式变成null模式。Null模式的Library cache lock相当于一个触发器，当这些对象的定义被修改后引用它的对象将被 置为无效，必须重新编译。

    在RAC环境下，这个问题进一步 延伸。比如 每个节点上都有某个表的引用对象，无论任何一个节点对这个表的修改，都有把所有节点上对 该表有引用的对象置为无效 。因此除了传统的Library cache lock这外， 每个节点上要有一个进程叫LCK0，对本实例的Library cache中的对象加一个Share-mode的IV（Invalidation）Instance Lock，如果某个用户想要修改  对象定义，必须获取一个Exclusive模式的IV锁，这会通 知本地的LCK0释放Share-mode锁,本地LCK0在释放这个锁这前，会通知其它节点上的LCK0将该节点上的Library cache中的所有相关对象置为失效。这是一种广播机制 。这些通信过程是由实例的LMD进程完成的。

    Row cache中存放的是数据字典，其目的是编译过程减少对磁盘的访问。其内容 也需要在所有的实例中同步 ，其同步机制和Library cache是一样的，也是由LCK0进程完成。

    可以看出None-Cache Fusion资源也以下特点。

    1、 资源数量有限：比如Row Cache 存放的是对象定义，Library Cache存放的是SQL代码 、执行计划等 。在一个生产系统中，表、 视图、存储过程、包的数量是有限的，SQL语句 虽然比较多，但数量也是有限的。如果 大部分SQL语句没有使用绑定变量或存储过程和包中使用大量动态SQL这 不论在单实例或RAC环境下都产大问题。

    2、资源被修改的频率很少：可以相一下生产系统第天会有多少次机会执行Alter table这种DDL操作。一般也是应用程序升级才执行一次。

    因为资源有 这些特点，ORACLE采用了于广播的机制。第个节点上的变化都马上通知所有节点。

    Cache Fusion 资源

     和Share Pool的资源比起来，Buffer Cache的数据块数量更多，修改更加密集。如果每次数据块修改都在集群内广播，这种方式比较消耗资源，也不 一定高效。因 此对于数据块这种资源，RAC采用的是Cache Fusion机制，使用PCM Lock。PCM Lock有3种模式：Shared、Exlusive、Null，RAC用 数据块状态(buffer State) 来描述 数据块上的锁类型 。二者的关系如下

    PCM Lock Mode            Buffer State                             说明

            X                                 XCUR         数据块上的锁是X模式且是最新 版本 current

            S                                 SCUR         数据块上的锁是S模式且是最新版本

           NULL                              CR           实例对数据块没有加任何模式的PCM锁

实例在读取数据块时加的锁是S模式的，数据块的状态是SCUR。某个实例要修改数据块时必须获取这个数据块的X锁，因为X和S模式不相容，其它实例必须 放弃这个数据块的S锁进入NULL状态。 数据 块的状态由GRD Global Resource Directory实现。它记录了数据块 在集群间的分布。每个实例的SGA中都有GRD，但都是部分的GRD，所有实例的GRD汇总在一 起就是 完整的GRD。

    RAC会根据每个资源的名称从集群中选择一个节点作 为它的Master Node，而其它 节点叫做Shadow Node。Master Node的GRD记录了该资源在所有节点上的使用信息，而Shadow Node只记录该资源在本节点的使用信息。

   GRD中记录的是数据块地址Data Block Address和PCM Lock信息，这种锁有三个属性：Mode、Role、PI。

   Mode属性用于模式锁的模式，有三种分别是

   （1）Exclusive（X）持有这种锁的实例可以对这个数据块进行修改。集群中同一时刻只有一个实例能获得X锁 。获得数据块的X锁后能否进行修改还要看记录上的行级锁，这和单实例 的机制是一样的。

   （2）Share(S) 拥有这个模式的锁 的实例可以对数据 块进行只读操作，基它实例不能获得 该数据块的X锁 。可以同时多个实例获 得同一数据块的S锁。

   （3）Null 这个模式代表对应的内存空间可以被重用。在没重用这前，实例不能访问该块的数据。

    Role属性有二种值Local和Global，Local 表示只有本节点对数据块做了修改，如果要将脏数据写入磁盘，不需 要联系GRD，本实例可直接写。Global表示多个实例拥有和磁盘不一样的版本，想要把这个数据块写入磁盘，必须联系GRD，由拥有数据 块当前版本的实例完成写入。

   Past Image代表这个实例拥有和磁盘不一样的版本。数据块被别的实例 修改，本实例上的数据块不是最新的。如果别的实例写入 这个数据块会通知其它实例释放该数据块的PI版本，如果别的实例挂了，这时就会 触 发 拥有PI版本的实例进行Crash Recovery,用崩溃节点写入的Redo Log完成恢复 。将redo 应用在PI上 ，得到一致的版本。

   Cache Fusion 缓存融合， 通过GRD，PCM LOCK,和全局队列来保证在各个实例间一致地读取和修改数据块。

     集群中 每个 实例的SGA中都只有部分GRD的内容， 有节点合在一起才构成完成的GRD。RAC实例比单实例多了以下特有进程。

（1）LMSn： 该进程负责数据块地实例间的传递，对应的服务叫Clobal Cache service

该进程的数量通过GCS_SERVER_PROCESSES来控制，默认有2个，取值范围1~9。

（2）LMD：这个提供负责的是Global Enqueue Service(GES)。具体就是负责在多个实例之间协调对数据块的访问顺序，来保证数据的一致性访问。

（3）LCK：这个进程负责Non-Cache Fusion的资源的同步访问， 每个实例有一个LCK进程。

（4）LMON：各个实例的LMON进程会定期通信，以检查集群中各节点的健康状态，当某个节点出现故障时， 负责集群 重构。它提供的服务叫Cluster Group Service（CGS），ORACLE Clusterware使用Process Monitor Daemon解决脑裂的方法，如果某节点上的实例异常挂起，如果单从Network、OS、Clusterware几个层面 看，可能检测不到这种异常。因此数据库必须有自我监控的机制。LMON进程提供了节点监控 （Node Montor）功能。这个功能是用 来记录应用层各个节点的健康状态，节点的健康状态通过GRD中的一个位图bitmap记录， 每个节点一位，0代表关闭，1代表正常运行，各节点的LMON互相通信，确认这个位图的一致性。

    LMON可以和下层的Clusterware合作也可以 单独工作。当LMON检测到实例级别的脑裂时，期待借助于Clusterware解决脑裂，但RAC并不假设Clusterware 肯定能解决问题 ，因此LMON不会无尽等待Clusterware层的处理结果，当等待超时LMON进程会自动触发IMR（Instance Membership Recovery）IMR可以看做是ORACLE在数据库层提供的脑裂、IO隔离机制。

    LMON主要借助两种心跳来完成健康监测：

    1、节点间的心跳

    2、控制文件的磁盘心跳， 每个实例的CKPT进程 每3秒更新一次控制文件的Checkpoint Progress Record数据块，控制文件是 共享的，因此实例可以互相检测对方是否及时更新以判断状态。

（5）DIAG：该进程监控实例的健康状态，关在实例出现运行错误时收集诊断数据记录在Alert.log日 志中。

（6）GSD：Global Service Daemon 这个进程负责从客户端工具比如srvctl接收命令，为用户提供管理接口。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/9683969/viewspace-676040/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/9683969/viewspace-676040/