怎么理解并掌握RAC

共计 4565 个字符，预计需要花费 12 分钟才能阅读完成。

这篇文章主要介绍“怎么理解并掌握 RAC”，在日常操作中，相信很多人在怎么理解并掌握 RAC 问题上存在疑惑，丸趣 TV 小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”怎么理解并掌握 RAC”的疑惑有所帮助！接下来，请跟着丸趣 TV 小编一起来学习吧！

理解 redo 共享了和 redo 单个 sequence 里面的 scn 不连续，就会明白为什么 RAC 到 RAC 的恢复或 RAC 到单机的恢复，一般都是 recover 到某个 thread 的某个 scn 或 sequnce 就可以了

数据库是否 RAC 就是看参数 cluster_database

RAC 区别于单机的一个就是多了一个 GRD（global
resource directory）内存区以及附属的多个后台进程和部分数据库文件，GRD 里记录的是每一个数据块在集群间的分布图，它位于每一个实例的 SGA 的 shared pool 中，但是每个实例都是部分 GRD，所有实例的 GRD 汇总在一起就是一个完整的 GRD。该区域用来存储同一个数据库在不同节点上的分布，即多个实例在并发操作一个数据块时，将该数据块存储在各自实例的 GRD 内存区中。

GRD 可以想像为一张大分区表，每个实例都是分区表中的分区。

GRD Master：每个被调入内存的对象，包括表，索引，cluster 等，都会被分配一个 master 实例。
GRD Master 本身也是一张表：(V$GCSHVMASTER_INFO、V$GCSPFMASTER_INFO、V$HVMASTER_INFO)
objectmaster_instance_id
T11
T22
T31
idx_t12
…

每个实例只会维护该实例所 master 的那些资源的 GRD 记录。
比如实例 1 里记录的 GRD 的数据就是 T1,T3 等的 GRD 的记录。
obj#file#block#instance…..
T110020002
T110014561
T2….

每个实例都有一份完全一样的拷贝的 GRD Master 表。
这个 master 表记录的是数据库对象，不是数据库的某行某块

RAC 实例访问的形象理解 1：比如 master 表记录中没有关于数据库对象表 1 的记录
实例 1 去访问表 1 的某行对应的块，发现 master 表中没有表 1，也就是表 1 从来没有访问过，这样数据库就在 master 表中记录表 1 的 master 为实例 1
RAC 实例访问的形象理解 2：比如 master 表记录的数据库对象表 1 的 maser 是实例 2
实例 1 去访问表 1 的某行对应的块，实例 1 去访问实例 2，实例 2 发现这个块不在 GRD 中，就告诉实例 1 这个块不在 SGA 中，实例 2 让实例 1 去走 IO 访问磁盘
实例 1 去访问表 1 的某行对应的块，实例 1 去访问实例 2，实例 2 发现这个块在 GRD 中并且就在自己的 SGA 上，实例 2 把这个块的副本发送给实例 1
实例 1 去访问表 1 的某行对应的块，实例 1 去访问实例 2，实例 2 发现这个块在 GRD 中并且在实例 3 上，实例 2 告诉实例 1 这个块在实例 3 上，并且实例 2 让实例 3 把这个块的副本发送给实例 1

2 way 和 3 way 是指要跳几个节点  
只有两节点的 RAC 不可能出现 gc current 3-way，两节点，某个数据块不在自己这里就在对方那里

本节点去访问 resource MASTER 节点
2-way: resource MASTER 和 cached 节点在同一个节点。
3 way: 就是多一个节点，resource MASTER 和 cached 节点不是同一个节点

RAC 提高性能的理解：负载不足导致 sql 执行很慢时，多个实例可以分摊负载（CPU、内存），负载不是性能瓶颈的情况下，RAC 无法提高具体的 sql 的执行效率，相反实例越多，具体的单个 SQL 的性能越差。

实例越多性能越差的理解：比如 10 个节点，实例 A 要访问 100 个块，其中 10 个块在节点 1，10 个块在节点 2.。。10 个块在节点 10，这样 100 个块，就要访问 1 次 master，master 再告诉块具体在哪个节点，这些节点再把块推送到实例 A，这样就需要 1 次实例到 master 的访问 +10 次 master 到各个节点的访问 +10 次各个节点推送块到节点 A，总计 11 次的访问 +10 次的 GC 块传输

RAC 的本质是一个数据库，运行在多台计算机上的数据库，它通过 Distributed Lock Management(DLM: 分布式锁管理器) 来解决并发问题。因为 RAC 的资源是共享的，为了保证数据的一致性，就需要使用 DLM 来协调实例间对资源的竞争访问。RAC 的 DLM 就叫作 Cache Fusion（内存融合）。

Cache Fusion 是通过高速的 Private
Interconnect，在实例间进行数据块传递，它是 RAC 最核心的工作机制，它把所有实例的 SGA 虚拟成一个大的 SGA 区，从而使得多个节点 SGA 对用户透明。每当不同的实例请求相同的数据块时，这个数据块就通过 Private Interconnect 在实例间进行传递。以避免首先将块推送到磁盘，然后再重新读入其他实例的缓存中这样一种低效的实现方式。当一个块被读入 RAC 环境中某个实例的缓存时，该块会被赋予一个锁资源（与行级锁不同），以确保其他实例知道该块正在被使用。之后，如果另一个实例请求该块的一个副本，而该块已经处于前一个实例的缓存内，那么该块会通过 Private Interconnect 直接被传递到另一个实例的 SGA。如果内存中的块已经被改变，但改变尚未提交，那么将会传递一个 CR 副本。这就意味着只要可能，数据块无需写回磁盘即可在各实例的缓存之间移动，从而避免了同步多实例的缓存所花费的额外 I /O。这样对用户而言 cache fusion 就把多个实例的数据库缓冲区虚拟成一个数据库缓冲区，它实现了 SGA 对用户透明。很明显，不同的实例缓存的数据可以是不同的，也就是在一个实例要访问特定块之前，而它又从未访问过这个块，那么它要么从其他实例 cache fusion 过来，或者从磁盘中读入。整个 Cache Fusion 有两个服务组成：GCS 和 GES。GCS 负责数据库在实例间的传递，GES 负责锁管理。Cache Fusion 要解决的首要问题就是：数据块拷贝在集群节点间的状态分布图，这是通过 GRD 实现的。

要发挥 Cache
Fusion 的作用，要有一个前提条件，那就是互联网络的速度要比访问磁盘的速度要快！否则，没有引入 Cache Fusion 的意义。

GCS/GES

Global Cache Service 全局缓存服务(GCS): 要和 Cache Fusion 结合在一起来理解。全局缓存要涉及到数据块。全局缓存服务负责维护该全局缓冲存储区内的缓存一致性，确保一个实例在任何时刻想修改一个数据块时，都可获得一个全局锁资源，从而避免另一个实例同时修改该块的可能性。进行修改的实例将拥有块的当前版本（包括已提交的和未提交的事物）以及块的前象 (post image)。如果另一个实例也请求该块，那么全局缓存服务要负责跟踪拥有该块的实例、拥有块的版本是什么，以及块处于何种模式。GCS 对应进程 LMSn(processes global cache fusion requests)

Global Enqueue Service 全局队列服务 (GES)：主要负责维护字典缓存和库缓存内的一致性。字典缓存是实例的 SGA 内所存储的对数据字典信息的缓存，用于高速访问。由于该字典信息 存储在内存中，因而在某个节点上对字典进行的修改（如 DDL) 必须立即被传播至所有节点上的字典缓存。GES 负责处理上述情况，并消除实例间出现的差异。
处于同样的原因，为了分析影响这些对象的 SQL 语句，数据库内对象上的库缓存锁会被去掉。这些锁必须在实例间进行维护，而全局队列服务必须确保请求访问相
同对象的多个实例间不会出现死锁。GES 对应进程 LMON(issues heartbeates and performs recovery)

RAC 的一些等待事件

gc buffer busy

即 global cache buffer busy，产生的原因和单实例的 buffer busy waits 类似，就是一个时间点节点 a 的实例向节点 b 请求 block 的等待。主要是修改操作引起，而非读引起。

11g 开始 gc buffer  busy 分为 gc buffer busy acquire 和 gc buffer busy release。

产生原因：热块，低效 sql（越多的数据块请求到 buffer cache 中，那么越可能造成别的会话等待。）数据交叉访问（RAC 数据库，同一数据在不同数据库实例上被请求访问）所以 RAC 建议不同的应用功能在不同的数据库实例上被访问

gc buffer busy acquire 是当 session#1 尝试请求访问远程实例(remote  instance) buffer，但是在 session#1 之前已经有相同实例上另外一个 session#2 请求访问了相同的 buffer，并且没有完成，那么 session#1 等待 gc buffer busy acquire。

gc buffer busy release 是在 session#1 之前已经有远程实例的 session#2 请求访问了相同的 buffer，并且没有完成，那么 session#1 等待 gc buffer busy release。

gcs log flush sync

GCS 日志刷新同步

flush 是 Oracle 为了保证 Instance Recovery 实例恢复机制，而要求每一个 current block 在本地节点 local instance 被修改后(modify/update) 必须要将该 current block 相关的 redo 写入到 logfile 后（要求 LGWR 必须完成写入后才能返回)，才能由 LMS 进程传输给其他节点使用。

The cause of this wait event gcs
log flush sync is mainly – Redo log IO performance.

RAC 使用分布锁管理（DLM）机制对并发进行检测，用一个例子说明 DLM 作用

（1）  一个 2 节点的 RAC

（2）  节点 1 想要修改数据 1

（3）  节点 1 向 DLM 请求，DLM 发现数据 1 还没有被任何节点使用，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 的进程 1 修改数据 1

（2）  节点 2 的进程 2 也想修改数据 1

（3）  节点 2 仍然请求 DLM，DLM 发现节点 2 现在已经有权限，无须授权

（4）  进程 2 对 DLM 的请求被通过，但是进程 2 是否能够修改数据 1，还需要进一步检查

（5）  通过传统的锁模式，比如“行级锁”，进程 2 发现数据 1 正被进程 1 修改，所以进程 2 只能等待

所以学习 RAC 就是学习 DLM，也就是 Cache Fusion（内存融合）了

RAC 集群实现并发机制过程：

到此，关于“怎么理解并掌握 RAC”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注丸趣 TV 网站，丸趣 TV 小编会继续努力为大家带来更多实用的文章！