（转）RAC下的并发控制1

 

RAC下的并发控制
    对于RAC的初学者来说，很容易被HA、LB、Cache Fusion这些光鲜的外衣所迷惑，而忽略了其最朴素的本质。RAC的本质上是一个数据库，它的主要任务也是数据库的主要任务--------事务处理。因此从并发和锁这个侧面入手，对RAC抽丝剥茧。
    在开始理论学习之前，先暂时抛弃那些拗口的术语，简单描述一下集群环境和单机环境相比会有哪些新问题，明白这些问题之后再来讨论RAC就顺理成章了。
    首先，RAC是一个数据库，这一点毋庸置疑。既然是数据库，它就必须要解决并发问题。它也是通过锁，每个进程在访问修改数据之前，都必须先对数据加锁。使用锁机制既保护了自己的访问不会被别人破坏，也不会去破坏别人的访问。
    其次，RAC是运行在多台计算机的数据库。运行平台从单台计算机扩展成多台计算机，相应的原来单台计算机上多个进程间的并发，现在被扩大成多台计算机上的进程并发。原先在单实例中，一个进程是否可以修改一条数据，取决于是否有其他进程(同一台计算机上)并发修改。在RAC环境下，这种判断已经不够了，还必须检查其他计算机上的进程是否有并发修改。
    于是产生了RAC要解决的第一个问题：如何在多台计算机环境下感知并发的存在?对于检查本机上的并发，用传统的单实例中的锁机制就可以解决，没有必要重复地发明轮子。但是对于其他计算机上的并发检测，必须引入一个新的机制，这个机制就是分布式锁管理器(Distributed Lock：Management，DLM)。可以把DLM想象成一个“仲裁”，它记录着哪个节点正在用哪种方式操作哪个数据，并负责协调解决节点问的竞争。
用一个例子说明DLM的作用：
    (1)一个2节点的RAC；
    (2)节点1想要修改数据1；
    (3)节点1向DLM请求，DLM发现数据l还没有被任何节点使用，DLM就授权给节点1；并且DLM登记节点1对数据1的使用；
    (4)节点2也想修改数据1；
    (5)节点2向DLM请求，DLM发现数据1被节点1使用，DLM就会请求节点1“先给节点2用吧”，节点1接到请求后释放其对数据1的占用，节点2能够操作数据1；
    (6)DLM记录这个过程。
    需要强调的是DLM负责的是节点间的协调，而节点内的协调不是DLM负责。继续上面这个例子：
    (1)现在节点2的进程l修改数据1；
    (2)节点2的进程2也想修改数据l；
    (3)节点2仍然请求DLM，DLM发现节点2现在已经有权限，无须授权；
    (4)进程2对DLM的请求被通过，但是进程2是否能够修改数据l，还需要进一步检查；
    (5)通过传统的锁模式，比如“行级锁”，进程2发现数据1正被进程1修改，所以进程2只能等待。
    用DLM解决了第一个问题后，很快第二个问题就来了，如何定义资源的粒度?所谓资源粒度就DLM是在哪个层次上对资源冲突进行协调?是在每条数据记录级别?还是在数据文件级别?还是在数据块级别?Oracle RAC选择的是以数据块作为粒度单位。也就是说，进程想要修改记录1时，向DLM提出的申请是“数据块1的操作权限”，而不是“记录1的操作权限”。选择数据块作粒度也是从性能方面权衡的结果。
    到这里，RAC和传统单实例的区别应该很清晰了。RAC比单实例多的就是分布式锁管理器(DLM)。DLM的作用就是协调实例间对资源的竞争访问，而实例内部的竞争RAC和单实例没有任何区别。所以学习RAC就是学习DLM。
    Oracle的集群发展历史分为两个阶段，最初的是Oracle并行服务器(Oracle Parallel Server，OPS)，第二个阶段是从Oracle 9开始的Oracle真正应用集群(Real Application Cluster，RAC)。两个阶段中的DLM名称也不同，OPS的叫作PCM，RAC的叫作Cache Fusion，每个版本中术语变化很大，但不管术语怎么变化，其机制都是类似的。

DLM中资源和锁
    DLM协调集群各节点对资源使用的功能就叫作同步。所有的资源访问都是需要同步。集群间的同步功能是一把“双刃剑”。保护数据一致性是它有利的一面，但是反过来这种同步也影响了集群的性能。如果集群同步活动非常密集，那么对集群性能的影响将是非常巨大的。因此，要想实现集群环境的理想性能，最关键的要素就是如何在节点间分配资源和协调任务，把节点间的同步活动降到最低但又正好满足需要。
    同步活动的数量取决于资源的数量和资源上活动的密集程度，并发活动少，需要进行的同步就少，如果并发活动密集，需要的同步活动也会“水涨船高”。
    在DLM中，也正是根据资源数量、活动密集程度这些特点，把资源分成了两种两类。分别叫作PCMResource、Non-PCMResource(PCM是OPs时代的术语，在9i的RAC中，很多资料还是沿用这个叫法。不过在一些较新的10g RAC资料中，出现了Cache Fusion Resource和Non-Cache Fusion Resource这两种分类方式，换汤不换药)。Cache Fusion Resource特指数据块这种资源，包括普通数据块、索引数据块、段头块(Segment Header)、Undo数据块。非数据块资源全部都归类为Non-Cache Fusion Resource，包括数据文件、控制文件、数据字典视图、Library Cache、Row Cache等。
    对应两种资源，DLM提供的锁也分成两种，PCM Lock和Non-PCM Lock。加上之前介绍的Lock和Latch，在RAC数据库中共有两大类4种锁。
Local Lock(本地锁)：这种锁用于本地进程间的并发控制，也就是传统单实例中的锁机制。Local Lock可以分成两种Latch和Lock。
Global Lock(全局锁)：这种锁用于集群间的并发控制，也是接下来要学习的。GlobalLock可以分成PCM Lock和Non-PCM Lock两类。
    Global Lock是由Oracle的后台进程使用的，这一点和Local Lock不同，Local Lock是由用户进程和后台进程使用的。

Non-Cache Fusion资源
    典型的Non-Cache Fusion资源包括Share Pool的Row Cache和Library Cache内容。以Library Cache为例，这个Cache中存放的是所有SOL语句、执行计划、包等对象，以及这些对象所引用的对象。当一个语句或包编译时，这个语句引用的所有对象都会加一个Library Catch Lock；而执行时，所有这些引用对象都要被加一个Library Cache Pin，以保证在语句执行过程中，应用对象的结构不会被修改。
    编译完成后，加在引用对象上的Library Catch Lock会由原来的Share或Exclusive模式变成Null模式。Null模式的Library Cache Lock相当于一个触发器，当这些对象的定义被修改时，引用它的对象将被置为无效状态，必须重新编译。比如“select * from a”编译之后，这个语句的执行计划对象会在a上加一个Null模式的Library Cache Lock，这个Null模式的Lock相当于一个触发器，以后如果对表a的结构做了修改，比如增加一个字段，这个触发器就会导致“select * from a”这个语句的执行计划失效。如果再次执行这个语句，旧的执行计划就不能再被使用，必须重新编译产生新的执行计划。
    在RAC环境下，这个问题进一步延伸。现在每个节点都可能有表a的引用对象。无论在任何一个节点上对a结构进行修改，都需要把所有节点上的引用a的对象置为失效。因此除了传统的Library Cache Lock之外，每个节点上的LCK0进程，会对本实例Library Cache中的对象加一个Shared-mode的IV(Invalidation) Instance Lock，如果某个用户想要修改对象定义，必须获得一个Exclusive模式的Iv锁，这会通知本地的LCK0释放Shared—mode锁，本地LCK0在释放这个锁之前，会通知其他节点上的LCK0，其他节点的LCK0收到这个消息后，就会将本地Library Cache中的所有相关对象置为失效，这种机制是一种广播机制。这些通信过程是通过实例的LMD进程完成的。
    Row Cache中存放的是数据字典，其目的是编译过程减少对磁盘的访问。其内容也需要在所有实例中同步，其同步机制和Library Cache是一样的，也是由LCK0进程完成。
    可以看出，Non-Cache Fusion资源有如下特点。
    ◇资源数量有限：比如Row Cache中存放的是对象定义，Library Cache中存放的SQL
    代码、执行计划等，在一个稳定的生产系统中，表、视图、存储过程、包的数量是有
    限的，SQL语句数量虽然更多些，但是数量也是有限的。
    ◇资源被修改的频率很少：可以想一下生产系统每天会有多少次机会执行Alter Table
    这种DDL操作，一般也就是应用程序升级时才执行一次。
    因为这些资源有这些特点，Oracle采用了类似于广播的机制，每个节点上的变化都通知给所有节点。这种策略比下面介绍的Cache Fusion资源的实时检查更加高

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

转载于:http://blog.itpub.net/14272606/viewspace-705575/