RAC架构演变

从单实例到RAC，体系结构也由RAC集群和Clusterware集群构建

RAC的数据库和单实例的数据库在本质上并没有多大的区别；数据文件、控制文件都是共享的，不过每个实例有自己独立的redo log 组；对于自动undo管理模式、每个实例都拥有独立的undo表空间。在数据文件和控制文件的格式上、RAC系统和单实例系统并没有本质区别、因此、单实例系统可以很方便地升级到RAC系统

㈠ SGA的变化

SGA的显著变化是多了一个GRD
GRD保存：
① PCM Lock信息
② 节点健康状态的bitmap

㈡ 后台进程的变化
这里只阐述RAC集群上的后台进程的变化
① LMON进程
LMON提供了CGS和NM两个服务来维护RAC集群的状态
⑴ NM
是RAC集群与Clusterware集群的通信通道
通过NM，把本节点的资源登记到本地Clusterware，再由本地Clusterware传递给其他节点Clusterware
同时，NM还会从其他节点的Clusterware获取他们的资源状态

RAC的每个实例的所有进程是作为一个NM组注册到Clusterware中
其中LMON进程作为组长并获得Member ID，其他进程以同样的ID注册

⑵ CGS
Cluster Group Services
这个服务主要负责有：
GRD内的bitmap记录了节点的健康状态，0代表关闭，1代表正常运行
各节点的LMON定时通信，保证GRD Bitmap的一致性
另外，LMON可以和下层的Clusterware合作也可以单独工作
RAC集群并不总是假设Clusterware集群能够处理问题
如果等待超时，LMON会自动触发IMR(instance membership recovery)

② LMSn进程
负责数据块在实例间的传递

③ LMD进程
负责在多个实例间协调对数据块的访问顺序

④ LCK进程
负责non-cache fusion资源的并发访问

⑤ DIAG进程
负责实例运行时错误并记录到alert.log中

⑥ GSD进程
负责从客户端工具接收用户命令

㈢ 文件的变化
① Redo Thread
一个实例对应一个redo thread
Redo是共享的，但隶属于各个实例
因为在Crash Recovery，执行recover的节点必须能够访问故障节点的联机日志
在RAC中，每个实例写入自己的redo log中，但能够读取其他实例的redo log
每个实例有一个thread#，可以区别于其他实例的redo
实例恢复的时候更多的是读取自己thread#的redo
介质恢复时读取全局的rodo

② Undo tablespace
每个实例都需要有一个单独的undo
通过参数sid.undo_tablespace配置

③ spfile
需要被所有节点访问，应放在共享盘

④ archived log

首先有一个概念，在RAC环境中，任何节点上的归档日志在任何一个节点上都可以全部看到。所以没有v$还是gv$的问题。

对于RAC来说，归档日志就是一连串的redo，最主要的决定因素是归档日志的NAME，只要能找到这个NAME，哪个节点都行，NAME中是包含完全路径的，这也就是为什么我们为了RMAN备份有NFS解决方案的原因。

SQL> select THREAD#,count(*) from v$archived_log group by THREAD#;

   THREAD#   COUNT(*)
---------- ----------
         1        280
         2        256