达梦共享集群DM DMDSC集群对比Oracle RAC原理详解

最新推荐文章于 2024-03-17 00:02:46 发布

羽书飞影

最新推荐文章于 2024-03-17 00:02:46 发布

阅读量2.9k

点赞数 3

分类专栏：达梦数据库文章标签： database 数据库

本文链接：https://blog.csdn.net/weixin_42018955/article/details/123481616

版权

达梦数据库专栏收录该内容

42 篇文章 25 订阅

订阅专栏

在众多关系型DBMS中，基于共享集群多实例共享一个库的这种模型下，众多关系型数据库中DMDSC与 OracleRAC是最为相似的，我实在找不出第二个更相似的这种机制了，所以为了更方便学习理解DMDSC，对比着Oracle RAC来学习更方便快捷理解。

一、什么是共享集群

1、什么是达梦DMDSC ？

DM 共享存储数据库集群的英文全称 DM Data Shared Cluster，简称 (DMDSC)。DMDSC 允许多个数据库实例同时访问、操作同一数据库，具有高可用、高性能、负载均衡等特性。并支持故障自动切换和故障自动重加入，某一个数据库实例故障后，不会导致数据库服务无法提供。

DMDSC 集群是一个多实例、单数据库的系统。多个数据库实例可以同时访问、修改同一个数据库的数据。用户可以登录集群中的任意一个数据库实例，获得完整的数据库服务。数据文件、控制文件在集群系统中只有一份，不论有几个节点，这些节点都平等地使用这些文件，这些文件保存在共享存储上，各个节点有自己独立的联机日志和归档日志。
DMDSC 集群得以实现的重要基础就是共享存储。DM 支持的共享存储有两种：裸设备和 DMASM。这两种存储的区别在于后者在前者的基础上，部署并使用了 DMASM 文件系统。为了方便对裸设备上的磁盘或文件进行管理，推荐用户使用后者 (DMASM)。
DMDSC 集群主要由数据库和数据库实例、共享存储、本地存储、通信网络、以及集群控制软件 DMCSS 组成。以部署了 DMASM 的 DMDSC 集群为例，展示 DMDSC 集群系统结构，如下图所示：

DMDSC 主要特点包括：

高可用性：只要集群中有一个活动节点,就能正常提供数据库服务。
高吞吐量：多个节点同时提供数据库服务，有效提升集群的整体事务处理能力。
负载均衡：用户的连接请求被平均分配到集群中的各个节点，确保各个节点的负载大致平衡。

2、什么是Oracle RAC？

Oracle RAC 运行于集群之上，为 Oracle 数据库提供了最高级别的可用性、可伸缩性和低成本计算能力。如果集群内的一个节点发生故障，Oracle 将可以继续在其余的节点上运行。Oracle 的主要创新是一项称为高速缓存合并的技术。高速缓存合并使得集群中的节点可以通过高速集群互联高效地同步其内存高速缓存，从而最大限度地低降低磁盘 I/O。高速缓存最重要的优势在于它能够使集群中所有节点的磁盘共享对所有数据的访问。数据无需在节点间进行分区。Oracle 是唯一提供具备这一能力的开放系统数据库的厂商。其它声称可以运行在集群上的数据库软件需要对数据库数据进行分区，显得不切实际。企业网格是未来的数据中心，构建于由标准化商用组件构成的大型配置之上，其中包括：处理器、网络和存储器。Oracle RAC 的高速缓存合并技术提供了最高等级的可用性和可伸缩性。Oracle 数据库 10g 和 OracleRAC 10g 显著降低了运营成本，增强了灵活性，从而赋予了系统更卓越的适应性、前瞻性和灵活性。动态提供节点、存储器、CPU 和内存可以在实现所需服务级别的同时，通过提高的利用率不断降低成本。

Oracle RAC的核心是共享磁盘子系统，集群中所有节点必须能够访问所有数据、重做日志文件、控制文件和参数文件，数据磁盘必须是全局可用的，允许所有节点访问数据库，每个节点有它自己的重做日志和控制文件，但是其他节点必须能够访问它们以便在那个节点出现系统故障时能够恢复。展示 RAC 集群系统结构，如下图所示：

RAC的特点：

除了具有普通的数据库特性外：

每一个节点的instance都有自己的SGA
每一个节点的instance都有自己的background process
每一个节点的instance都有自己的redo logs
每一个节点的instance都有自己的undo表空间
每一个节点的实例都有自己的SGA，但是之间在SGA里面的数据块都是需要相互传递的。
每一个节点都有自己的redo,redo不是共用的。虽然redo是放在共享磁盘上面，但是每个实例都有自己的redo，各有各的。当实例2坏了，实例1做恢复的时候可以通过实例2的redo信息来进行恢复。

每个实例都要处理自己的一套事务，所以需要使用自己的UNDO。

二、包含的集群组件介绍：

1、DMDSC进程介绍

DMCSS（对标Oracle osccd进程即cssd服务，集群注册服务）

DMCSS (Dameng Cluster Synchronization Services) DM 集群同步服务，使用 DMASM 集群或 DMDSC 集群都必须要配置 DMCSS 服务。在 DMASM 集群或 DMDSC 集群中，每个节点都需要配置一个 DMCSS 服务。这些 DMCSS 服务自身也构成一个集群，DMCSS集群中负责监控、管理整个 DMASM 集群和 DMDSC 集群的节点称为控制节点 (controlnode)，其他 DMCSS 节点称为普通节点 (normal node)。DMCSS 普通节点不参与 DMASM 集群和 DMDSC 集群管理，当 DMCSS 控制节点故障时，会从活动的普通节点中重新选取一个 DMCSS 控制节点。

DMCSS 工作的基本原理是：在 Voting disk 中，为每个被监控对象 (dmasmsvr、dmserver、DMCSS) 分配一片独立的存储区域，被监控对象定时向 Voting Disk 写入信息（包括时间戳、状态、命令、以及命令执行结果等）；DMCSS 控制节点定时从 Voting Disk 读取信息，检查被监控对象的状态变化，启动相应的处理流程；被监控对象只会被动的接收 DMCSS 控制节点命令，执行并响应。

DMCSS 主要功能包括：写入心跳信息、选取 DMCSS 控制节点、选取 DMASM/DMDSC 控制节点、管理被监控对象的启动流程、集群状态监控、节点故障处理、节点重加入等，DMCSS 还可以接收并执行 DMCSSM 指令。

DMASM（对标Oracle +ASM进程即ASM服务进程）

DMASM (DM Auto Storage Manager) 是一个专用的分布式文件系统，使用 DMASM 自动存储管理方案，可以帮助用户更加便捷地管理 DMDSC 集群的数据库文件。DMASM 的主要部件包括：提供存储服务的裸设备、dmasmsvr 服务器、dmasmapi 接口、初始化工具 dmasmcmd 和管理工具 dmasmtool 等。

DMDSC 集群可以直接使用裸设备作为共享存储，存放数据库文件。但是，由于裸设备存在的一些功能限制，造成 DMDSC 集群在使用、维护上并不是那么灵活、方便。裸设备的使用限制如下：

不支持动态扩展文件大小；在创建数据文件时，就必须指定文件大小，并且文件无法动态扩展。
数据文件必须占用整个裸设备盘，造成空间浪费。
不支持类 Linux 的文件操作命令，使用不方便。
操作系统支持最大裸设备数目较小，无法创建足够的数据库文件。

为了克服裸设备的这些使用限制，DM 专门设计了一个分布式文件系统 DMASM，来管理裸设备的磁盘和文件。DMASM 提供了基本的数据文件访问接口，可以有效降低 DMDSC 共享存储的维护难度。

DMCSSM（对标Oracle +ASM进程即ASMM服务，共享存储管理进程）

DM Cluster Synchronization Services Monitor，DM集群监视器，DMCSSM与DMCSS相互通信，获取并监控整个集群系统的状态信息。DMCSSM还提供了一系列的命令来管理、维护集群。同一个集群中，允许最多同时启动10个监视器，一般建议将监视器放在独立的第三方机器上。

DCR（对标Oracle OCR服务，在Oracle由ocssd进程管理，没有单独的进程）

DM Clusterware Registry，DCR是DM集群注册表的简称，用于存储、维护集群配置的详细信息，整个集群环境共享DCR配置信息，包括DMDSC、DMASM、DMCSS资源，包括实例名、监听端口、集群中故障节点信息等。DCR必须存储在集群中所有节点都可以访问到的共享存储中，并且只支持裸设备。在一个集群环境中只能配置一个DCR磁盘。

Voting Disk，表决磁盘记录了集群成员信息，DM集群通过Voting Disk进行心跳检测，确定集群中节点的状态，判断节点是否出现故障。当集群中出现网络故障时，使用Voting Disk来确定哪些DMDSC节点应该被踢出集群。表决磁盘还用来传递命令，在集群的不同状态（启动、节点故障、节点重加入等）DMCSS通过Voting Disk传递控制命令，通知节点执行相应命令。Voting Disk必须存储在集群中所有节点都可以访问到的共享存储中，并且只支持裸设备。在一个集群环境中只能配置一个表决磁盘。
集群中各实例启动时，通过访问DCR获取集群配置信息。被监控实例从Voting Disk读取监控命令，并向Voting Disk写入命令响应以及自身心跳信息；DMCSS也向Voting Disk写入自己的心跳信息，并从Voting Disk访问各被监控节点的运行情况，并将监控命令写入Voting Disk，供被监控实例访问执行。

MAL（对标Oracle EVMD 进程，除了复杂发布事件之外，它还是CRSD 和CSSD 两个进程之间的桥梁。）

MAL系统是达梦数据库基于TCP协议实现的一种内部通信机制，具有可靠、灵活、高效的特性。使用DMASM文件系统的DMDSC集群中存在两套MAL系统，DMASM服务器之间配置一套MAL系统，dmserver服务器之间配置一套MAL系统。一旦MAL链路出现异常，DMCSS会进行裁定，并从集群中踢出一个节点，保证集群环境正常运行。

2、Oracle RAC 进程介绍

OHAS

        Oracle高可用服务 (OHAS) OHAS是服务器启动后打开的第一个Grid Infrastructure组件。它被配置为以init(1)打开，并负责生成agent进程。
        Oracle Agent Grid Infrastructure使用两个oracle代理进程。第一个，概括起来说，负责打开一些需要访问OCR和VOTING文件的资源。它由OHAS创建。
        第二个代理进程由CRSD创建，负责打开所有不需要root权限来访问的资源。这个进程以Grid Infrastructure所属用户的权限运行，并且负责在RAC11.1中racg所做的工作。

OCSSD

OCSSD 这个进程是Clusterware最关键的进程，如果这个进程出现异常，会导致系统重启，这个进程提供CSS(Cluster Synchronization Service)服务。 CSS 服务通过多种心跳机制实时监控集群状态，提供脑裂保护等基础集群服务功能。

CSS 服务有2种心跳机制：一种是通过私有网络的Network Heartbeat，另一种是通过Voting Disk的Disk Heartbeat。这2种心跳都有最大延时，对于Disk Heartbeat，这个延时叫作IOT (I/O Timeout);对于Network Heartbeat, 这个延时叫MC(Misscount)。这2个参数都以秒为单位，缺省时IOT大于MC，在默认情况下，这2个参数是Oracle 自动判定的，并且不建议调整。可以通过如下命令来查看参数值：

$crsctl get css disktimeout

$crsctl get css misscount

CRSD

CRSD是实现"高可用性(HA)"的主要进程，它提供的服务叫CRS(Cluster Ready Service) 服务。

EVMD

EVMD 这个进程负责发布CRS 产生的各种事件(Event). 这些Event可以通过2种方式发布给客户：ONS 和 Callout Script. 用户可以自定义回调脚本，放在特定的目录下，这样当有某些事件发生时，EVMD会自动扫描该目录，并调用用户的脚本，这种调用是通过racgevt进程来完成的。

EVMD 进程除了复杂发布事件之外，它还是CRSD 和CSSD 两个进程之间的桥梁。 CRS 和CSS 两个服务之前的通信就是通过EVMD 进程完成的。

RACGIMON

RACGIMON 这个进程负责检查数据库健康状态，负责Service的启动，停止，故障转移(Failover)。这个进程会建立到数据库的持久连接，定期检查SGA中的特定信息，该信息由PMON 进程定时更新。

OPROCD

OPROCD 这个进程也叫作 Process Monitor Daemon. 如果在非Linux 平台上，并且没有使用第三方的集群软件时，就会看到这个进程。这个进程用来检查节点的Processor Hang(CPU 挂起), 如果调度时间超过1.5秒，就会认为CPU 工作异常，会重启节点。也就是说这个进程提供 "IO 隔离" 的功能。从其在Windows 平台上的服务名： OraFnceService 也可以看出它的功能。而在Linux 平台上，是利用Hangcheck-timer 模块来实现"IO 隔离"的。

ONS

Oracle警告服务。

二、工作原理：

1、DMDSC实现原理

DMDSC的工作原理根据达梦官方文档，主从围绕几方面进行了阐述，首先集群架构多节点共享一个库，那么首先想到的是事务是如何进行的，多个节点共写一个库，那么事务的一致性又是如何保障一致性的呢？下边围绕事务处理机制、全局处理机制、redo和undo几方面，对DMDSC集群的工作原理进行简单的阐述，详细可以参考官方文档。

事务管理（MVCC多版本并发控制技术，大多关系型数据库都是这种机制吧）

达梦mvcc是在表对象每一条物理记录中包含了两个字段：TID和RPTR。TID保存修改记录的事务号，RPTR保存回滚段中上一个版本回滚记录的物理地址。插入、删除和更新物理记录时，RPTR指向操作生成的回滚记录的物理地址。回滚记录与物理记录一样，也包含了TID和RPTR这两个字段。TID保存产生回滚记录时物理记录上的TID值（也就是上一个版本的事务号），RPTR保存回滚段中上一个版本回滚记录的物理地址。

物理记录TID等于当前事务号，说明是本事务修改的物理记录，物理记录可见
物理记录TID不在活动事务表中，并且TID小于NEXT_TID，物理记录可见
物理记录的TID包含在活动事务表中，或者TID>=NEXT_TID，物理记录不可见

封锁管理（全局锁和本地锁机制）

DM则采用了独特的封锁机制，使用TID锁和对象锁进行并发访问控制，有效减少封锁冲突、提升系统并发性能。

TID锁以事务号为封锁对象，每个事务启动时，自动以独占（X）方式对当前事务号进行封锁，由于事务号是全局唯一的，因此这把TID锁不存在冲突，总是可以封锁成功。同时，在4.1事务管理中，介绍了物理记录上包含一个TID字段，记录了修改数据的事务号。执行INSERT、DELETE、UPDATE操作修改物理记录时，设置事务号到TID字段的动作，就相当于隐式地对物理记录上了一把X方式的TID锁。因此，通过事务启动时创建的TID锁，以及写入物理记录的TID值，DM中所有修改物理记录的操作都不再需要额外的行锁，避免了大量行锁对系统资源的消耗，有效减少封锁冲突。特别是在DMDSC集群中，需要进行全局封锁，封锁的代价比单节点更高，通过TID锁可以有效减少封锁引发的性能损失。

DMDSC集群将封锁管理拆分为全局封锁服务（Global Locking Services，简称GLS）和本地封锁服务（Local Locking Services，简称LLS）两部分。整个系统中，只有控制节点拥有一个GLS。控制节点的GLS统一处理集群中所有节点的封锁请求、维护全局封锁信息、进行死锁检测，确保事务并发访问的正确性。每个节点都有一个LLS。各节点的LLS负责与GLS协调、通讯，完成事务的封锁请求，DMDSC集群中所有封锁请求都需要通过LLS向GLS发起，并在获得GLS授权后，才能进行后续操作。

闩管理（全局和本地缓存buffer竞争机制）

闩（Latch）是数据库管理系统的一种内部数据结构，通常用来协调、管理Buffer缓冲区、字典缓存和数据库文件等资源的并发访问。与锁（Lock）在事务生命周期中一直保持不同，闩（Latch）通常只保持极短的一段时间，比如修改Buffer中数据页内容后，马上会释放。闩（Latch）的封锁类型也比较简单，就是共享（Share）和独占（Exclusive）两种类型。

为了适用DMDSC集群，我们同样将闩划分为全局闩服务（Global Latch Services）和本地闩服务（Local Latch Services）两个部分。但是，为了与全局封锁服务GLS和本地封锁服务LLS的名字简称区分开来，我们以使用最为频繁的Buffer来命名全局闩服务。因此，全局闩服务也称为全局缓冲区服务（Global Buffer Services），简称GBS；本地闩服务也称为本地缓冲区服务（Local Buffer Services），简称LBS。

整个系统中，每一个节点上都部署一个GBS和一个LBS。GBS服务协调节点间的Latch封锁请求、以及Latch权限回收。GBS与GTV/GLS由控制节点统一管理不同，GBS不是集中式管理，而是由DMDSC集群中的所有节点共同管理，Buffer对象会根据数据页号（Page No）对数据页进行划分，分给某一个节点的GBS服务处理。LBS服务与LLS/LTV一样，部署在每一个节点，LBS服务根据用户请求，向GBS发起Latch封锁，或者根据GBS请求，回收本地的Latch封锁。

为了避免两个、或多个节点同时修改同一个数据页，导致数据损坏，或者数据页修改过程中，别的节点读取到无效内容，DMDSC集群中数据页的封锁流程产生一定变化，与单节点相比，增加了全局Latch封锁、释放两个步骤。并且，在获取全局Latch授权后，仍然需要进行正常的本地Latch封锁，避免节点内访问冲突。

缓存交换

DMDSC集群引入了缓存交换（Buffer Swap）技术，节点间的数据页尽可能通过网络传递，避免通过磁盘的写入、再读出方式在节点间传递数据，从而减少数据库的IO等待时间，提升系统的响应速度。

缓存交换的实现基础是GBS/LBS服务，在GBS/LBS中维护了Buffer数据页的相关信息。包括：1. 闩的封锁权限（LATCH）；2. 哪些站点访问过此数据页（Access MAP）；3. 最新数据保存在哪一个节点（Fresh EP）中；4. 以及最新数据页的LSN值（Fresh LSN）等信息。这些信息作为LBS封锁、GBS授权和GBS权限回收请求的附加信息进行传递，因此并不会带来额外的通讯开销。

场景1

节点EP0访问数据页P1。

节点EP0的本地LBS向EP1的GBS请求数据页P1的S LATCH权限
节点EP1的GBS修改P1控制结构，记录访问节点EP0的封锁模式为S LATCH（数据分布节点为EP0），并响应EP0的LBS请求
节点EP0的LBS获得GBS授权后，记录获得的授权模式是S_LATCH，P1数据不在其他节点的Buffer中，发起本地IO请求，从磁盘读取数据。IO完成后，修改LBS控制结构，记录数据页上的LSN信息。

2.场景2

节点EP1访问数据页P1。

节点EP1本地LBS向EP1的GBS请求数据页P1的S LATCH权限
节点EP1的GBS修改控制结构，记录访问节点EP1的封锁模式为S LATCH（数据分布节点为EP0/EP1），并响应EP1的LBS请求
节点EP1的LBS获得GBS授权后，记录获得的授权模式是S LATCH，根据数据分布情况，EP1向EP0发起P1的读请求，通过内部网络从EP0获取数据，而不是重新从磁盘读取P1数据。

3.场景3

节点EP0修改数据页P1。

节点EP0本地LBS向EP1的GBS请求数据页P1的X LATCH权限（附加LSN信息）
节点EP1的GBS修改控制结构的LSN值，从EP1的LBS回收P1的权限
修改访问节点EP0的封锁模式为S + X LATCH，并响应EP0的LBS请求
节点EP0的LBS获得GBS授权后，记录获得的授权模式是S + X LATCH
节点EP0修改数据页P1，LSN修改为11000

这个过程中，只有全局Latch请求，数据页并没有在节点间传递。

4.场景4

节点EP1修改数据页P1。

1.节点EP1本地LBS向EP1的GBS请求数据页P1的X LATCH权限

2.节点EP1的GBS发现P1被EP0以S + X方式封锁，向EP0发起回收P1权限的请求

3.节点EP0释放P1的全局LATCH，响应GBS，并且在响应消息中附加了最新的PAGE LSN值

4.节点EP1的GBS收到EP0的响应后，修改GBS控制结构，记录最新数据保存在EP0，最新的LSN值信息，记录EP1获得的授权模式是S + X LATCH（此时，数据分布节点仍然是EP0/EP1），并授权EP1的LBS

5.节点EP1的LBS收到授权信息后，记录获得的授权模式是S + X LATCH，并根据数据分布情况，向节点EP0发起数据页P1的读请求

6.节点EP1修改数据页P1，LSN修改为12000。

redo log管理机制

DMDSC集群中，各个节点拥有独立的日志文件，Redo日志的LSN值也是顺序递增的，Redo日志只会写入当前数据库实例的联机日志文件，与集群系统中的其他数据库实例没有关系。考虑到所有节点都可以修改数据，同一个数据页可能由不同节点先后修改，为了体现修改的先后顺序，确保故障恢复时能够按照操作的顺序将数据正确恢复。DMDSC集群要求对同一个数据页的修改，产生的LSN值是全局递增的，各个节点对同一数据页的修改在日志系统中是严格有序的。但是，针对不同数据页的修改并不要求LSN是全局递增的，也就是说只有多个节点修改相同数据页时，才会产生全局LSN同步问题。并且LSN全局同步，是在缓存交换时附带完成的，并不会增加系统的额外开销。

undo log管理机制

DMDSC集群的多版本并发控制（MVCC）实现策略是，通过回滚记录获取数据的历史版本，通过活动事务视图判断事务可见性、确定获取指定版本数据。因此，回滚记录也必须进行全局维护，有可能在节点间进行传递。与单节点一样，DMDSC集群中只有一个回滚表空间，回滚记录保存在回滚页中，回滚页与保存用户记录的数据页一样，由Buffer系统管理，并通过缓存交换机制实现全局数据共享。

为了减少并发冲突，提高系统性能，DMDSC集群中为每个节点分配了一个单独的回滚段（Segment），虽然这些回滚段位于同一个回滚表空间中，但是各个节点的回滚页申请、释放，并不会产生全局冲突。

与重做日志一样，DMDSC集群故障重启时，控制节点会扫描所有节点的回滚段，收集未提交事务进行回滚，收集已提交事务进行Purge操作。

2、Oracle RAC 实现原理

RAC软件存储原理

Oracle10g的RAC安装分为两个阶段。安装CRS和安装带有RAC组件的Database软件，并创建Cluster数据库。CRS软件使用的Oracle home必须不同于RAC软件使用的home。voting file和OCR file是不能被存储在ASM中的，因为它们必须在任何Oracle Instance启动前就可以被访问。且必须存储在共享的存储设备中。

voting file：其本质上是用于Cluster synchronization Services守护进程进行节点信息的监控。大小约为20MB；

Oracle Cluster Registry（OCR）文件：也是CRS关键的组成部分。用于维护在Cluster中高可用性组件的信息。例如，Cluster节点列表，Cluster数据库Instance到节点的映射和CRS应用资源的列表（如Services、虚拟内部链接协议地址等）。此文件是通过SRVCTL类似的管理工具自动维护的。其大小约100MB。

OCR的结构

Cluster的配置信息是在OCR中维护的。OCR依赖分布式的共享缓存结构用于优化关于Cluster知识库的查询。在Cluster中的每个节点都通过OCR进程访问OCR缓存在其内存中维护着一个副本。事实上在Cluster中，只有一个OCR进程对共享存储中的OCR进行读写操作。此进程负责刷新（refresh）其自己拥有的本地缓存以及Cluster中其他节点的OCR cache。对于涉及到Cluster知识库的访问，OCR客户端直接访问本地OCR进程。当客户端需要更新OCR时，它们将通过本地OCR进程与那个扮演读写OCR文件的进程进行交互。

OCR客户端应用有：Oracle通用安装器（OUI）、SRVCTL、企业管理器（EM）、DBCA、DBUA、NetCA和虚拟网络协议助理（VIPCA）。此外，OCR维护管理着CRS内部中定义的各种应用程序的资源的依赖和状态信息，特别是Database、Instance、Services和节点的应用程序。

配置文件的名字是ocr.loc，并且配置文件变量是ocrconfig_loc。Cluster 知识库的位置是不受限于裸设备的。可以将OCR放置在由Cluster file system管理的共享存储设备上。

note：OCR也可用于在ASM的单Instance中作为配置文件，每个节点有一个OCR。

RAC Database存储原理

与single-Instance Oracle的存储方式最主要的不同之处在于RAC存储必须将所有RAC中数据文件存放在共享设备中（裸设备或是Cluster文件系统）以便于访问相同Database的Instance能够共享。必须为每个Instance创建至少两个redo log组，并且所有的redo log组必须也存储在共享设备中，从而为了crash恢复的目的。每个Instance的在线redo log groups被称作一个Instance的在线redo 线程。

此外，必须为每个Instance创建一个共享的undo表空间用于Oracle推荐的undo自动管理特点。每个undo表空间必须是对所有Instance共享的，主要用于恢复的目的。

归档日志不能被存放在裸设备上，因为其命名是自动产生的，并且每个是不一致的。因此需要存储在一个文件系统中。如果使用Cluster file system（CFS），则可以在任何时间在任何node上访问这些归档文件。如果没有使用CFS，就不得不使其他Cluster成员在恢复时那些归档日志是可用的，例如通过网络文件系统（NFS）来实现。如果使用推荐的flash recovery area特性，则其必须被存储在共享目录下，以便于所有的Instance能够访问。（共享目录可以是一个ASM磁盘组，或是一个CFS）。

RAC和共享存储技术

存储是网格技术中的关键组成部分。传统上，存储都直接依附在每个Server（directly attached to each individual Server DAS）上。在过去的几年来，更灵活的存储出现并得到应用，主要是通过存储空间网络或是正规的以太网来实现访问。这些新的存储方式使得多个Servers访问相同的磁盘集合成为可能，在分布式环境中，可以获得简单的存取。

storage area network（SAN）代表了数据存储技术在这一点的演进。传统上，C/S系统中，数据被存储在Server内部或是依附它的设备中。随后，进入了network attached storage（NAS）阶段，这使得存储设备与Server和直接连接它们的网络向分离。它在SAN遵循的原则进一步允许存储设备存在于各自的网络中，并直接通过高速的媒介进行交换。用户可以通过Server系统对存储设备的数据进行访问，Server 系统与本地网络（LAN）和SAN相互连接。

文件系统的选择是RAC的关键。传统的文件系统不支持多系统的并行挂载。因此，必须将文件存储在没有任何文件系统的裸卷标或是支持多系统并发访问的文件系统中。因此，三个主要的方法用于RAC的共享存储有：

裸卷标：既是一些直接附加的裸设备，需要用于存储，并以block模式进程操作。
Cluster file system：也需要以block模式进程存取。一个或多个Cluster file 系统可以被用于存储所有的RAC文件。
自动存储管理（ASM）：对于Oracle Database files，ASM是一个轻便的、专用的、最佳化的Cluster file system。

Oracle Cluster file system

Oracle Cluster file system（OCFS）是一个共享文件系统，专门为Oracle RAC设计。OCFS排除了Oracle Database files被连接到逻辑磁盘上的需要，并使得所有的节点共享一个ORACLE Home，而不需每个node在本地有一个副本。OCFS卷标可以横跨一个或多共享disks，用于冗余和性能的增强。Oracle Cluster file system对开发人员和用户时免费的。可从官方网站下载。

可放入OCFS中的文件类表：

Oracle software的安装文件：在10g中，此设置只在windows 2000中支持。说是后面的版本会提供在Linux中的支持，但我还没具体看。
Oracle 文件（控制文件、数据文件、redo logs文件，bfiles等）
共享配置文件（spfile）
在Oracle运行期间，由Oracle创建的文件。
voting和OCR文件。

自动存储管理（ASM）

是10g的新特性。它提供了一个纵向的统一管理的文件系统和卷标管理器，专门用于建立Oracle Database 文件。ASM可以提供单个SMP机器的管理或是贯穿多个Oracle RAC的Cluster节点。

ASM无需再手动调节I/O，会自动的分配 I/O 负载到所有的可用资源中，从而优化性能。通过允许增加Database大小而不需shutdown数据库来调节存储分配，来辅助DBA管理动态数据库环境。

ASM可以维护数据的冗余备份，从而提高故障的容错。它也可以被安装到可靠的存储机制中。

选择RAW或CFS

CFS的优点：对于RAC的安装和管理非常简单；对RAC使用Oracle managed files（OMF）；single Oracle软件安装；在Oracle data files上可以自动扩展；当物理节点失败时，对归档日志的统一访问。

裸设备的使用：一般会用于CFS不可用或是不被Oracle支持的情况下；它提供了最好的性能，不需要在Oracle和磁盘之间的中间层；如果空间被耗尽，裸设备上的自动扩展将失败；ASM、逻辑存储管理器或是逻辑卷标管理器可以简化裸设备的工作，它们也允许加载空间到在线的裸设备上，可为裸设备创建名字，从而便于管理。

RAC的典型Cluster栈

在Cluster中的每个节点都需要一个被支持的相互连接的软件协议来支持内部Instance的交互，同时需要TCP/IP支持CRS的轮询。所有的UNIX平台在千兆以太网上使用user datagram protocol（UDP）作为主要的协议并进行RAC内部Instance 的IPC交互。其他支持的特有协议包括用于SCI和Sunfire的连接交互的远程共享内存协议和超文本协议，用于超光纤交互。在任何情况下，交互必须能被平台的Oracle所辨识。

使用Oracle clusterware，可以降低安装并支持并发症。但如果用户使用非以太交互，或开发了依赖clusterware的应用程序在RAC上，可能需要vendor clusterware。

同交互连接一样，共享存储方案必须被当前平台的Oracle所辨识。如果在目标平台上，CFS可用，Database area和flash recovery area都可以被创建到CFS或ASM上。如果在目标平台上，CFS不可用，则Database area可以创建在ASM或是裸设备上（需要卷标管理器）并且flash recovery area必须被创建在ASM中。

RAC certification Matrix

它设计用于处理任何认证问题。可以使用matrix回答任何RAC相关的认证问题。具体使用步骤如下：

连接并登陆 http://metalink.oracle.com
点击菜单栏的“certify and availability”按钮
点击“view certifications by product”连接
选择RAC
选择正确的平台

必要的全局资源

一个single-Instance环境，锁坐标通向一个共享的资源就像表中的一行。lock避免了两个进程同时修改相同的资源。

在RAC环境中，内部节点的同步是关键，因为它维持着不同节点中各自进程的一致性，避免其在同时修改相同的资源数据。内部节点的同步确保每个Instance看到buffer cache中block的最近的版本。下图中显示了当不存在加锁的情况。

a、全局资源的协调

cluster操作要求在所有Instance中对控制共享资源的访问进行同步。RAC使用Global Resource Directory来记录cluster Database中资源的使用信息。Global Cache Service（GCS）和Global Enqueue Service（GES）管理GRD中的信息。

每个Instance在其本地的SGA中维护GRD的一部分。GCS和GES指定一个Instance管理特殊资源的所有信息，它被称为资源的master。每个Instance都知道resource的Instance masters。

维护RAC的活动中的cache的依附性（cache coherency）是非常重要的。所谓cache coherency是保持在不同Oracle Instances中的多个block版本的一致性的技术。GCS通过所谓的cache融合算法来实现cache coherency。

GES管理所有非cache 融合算法的内部Instance资源操作和Oracle入队机制的状态轨迹。GES主要的控制的资源是字典cache locks和library cache locks。同时，它还对所有死锁敏感的队列和资源起到死锁检测的作用。

b、Global cache coordination实例

假设某data block被第一个节点修改，成为脏数据。并且在clusterwide中，只有一个block copy版本，其内容用SCN号代替了。则具体的步骤如下：

第二个Instance视图修改该block，向GCS提出请求。
GCS向block的holder（持有者）提交请求。在此，第一个Instance就是holder。
第一个Instance接到消息，并将block发送给第二个Instance。第一个Instance保存脏buffer用于恢复的目的。block的脏镜像被称作block的past image。一个past image block将不能进一步被改变。
收到block后，第二个Instance通知GCS，告知已经holds该block。

c、write to disk coordination：实例

在cluster结构中的Instances中的caches中，可能存在同一个block的不同的修改版本。由GCS管理的写协议确保了只有最近一个版本被写入磁盘中。它同时需要确保其他之前的版本从其他cache中被清洗。一个写磁盘的请求可以从任意一个Instance上发起，无论它是保存了block的当前版本还是过去的版本。假设第一个Instance hold过去的block镜像，请求Oracle将buffer写入磁盘，如上图，过程如下：

第一个Instance发送一个写请求给GCS
GCS将请求转给第二个Instance，当前该block的holder
第二个Instance接到写请求后将block写入磁盘
第二个Instance通知GCS，告知其写操作完成
当接到GCS接到通知后，GCS命令所有的过去的镜像的holders删除其过去的镜像。此镜像将不会在因恢复而需要。

RAC和Instance/crash recovery

a、当一个Instance失败，当该失败被其他Instance检测到，第二个Instance将会执行下面的恢复操作：

在恢复的第一阶段，GES重新灌入队列
GCS也重新灌入其资源。GCS进程只重新灌入那些失去其控制的资源。在这期间，所有的GCS资源请求和写请求都临时被挂起。然而，事务可以继续修改data blocks，只要这些事务已经获得了必要的资源。
当队列被重新配置后，一个活动的Instance可以获得占有该Instance恢复队列。因此，当GCS资源被重新灌入的同时，SMON确定需要被恢复的blocks的集合。这个集合被称作恢复集。因为，使用cache 融合算法，一个Instance传送这些blocks的内容到请求的Instance，而不需要将这些blocks写入磁盘。这些blocks在磁盘上的版本可能不包含其他Instance进程的data的修改操作的blocks。这意味着SMON需要合并所有失败的Instance的redo logs来确定恢复集。这是因为一个失败的线程可能导致一个在redo 中的hole（洞）需要用指定的block填补。所以失败的Instance的redo 线程不能被连续的应用。同时，活动的Instances的redo 线程不需恢复，因为SMON可以使用过去和当前的通信缓冲的镜像。
用于恢复的缓冲空间被分配，并且那些之前读取redo logs被辨识的资源被声明为恢复资源。这避免了其他Instance访问这些资源。
所有在随后的恢复操作中需要的资源被获得，并且GRD当前是不冻结的。任何不需恢复的data block现在可以被访问。所以当前系统是部分可用的。此时，假设有过去或当前的blocks镜像需要被恢复，而其在cluster Database中的其他caches中，对于这些特殊的blocks，最近的镜像是开始恢复点。如果对于要恢复的block，过去镜像和当前镜像缓冲都不在活动的Instance的caches中，则SMON将写入一个log，表明合并失败。SMON会对第三步中辨识的每个block进行恢复和写入，在恢复之后会马上释放资源，从而使更多的资源在恢复时可以被使用。

当所有的block被恢复，占用的恢复资源被释放，则系统再次可用。

在恢复中，log合并的开支和失败的Instances的数目是成比例的，并且与每个Instance的redo logs的大小有关。

b、Instance recovery和Database availability

下图显示了在进行Instance恢复时，每一步执行时数据库的可用程度：

RAC运行在多节点上
有节点失败被检测到
GRD的队列部分被重新设置；资源管理被重新分配到活动的nodes。此操作的执行比较快
GRD的缓冲部分被重新设置，SMON读取失败Instance的redo logs辨识那些需要恢复的blocks的集合
SMON向GRD发起请求，获得所有在需要恢复的blocks集合中的Database blocks。当请求结束，所有的其他的blocks都可被访问了
Oracle执行滚动的向前恢复。失败线程的redo logs被应用到Database，并且那些被完全恢复的blocks将马上可以被访问
Oracle执行滚回恢复。对于尚未提交的事务，undo blocks被应用到Database中
Instance的恢复完成，所有的data可以被访问

有效的内部节点行级锁

Oracle支持有效的行级锁。这些行级锁主要是在DML操作时被创建，例如UPDATE。这些锁被持有，直到事务被提交或回滚。任何请求相同行的lock的进程都将被挂起。

cache融合算法的块传输独立于这些user可见的行级锁。GCS对blocks的传输是一个底层的操作，无需当代行级锁被释放就开始进行。blocks可能被从一个Instance传输到其他其他Instances，同时该blocks可能被加锁。

GCS提供对data blocks的访问，允许多个事务的并发进行。

RAC的额外的内存需求

RAC特有的内存多数是在SGA创建时从shared pool中分配的。因为blocks可能跨越Instances被缓冲，必须要求更大的缓冲区。因此，当将single Instance的Database迁移到RAC中时，保持每个Instance的请求工作量都能与single-instance时的情况相同，则需要对运行RAC的Instance增大10%的buffer cache和15%的shared pool。这些值只是基于RAC大小的经验，一个初始的尝试值。一般会大于此值。

如果正在使用推荐的自动内存管理特性，可以通过修改SGA_TARGET初始参数来设置。但考虑到同样数量的user访问被分散到多个nodes中，每个Instance的内存需求可以被降低。

实际资源的使用可以通过查询每个Instance中的GCS和GES实体中的视图V$RESOURCE_LIMIT视图CURRENT_UTILIZATION和MAX_UTILIZATION字段，具体语句为：

S ELECT resource_name, current_utilization, max_utilization FROM v$resource_limit WHERE resource_name like ‘g%s_%’;

RAC与并发执行

Oracle的优化器是基于执行访问代价的，这就考虑了并发执行的代价，并将其作为获得理想的执行计划的一个部件。

在RAC环境中，优化器的并发选择是由内部节点和外部节点并发两类组成的。例如，一个特殊的查询请求需要六个查询进程完成，并且在本地节点有六个并发的从属执行进程都是idle的，则查询通过使用本地资源执行，从而获得结果。这阐述了有效地内部节点并发，也无需多节点并发的查询协调的开支。如果本地节点中只有两个并发执行从属进程可用，则这两个进程和其他节点的四个进程共同执行查询。在这种情况下，内部节点和外部节点并发都被使用到，从而加速查询。

在真实环境的决策支持应用程序中，查询不能通过各种查询servers得到较好的划分。所以有些并发执行servers完成其任务后先于其他servers变为idle状态。Oracle并发执行技术动态监测idle的进程，并将超载进程的队列表中的任务分配任务给处于idle状态的进程。这样，Oracle有效的再分配了所有进程的查询工作量。RAC进一步扩展这个效率到整个cluster上。

全局动态性能视图

全局动态性能视图显示所有开启并访问RAC Database的Instances相关的信息。而标准动态性能视图只显示了本地Instance的相关信息。

对于所有V$类型的视图，都会对应一个GV$视图，除了几个别的特殊情况。除了V$视图中的columns，GV$视图中包含了一个名为INST_ID的额外的column，显示了RAC中的Instance number。可以在任何开启的Instance上访问GV$。

为了查询GV$视图，每个Instance上的初始PARALLEL_MAX_SERVERS初始化参数至少设置为1 。这是由于对GV$的查询使用了特殊的并发执行。并发执行的协调者运行在客户端连接的Instance上，并且每个Instance上分配一个slave用于查询其潜在的V$视图。如果有一个Instance上的PARALLEL_MAX_SERVERS被设置为0，则无法获得该node的信息，同理，如果所有的并发servers非常忙，则也无法获得结果。在以上两种情况下，不会获得提示或错误信息。