一. RAC 并发
RAC 的本质是一个数据库, 运行在多台计算机上的数据库, 它的主要任务是数据库就是事务处理, 它通过 Distributed Lock Management(DLM: 分布式锁管理器) 来解决并发问题. 因为 RAC 的资源是共享的, 为了保证数据的一致性, 就需要使用 DLM 来协调实例间对资源的竞争访问. RAC 的 DLM 就叫作 Cache Fusion.
在 DLM 中, 根据资源数量, 活动密集程度, 把资源分成两类: Cache Fusion 和 Non-Cache Fusion.
Cache Fusion Resource 指数据块这种资源, 包括普通数据库, 索引数据库, 段头块 (Segment Header),undo 数据库.
Non-Cache Fusion Resource 是所有的非数据库块资源, 包括数据文件, 控制文件, 数据字典, Library Cache,share Pool 的 Row Cache 等. Row Cache 中存放的是数据字典, 它的目的是在编译过程中减少对磁盘的访问.
在 Cache Fusion 中, 每一个数据块都被映射成一个 Cache Fusion 资源, Cache Fusion 资源实际就是一个数据结构, 资源的名称就是数据块地址 (DBA). 每个数据请求动作都是分步完成的. 首先把数据块地址 X 转换成 Cache Fusion 资源名称, 然后把这个 Cache Fusion 资源请求提交给 DLM, DLM 进行 Global Lock 的申请, 释放活动, 只有进程获得了 PCM Lock 才能继续下一步, 即: 实例要获得数据块的使用权.
Cache Fusion 要解决的首要问题就是: 数据块拷贝在集群节点间的状态分布图, 这是通过 GRD 实现的.
GRD(Global Resource Directory)
可以把 GRD 看作一个内部数据库, 这里记录的是每一个数据块在集群间的分布图, 它位于每一个实例的 SGA 中, 但是每个实例 SGA 中都是部分 GRD, 所有实例的 GRD 汇总在一起就是一个完整的 GRD.
RAC 会根据每个资源的名称从集群中选择一个节点作为它的 Master Node, 而其他节点叫作 Shadow Node. Master Node 的 GRD 中记录了该资源在所有节点上的使用信息, 而 Shadow Node 的 GRD 中只需要记录资源在该节点上的使用情况, 这些信息实际就是 PCM Lock 信息. PCM Lock 有 3 个属性: Mode,Role 和 PI(Past Image)
二. RAC 架构
2.1 SGA 的变化
和传统的单实例相比, RAC Insance 的 SGA 最显著的变化就是多了一个 GRD 部分. Oracle 中的数据操作都是在内存的 SGA 区完成的, 和传统的单实例不同, RAC 是有多个, 每个数据块可以在任何一个 Instance 的 SGA 中都有拷贝, RAC 必须知道这些拷贝的分布版本, 状态, 而 GRD 就是这些信息的内存区.
GRD 虽然位于 SGA 中, 但是不像 Buffer Cache 或者 Log buffer 等 SGA 组件, 有明确的参数来对应, 每个节点中都只有部分 GRD 内容, 所有的节点合在一起才构成完整的 GRD.
2.2 后台进程的变化
每个 RAC 的实例和传统的单实例一样, 都有 DBWR,LGWR,ARCn,CKPT 这些后台进程, 除了这些进程外, 每个实例还增加了若干 RAC 特有的进程, 要注意的是, 这些进程名称和进程提供的服务名称差异很大, 比如 LMS 进程提供的是 GCS 服务, 很不便与记忆, 造成这种现象的原因是进程名称从 9i 之前的 OPS(RAC 前身) 延续下来的, 但是服务却已经在 RAC 中重新设计并命名.
2.2.1 LMSn
这个进程是 Cache Fusion 的主要进程, 负责数据块在实例间的传递, 对应的服务叫作 GCS(Global Cache Service), 这个进程的名称来源与 Lock Manager Service. 从 Oracle 9 开始, Oracle 对这个服务重新命名成 Global Cache SErvice, 但是进程名字确没有调整. 这个进程的数量是通过参数 GCS_SERVER_PROCESSES 来控制, 缺省值是 2 个, 取值范围为 0-9.
2.2.2 LMD
这个进程负责的是 Global Enqueue Service(GES), 具体来说, 这个进程负责在多个实例之间协调对数据块的访问顺序, 保证数据的一致性访问. 它和 LMSn 进程的 GCS 服务还有 GRD 共同构成 RAC 最核心的功能 Cache Fusion.
2.2.3 LCK
这个进程负责 Non-Cache Fusion 资源的同步访问, 每个实例有一个 LCK 进程
2.2.4 LMON
各个实例的 LMON 进程会定期通信, 以检查集群中各个节点的健康状态, 当某个节点出现故障时, 负责集群 重构, GRD 恢复等操作, 它提供的服务叫作: Cluster Group Services(CGS).
LMON 主要借助两种心跳机制来完成健康检查:
1) 节点间的网络心跳 (Network Heartbeat): 可以想象陈节点间定时的发送 ping 包检测节点状态, 如果能在规定时间内收到回应, 就认为对方状态正常
2) 通过控制文件的磁盘心跳 (Controlfile Heartbeat): 每个节点的 CKPT 进程每隔 3 秒更新一次控制文件一个数据块, 这个数据块叫作 Checkpoint Progress Record, 控制文件是共享的, 所以实例间可以相互检查对方是否及时更新来判断.
2.2.5 DIAG
DIAG 进程监控实例的健康状态, 并在实例出现运行错误时手机诊断数据记录到 alert.log 文件
2.2.6 GSD
这个进程负责懂客户端工具, 比如 srvctl 接收用户命令, 为用户提供管理接口.
2.3 文件
Oracle 文件包括二进制执行文件, 参数文件 (pfile 和 spfile), 密码文件, 控制文件, 数据文件, 联机日志, 归档日志, 备份文件.
2.3.1 spfile
这个参数文件需要被所有节点访问, 需要放在共享存储上
2.3.2 Redo Thread
RAC 环境下有多个实例, 每个实例都需要有自己的一套 Redo log 文件来记录日志. 这套 Redo Log 就叫作一个 Redo Thread, 其实单实例下也是 Redo Thread, 只是 Thread 这个词很少被提及, 每个实例一套 Redo Thread 的设计就是为了避免资源竞争造成性能瓶颈.
Redo Thread 有两种, 一种是 Private 的, 创建语法: alter database add logfile .. Thread n; 另一种是 public, 创建语法: alter database add logfile...; RAC 中每个实例都要设置 thread 参数, 该参数默认值为 0. 如果设置了这个参数, 则实例启动时, 会使用等于该 Thread 的 Private Redo Thread. 如果没有设置这个参数, 则使用缺省值 0, 启动实例后选择使用 Public Redo Thread, 并且实例会用独占的方式使用该 Redo Thread.
RAC 中每个实例都需要一个 Redo Thread, 每个 Redo Log Thread 至少需要两个 Redo Log Group, 每个 Log Group 成员大小应该相等, 每组最好有 2 个以上成员, 这些成员应放在不同的磁盘上, 以避免单点失败.
要注意的是, 在 RAC 环境下, Redo Log Group 是在整个数据库级别进行编号的, 比如实例 1 有 1,2,3 三个日志组, 那么实例 2 的日志组就应该从 4 开始编号, 不能在使用 1,2,3 这三个编号.
在 RAC 环境下, 所有实例的联机日志必须放在共享存储上, 因为如果某个节点异常关闭, 剩下的节点要进行 Crash Recovery, 执行 Crash Recovery 的这个节点必须能够访问到故障节点的连接日志, 只有把联机日志放在共享存储上才能满足这个要求.
2.3.3 Archived Log
RAC 中的每个实例都会产生自己的归档日志, 归档日志只有在执行 Media Recovery 时才会用到, 所以归档日志不必放在共享存储上, 每个实例可以在本地存放归档日志. 但是如果在单个实例上进行备份归档日志或者进行 Media Recovery 操作, 又要求在这个节点必须能够访问到所有实例的归档日志, 在 RAC 环境下, 配置归档日志可以有多种选择.
1) 使用 NFS
这种方式实际是归档到共享存储, 比如 2 个节点, 每个节点都有 2 个目录, Arch1,Arch2 分别对应实例 1 和实例 2 的日志. 每个实例只配置一个归档位置, 归档到本地, 然后通过 NFS 把对方的目录挂到本地.
2) 实例间归档 (CIA: Cross Instance Archive)
这种方式是上一种方式的变种, 也是比较常见的一种配置方法. 两个节点都创建 2 个目录 Arch1 和 Arch2 分别对应实例 1 和实例 2 产生的归档日志. 每个实例都配置两个归档位置. 位置 1 对应本地归档目录, 位置 2 对应另一个实例.
3) 使用 ASM
这种方式也是归档到共享存储, 只是通过 Oracle 提供的 ASM, 把上面的复杂性隐藏了, 但原理都一样.
2.3.4 Undo Tablespace
和 Redo Log 一样, 在 RAC 环境下, 每个实例都需要有一个单独的回滚表空间, 这个是通过参数 SID.undo_tablespace 来配置的.
2.4 SCN(System Change Number)
SCN 是 Oracle 用来跟踪数据库内部变化发生的先后顺序的机制, 可以把它想象成一个高精度的时钟, 每个 Redo 日志条目, Undo Data Block,Data Block 都会有 SCN 号. Oracle 的 Consistent-Read, Current-Read, Multiversion-Block 都是依赖 SCN 实现.
在 RAC 中, 有 GCS 负责全局维护 SCN 的产生, 缺省用的是 Lamport SCN 生成算法, 该算法大致原理是: 在所有节点间的通信内容中都携带 SCN, 每个节点把接收到的 SCN 和本机的 SCN 对比, 如果本机的 SCN 小, 则调整本机的 SCN 和接收的一致, 如果节点间通信不多, 还会主动地定期相互通报. 故即使节点处于 Idle 状态, 还是会有一些 Redo log 产生. 还有一个广播算法 (Broadcast), 这个算法是在每个 Commit 操作之后, 节点要想其他节点广播 SCN, 虽然这种方式会对系统造成一定的负载, 但是确保每个节点在 Commit 之后都能立即查看到 SCN.
这两种算法各有优缺点, Lamport 虽然负载小, 但是节点间会有延迟, 广播虽然有负载, 但是没有延迟. Oracle 10g RAC 缺省选用的是 BroadCast 算法, 可以从 alert.log 日志中看到相关信息:
Picked broadcast on commit scheme to generate SCNS
RedoLog Checkpoint 和 SCN 关系
http://blog.csdn.net/tianlesoftware/archive/2010/01/25/5251916.aspx
2.5 Cache Fusion, GCS, GES 关系
Cache Fusion(内存融合) 是通过高速的 Private Interconnect, 在实例间进行数据块传递, 它是 RAC 最核心的工作机制, 它把所有实例的 SGA 虚拟成一个大的 SGA 区. 每当不同的实例请求相同的数据块时, 这个数据块就通过 Private Interconnect 在实例间进行传递.
整个 Cache Fusion 有两个服务组成: GCS 和 GES. GCS 负责数据库在实例间的传递, GES 负责锁管理
总结:
lms 和 lmd 共同负责 gcs
gcs 和 ges 共同组成 grd
而这一套服务就是 dlm
来源: http://www.bubuko.com/infodetail-2589083.html