工作原理和相关组件

OracleRAC 是多个单实例在配置意义上的扩展，实现由两个或者多个节点（实例）使用一个共同的共享数据库（例如，一个数据库同时安装多个实例并打开）。在这种情况下，每一个单独的实例有它自己的 cpu 和物理内存，也有自己的 SGA 和后台进程。和传统的 oracle 实例相比，在系统全局区（SYSTEM CLOBAL AREA,SGA）与后台进程有着显著的不同。最大的不同之处在于多了一个GRD,GRD内存块主要是记录此rac有多少个集群数据库与系统资源，同时也会记录数据块的相关信息，因为在 rac 架构中，每个数据块在每一个 SGA 中都有一份副本，而 rac 必须知道这些数据块的位置，版本，分布以及目前的状态，这些信息就存放在 GRD 中，但 GRD 只负责存放不负责管理，管理的责任则交给后台进程 GCS 和 GES 来进行。Oracle 的多个实例访问一个共同的共享数据库。每个实例都有自己的 SGA、PGA 和后台进程，这些后台进程应该是熟悉的，因为在 RAC 配置中，每个实例将需要这些后台进程运行支撑的。可以从以下几个方面了解 RAC工作原理和运行机制。

SCN

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。

RAC 的 GES/GCS 原理

全局队列服务（GES）主要负责维护字典缓存和库缓存的一致性。字典缓存是实例的 SGA 内所存储的对数据字典信息的缓存，用于高速访问。由于该字典信息存储在内存中，因而在某个节点上对字典进行的修改（如DDL)必须立即被传播至所有节点上的字典缓存。GES 负责处理上述情况，并消除实例间出现的差异。处于同样的原因，为了分析影响这些对象的 SQL 语句，数据库内对象上的库缓存锁会被去掉。这些锁必须在实例间进行维护，而全局队列服务必须确保请求访问相同对象的多个实例间不会出现死锁。LMON、LCK 和 LMD 进程联合工作来实现全局队列服务的功能。GES 是除了数据块本身的维护和管理（由 GCS 完成）之外，在 RAC 环境中调节节点间其他资源的重要服务。为了保证集群中的实例的同步，两个虚拟服务将被实现：全局排队服务（GES），它负责控制对锁的访问。

全局内存服务（GCS)，控制对数据块的访问。GES 是分布式锁管理器(DLM)的扩展，它是这样一个机制，可以用来管理 oracle 并行服务器的锁和数据块。在一个群集环境中，你需要限制对数据库资源的访问，这些资源在单 instance 数据库中被 latches 或者 locks 来保护。比如说，在数据库字典内存中的对象都被隐性锁所保护，而在库高速缓存中的对象在被引用的时候，必须被 pin 所保护。在 RAC 群集中，这些对象代表了被全局锁所保护的资源。GES 是一个完整的 RAC 组件，它负责和群集中的实例全局锁进行沟通，每个资源有一个主节点实例，这个实例记录了它当前的状态。而且，资源的当前的状态也记录在所有对这个资源有兴趣的实例上。GCS,是另一个 RAC 组件，负责协调不同实例间对数据块的访问。对这些数据块的访问以及跟新都记录在全局目录中（GRD）,这个全局目录是一个虚拟的内存结构，在所有的实例中使用扩张。每个块都有一个master实例，这个实例负责对GSD的访问进行管理，GSD里记录了这个块的当前状态信息。

GCS 是 oracle 用来实施 Cache fusion 的机制。被 GCS 和 GES 管理的块和锁叫做资源。对这些资源的访问必须在群集的多个实例中进行协调。这个协调在实例层面和数据库层面都有发生。实例层次的资源协调叫做本地资源协调；数据库层次的协调叫做全局资源协调。

本地资源协调的机制和单实例 oracle 的资源协调机制类似，包含有块级别的访问，空间管理，dictionary cache、library cache 管理，行级锁，SCN 发生。全局资源协调是针对 RAC 的，使用了 SGA 中额外的内存组件、算法和后台进程。GCS 和 GES 从设计上就是在对应用透明的情况下设计的。换一句话来说，你不需要因为数据库是在 RAC上运行而修改应用,在单实例的数据库上的并行机制在 RAC 上也是可靠地。

支持 GCS 和 GES 的后台进程使用私网心跳来做实例之间的通讯。这个网络也被 Oracle 的群集组件使用，也有可能被群集文件系统（比如 OCFS)所使用。GCS 和 GES 独立于 Oracle 群集组件而运行。但是，GCS 和GES 依靠这些群集组件获得群集中每个实例的状态。如果这些信息不能从某个实例获得，这个实例将被关闭。这个关闭操作的目的是保护数据库的完整性，因为每个实例需要知道其他实例的情况，这样可以更好的确定对数据库的协调访问。

GES 控制数据库中所有的 library cache 锁和 dictionary cache 锁。这些资源在单实例数据库中是本地性的，但是到了 RAC 群集中变成了全局资源。全局锁也被用来保护数据的结构，进行事务的管理。一般说来，事务和表锁在 RAC 环境或是单实例环境中是一致的。

Oracle 的各个层次使用相同的 GES 功能来获得，转化以及释放资源。在数据库启动的时候，全局队列的个数将被自动计算。GES 使用后台进程 LMD0 和 LCK0 来执行它的绝大多数活动。一般来说，各种进程和本地的 LMD0 后台进程沟通来管理全局资源。本地的 LMD0 后台进程与别的实例上的 LMD0 进程进行沟通。

LCK0 后台进程用来获得整个实例需要的锁。比如，LCK0 进程负责维护 dictionary cache 锁。影子进程(服务进程）与这些后台进程通过 AST(异步陷阱）消息来通信。异步消息被用来避免后台进程的阻塞，这些后台进程在等待远端实例的的回复的时候将阻塞。后台进程也能发送 BAST(异步锁陷阱）来锁定进程，这样可以要求这些进程把当前的持有锁置为较低级限制的模式。资源是内存结构，这些结构代表了数据库中的组件，对这些组件的访问必须为限制模式或者串行化模式。换一句话说，这个资源只能被一个进程或者一直实例并行访问。如果这个资源当前是处于使用状态，其他想访问这个资源的进程必须在队列中等待，直到资源变得可用。队列是内存结构，它负责并行化对特殊资源的访问。如果这些资源只被本地实例需求，那么这个队列可以本地来获得，而且不需要协同。但是如果这个资源被远程实例所请求，那么本地队列必须变成全球化。

CLUSTERWARE 架构

在单机环境下，Oracle 是运行在 OS Kernel 之上的。 OS Kernel 负责管理硬件设备，并提供硬件访问接口。Oracle 不会直接操作硬件，而是有 OS Kernel 代替它来完成对硬件的调用请求。在集群环境下，存储设备是共享的。OS Kernel 的设计都是针对单机的，只能控制单机上多个进程间的访问。如果还依赖 OS Kernel 的服务，就无法保证多个主机间的协调工作。这时就需要引入额外的控制机制，在RAC 中，这个机制就是位于 Oracle 和 OS Kernel 之间的 Clusterware，它会在 OS Kernel 之前截获请求，然后和其他结点上的 Clusterware 协商，最终完成上层的请求。在 Oracle 10G 之前，RAC 所需要的集群件依赖与硬件厂商，比如 SUN,HP,Veritas. 从 Oracle 10.1版本中，Oracle推出了自己的集群产品. Cluster Ready Service(CRS),从此 RAC 不在依赖与任何厂商的集群软件。在 Oracle 10.2版本中，这个产品改名为：Oracle Clusterware。所以我们可以看出，在整个 RAC 集群中，实际上有 2 个集群环境的存在，一个是由 Clusterware 软件组成的集群，另一个是由 Database 组成的集群。

Clusterware 的主要进程

a) CRSD——负责集群的高可用操作，管理的 crs 资源包括数据库、实例、监听、虚拟 IP，ons，gds 或者其他，操作包括启动、关闭、监控及故障切换。改进程由 root 用户管理和启动。crsd 如果有故障会导致系统重启。

b) cssd，管理各节点的关系，用于节点间通信，节点在加入或离开集群时通知集群。该进程由 oracle 用户运行管理。发生故障时 cssd 也会自动重启系统。

c) oprocd – 集群进程管理 —Process monitor for the cluster. 用于保护共享数据 IO fencing。

d) 仅在没有使用 vendor 的集群软件状态下运行

e) evmd ：事件检测进程，由 oracle 用户运行管理

Cluster Ready Service（CRS，集群准备服务）是管理集群内高可用操作的基本程序。Crs 管理的任何事物被称之为资源，它们可以是一个数据库、一个实例、一个监听、一个虚拟 IP（VIP）地址、一个应用进程等等。CRS是根据存储于 OCR 中的资源配置信息来管理这些资源的。这包括启动、关闭、监控及故障切换（start、stop、monitor 及 failover）操作。当一资源的状态改变时，CRS 进程生成一个事件。当你安装 RAC 时，CRS 进程监控Oracle 的实例、监听等等，并在故障发生时自动启动这些组件。默认情况下，CRS 进程会进行 5 次重启操作，如果资源仍然无法启动则不再尝试。Event Management（EVM）：发布 CRS 创建事件的后台进程。Oracle Notification Service（ONS）：通信的快速应用通知（FAN：Fast Application Notification）事件的发布及订阅服务。RACG：为 clusterware 进行功能扩展以支持 Oracle 的特定需求及复杂资源。它在 FAN 事件发生时执行服务器端的调用脚本（server callout script）Process Monitor Daemon（OPROCD）：此进程被锁定在内存中，用于监控集群（cluster）及提供 I/O 防护（I/Ofencing）。OPROCD 执行它的检查，停止运行，且如果唤醒超过它所希望的间隔时，OPROCD 重置处理器及重启节点。一个 OPROCD 故障将导致 Clusterware 重启节点。

Cluster Synchronization Service（CSS）：CSS 集群同步服务，管理集群配置，谁是成员、谁来、谁走，通知成员，是集群环境中进程间通信的基础。同样，CSS 也可以用于在单实例环境中处理 ASM 实例与常规 RDBMS 实例之间的交互作用。在集群环境中，CSS 还提供了组服务，即关于在任意给定时间内哪些节点和实例构成集群的动态信息，以及诸如节点的名称和节点静态信息（这些信息在节点被加入或者移除时被修改）。CSS 维护集群内的基本锁功能（尽管大多数锁有 RDBMS 内部的集成分布式锁管理来维护）。除了执行其他作业外，CSS 还负责在集群内节点间维持一个心跳的程序，并监控投票磁盘的 split-brain 故障。在安装 clusterware 的最后阶段，会要求在每个节点执行 root.sh 脚本，这个脚本会在/etc/inittab 文件的最后把这 3 个进程加入启动项，这样以后每次系统启动时，clusterware 也会自动启动，其中 EVMD 和 CRSD 两个进程如果出现异常，则系统会自动重启这两个进程，如果是 CSSD 进程异常，系统会立即重启。

注意：

Voting Disk 和 OCR 必须保存在存储设备上供各个节点访问。
Voting Disk、OCR 和网络是安装的过程中或者安装前必须要指定或者配置的。安装完成后可以通过一些工具进行配置和修改。

RAC 软件结构

RAC 软件结构可以分为四部分。

操作系统相关的软件
RAC 共享磁盘部分
RAC 中特别的后台进程和实例进程
全局缓冲区服务和全局队列服务

(一) Operation System-Dependent（OSD）

RAC 通过操作系统的相关软件来访问操作系统和一些与 Cluster 相关的服务进程。OSD 软件可能由 Oracle 提供（windows 平台）或由硬件厂商提供（unix 平台）。OSD 包括三个自部分：

The Cluster Manager(CM)：集群监视器监视节点间通信，并通过 interconnect 来协调节点操作。同时还提供 CLUSTER 中所有节点和实例的统一视图。CM 还控制 CLUSTER 的成员资格。
The Node Monitor（节点监视器）：节点监视器提供节点内各种资源的状态，包括节点、interconnect 硬件和软件和共享磁盘等。
The Interconnect 节点间心跳（两种心跳机制，一种是通过私有网络的 network heartbeat；另一种是通过 voting disk 的 disk heartbeat）

(二) Real Application Cluster Shard Disk Component

RAC 中这部分组件和单实例 Oracle 数据库中的组件没有什么区别。包括一个或者多个控制文件、一些列联机重做日志文件、可选的归档日志文件、数据文件等。在 RAC 中使用服务器参数文件会简化参数文件的管理，可以将全局参数和实例特定的参数存储在同一个文件中。

(三) Real Application Cluster-Specific Daemon and Instance Processes包括以下部分：

The Global Service Daemon（GSD）：在每个节点上都运行一个全局服务后台进程，用于接收客户端如DBCA、EM 等发出的管理消息，并完成相应的管理任务，比如实例的启动和关闭。
RAC 中特别的实例进程： Global Cache Service Processes(LMSn)：控制到远端实例的消息的流量，管理全局数据块的访问。还用于在不同实例的缓冲区之间传递 BLOCK 的映射。
Global Enqueue Service Monitor(LMON)：监视全局队列和集群间的资源交互，执行全局队列的恢复操作。
Global Enqueue Service Daemon(LMD)：管理全局队列和全局资源访问。对于每个实例，LMD 管理来自远端的资源请求。
Lock Processes(LCK)：管理除 Cache Fusion 以外的非数据块资源请求，比如数据文件，控制文件，数据字典试图，library 和 row cache 的请求。
Diagnosability Daemon(DIAG)：在实例中捕获进程失败的诊断数据。
(四) The Global Cache and Global Enqueue Service

全局缓存服务（GCS）和全局队列服务（GES）是 RAC 的集成组件，用于协调对共享数据库和数据库内的共享资源的同时访问。 GCS 和 GES 包括以下特性：

应用透明性。
分布式结构
分布式结构的全局资源目录：只要还存在一个节点，即使出现一个或多个节点失败，GCS 和 GES 仍然可以保证全局资源目录的完整性。
资源控制：GCS 和 GES 会选择一个实例来管理所有的资源信息，这个实例叫做 resource master。GCS和 GES 会根据数据访问方式阶段性的评估和修改 resource master。这种方式会减少网络流量和资源获取时间。
GCS 和 GES 与 CM 之间的交互：GCS 和 GES 独立于 CM。但同时 GCS 和 GES 依赖于 CM 提供的各个节点上实例的状态信息。一旦无法取得某个实例的信息，则 Oracle 会马上关闭没有响应的实例，来保证整个 RAC 的完整性。

集群注册（OCR）

健忘问题是由于每个节点都有配置信息的拷贝，修改节点的配置信息不同步引起的。Oracle 采用的解决方法就是把这个配置文件放在共享的存储上，这个文件就是 OCR Disk。OCR 中保存整个集群的配置信息，配置信息以”Key-Value” 的形式保存其中。在 Oracle 10g 以前，这个文件叫作 Server Manageability Repository(SRVM). 在 Oracle 10g，这部分内容被重新设计，并重名为 OCR.在 Oracle Clusterware 安装的过程中，安装程序会提示用户指定 OCR 位置。并且用户指定的这个位置会被记录在/etc/oracle/ocr.Loc(LinuxSystem) 或者/var/opt/oracle/ocr.Loc(SolarisSystem)文件中。而在 Oracle 9i RAC 中，对等的是 srvConfig.Loc 文件。Oracle Clusterware 在启动时会根据这里面的内容从指定位置读入 OCR 内容。

(一) OCR key

整个 OCR 的信息是树形结构，有 3 个大分支。分别是 SYSTEM,DATABASE 和 CRS。每个分支下面又有许多小分支。这些记录的信息只能由 root 用户修改。

(二) OCR process

Oracle Clusterware 在 OCR 中存放集群配置信息，故 OCR 的内容非常的重要，所有对 OCR 的操作必须确保OCR 内容完整性，所以在 ORACLE Clusterware 运行过程中，并不是所有结点都能操作 OCR Disk.在每个节点的内存中都有一份 OCR 内容的拷贝，这份拷贝叫作 OCR Cache。每个结点都有一个 OCR Process来读写 OCR Cache，但只有一个节点的 OCR process 能读写 OCR Disk 中的内容，这个节点叫作 OCR Master 结点。这个节点的 OCR process 负责更新本地和其他结点的 OCR Cache 内容。所有需要OCR 内容的其他进程，比如OCSSD,EVM等都叫作Client Process，这些进程不会直接访问OCR Cache，而是像 OCR Process发送请求，借助 OCR Process获得内容，如果想要修改 OCR 内容，也要由该节点的 OCR Process像 Master node 的 OCR process 提交申请，由 Master OCR Process 完成物理读写，并同步所有节点 OCR Cache 中的内容。

　ORACLE 仲裁盘（VOTING DISK）

Voting Disk 这个文件主要用于记录节点成员状态，在出现脑裂时，决定那个 Partion 获得控制权，其他的Partion 必须从集群中剔除。在安装 Clusterware 时也会提示指定这个位置。安装完成后可以通过如下命令来查看Voting Disk 位置。$Crsctl query css votedisk。

集群的网络连接

专用网络

每个集群节点通过专用高速网络连接到所有其他节点，这种专用高速网络也称为集群互联或高速互联 (HSI)。Oracle 的 Cache Fusion 技术使用这种网络将每个主机的物理内存 (RAM) 有效地组合成一个高速缓存。 OracleCache Fusion 通过在专用网络上传输某个 Oracle 实例高速缓存中存储的数据允许其他任何实例访问这些数据。它还通过在集群节点中传输锁定和其他同步信息保持数据完整性和高速缓存一致性。专用网络通常是用千兆以太网构建的，但是对于高容量的环境，很多厂商提供了专门为 Oracle RAC 设计的低延迟、高带宽的专有解决方案。 Linux 还提供一种将多个物理 NIC 绑定为一个虚拟 NIC 的方法（此处不涉及）来增加带宽和提高可用性。

公共网络

为维持高可用性，为每个集群节点分配了一个虚拟 IP 地址 (VIP)。如果主机发生故障，则可以将故障节点的 IP 地址重新分配给一个可用节点，从而允许应用程序通过相同的 IP 地址继续访问数据库。

Virtual lP（VIP）

即虚拟 IP，Oracle 推荐客户端连接时通过指定的虚拟 IP 连接，这也是 Oracle10g 新推出的一个特性。其本质目的是为了实现应用的无停顿(虽然目前还是有点小问题，但离目标已经非常接近)。用户连接虚 IP，这个 IP并非绑定于网卡，而是由 oracle 进程管理，一旦某个用户连接的虚 IP 所在实例宕机，oracle 会自动将该 IP 映射到状态正常的实例，这样就不会影响到用户对数据库的访问，也无须用户修改应用。Oracle 的 TAF 建立在 VIP 技术之上。IP 和 VIP 区别在与： IP 是利用 TCP 层超时， VIP 利用的是应用层的立即响应。VIP 它是浮动的 IP. 当一个节点出现问题时会自动的转到另一个节点上。

透明应用切换（TAF）

透明应用故障转移（Transport Application Failover，TAF）是 oracle 数据提供的一项，普遍应用于 RAC 环境中，当然也可以用于 Data Guard 和传统的 HA 实现的主从热备的环境中。TAF 中的 Transparent 和 Failover，点出了这个高可用特性的两大特点：

TAF 是用于故障转移的，也就是切换。当 Oracle 连接的会话由于数据库发生故障不可用时，会话能够自动切换到 RAC 中的其他可用的节点上，或者切换到 Standby 上面，或者切换到 HA 方式中的另一个可用的节点上面。
TAF 的故障转移，对应用来说是透明的，应用系统不需要进行特别的处理就能够自动进行故障转移。

但是，TAF 是完美的吗？是不是使用了 TAF，应用就能真的无缝地进行切换呢？对应用和数据库有没有其他什么要求？要回答这些问题，我们需要全面地了解、掌握 TAF。我始终认为，要用好一个东西，首先得掌握这个东西背后的工作原理与机制。首先来看看 Failover。Failover 有两种，一种是连接时 Failover，另一种则是运行时 Failover。前者的作用在于，应用（客户端）在连接数据库时，如果由于网络、实例故障等原因，连接不上时，能够连接数据库中的其他实例。后者的作用在于，对于一个已经在工作的会话（也就是连接已经建立），如果这个会话的实例异常中止等，应用（客户端）能够连接到数据库的其他实例（或备用库）。

　连接负载均衡

负载均衡（Load-Banlance）是指连接的负载均衡。RAC 的负载均衡主要指的是新会话连接到 RAC 数据库时，根据服务器节点的 CPU 负载判定这个新的连接要连接到哪个节点进行工作。Oracle RAC 可以提供动态的数据服务，负载均衡分为两种，一种是基于客户端连接的，一种是基于服务器端的。

VIP 的原理和特点

Oracle 的 TAF 建立在 VIP 的技术之上。IP 和 VIP 区别在于：IP 是利用 TCP 层超时，VIP 利用的是应用层的立即响应。VIP 是是浮动的 IP，当一个节点出现问题的时候，会自动的转到另一个节点上。假设有一个两节点的 RAC，正常运行时每个节点上都有一个 VIP，即 VIP1 和 VIP2。当节点 2 发生故障，比如异常关系。RAC 会做如下操作：

(一) CRS 在检测到 rac2 节点异常后，会触发 Clusterware 重构，最后把 rac2 节点剔除集群，由节点 1 组成新的集群。

(二) RAC 的 Failover 机制会把节点 2 的 VIP 转移到节点 1 上，这时节点 1 的 PUBLIC 网卡上就有 3 个 IP 地址：VIP1,VIP2, PUBLIC IP1。

(三) 用户对 VIP2 的连接请求会被 IP 层路由转到节点 1。

(四) 因为在节点 1 上有 VIP2 的地址，所有数据包会顺利通过路由层，网络层，传输层。

(五) 但是，节点 1 上只监听 VIP1 和 public IP1 的两个 IP 地址。并没有监听 VIP2，故应用层没有对应的程序接收这个数据包，这个错误立即被捕获。

(六) 客户端能够立即接收到这个错误，然后客户端会重新发起向 VIP1 的连接请求。VIP 特点：

VIP 是通过 VIPCA 脚本创建的。
VIP 作为 Nodeapps 类型的 CRS Resource 注册到 OCR 中，并由 CRS 维护状态。
VIP 会绑定到节点的 public 网卡上，故 public 网卡有 2 个地址。
当某个节点发生故障时，CRS 会把故障节点的 VIP 转移到其他节点上。
每个节点的 Listener 会同时监听 public 网卡上的 public ip 和 VIP。
客户端的 tnsnames.Ora 一般会配置指向节点的 VIP。

日志体系

　Redo Thread

RAC 环境下有多个实例，每个实例都需要有自己的一套 Redo Log 文件来记录日志。这套 Redo Log 就叫做 RedoThread，其实单实例下也是 Redo Thread，只是这个词很少被提及，每个实例一套 Redo Thread 的设计就是为了避免资源竞争造成的性能瓶颈。Redo Thread 有两种，一种是 Private，创建语法 alter database add logfile ......thread n；另一种是 public，创建语法：alter database add logfile......；RAC 中每个实例都要设置 thread 参数，该参数默认值为 0。如果设置了这个参数，则使用缺省值 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 两个日志组，那么实例 2 的日志组编号就应该从 3 开始，不能使用 1,2 编号了。在 RAC 环境上，所有实例的联机日志必须放在共享存储上，因为如果某个节点异常关闭，剩下的节点要进行 crash recovery，执行 crash recovery 的这个节点必须能够访问到故障节点的连接日志，只有把联机日志放在共享存储上才能满足这个要求。

Archive log

RAC 中的每个实例都会产生自己的归档日志，归档日志只有在执行 Media Recovery 时才会用到，所以归档日志不必放在共享存储上，每个实例可以在本地存放归档日志。但是如果在单个实例上进行备份归档日志或者进行 Media Recovery 操作，又要求在这个节点必须能够访问到所有实例的归档日志，在 RAC 幻境下，配置归档日志可以有多种选择。

使用 NFS

使用 NFS 的方式将日志直接归档到存储，例如两个节点，每个节点都有 2 个目录，Arch1，Arch2 分别对应实例 1 和实例 2 产生的归档日志。每个实例都配置一个归档位置，归档到本地，然后通过 NFS 把对方的目录挂到本地。

实例间归档（Cross Instance Archive CIA）

实例间归档（Cross Instance Archive）是上一种方式的变种，也是比较常见的一种配置方法。两个节点都创建 2 个目录 Arch1 和 Arch2 分别对应实例 1 和实例 2 产生的归档日志。每个实例都配置两个归档位置。位置 1对应本地归档目录，位置 2 对应另一个实例。

使用 ASM

使用 ASM 将日志归档到共享存储，只是通过 Oracle 提供的 ASM，把上面的复杂性隐藏了，但是原理都一样。

Trace 日志

Oracle Clusterware 的辅助诊断，只能从 log 和 trace 进行。而且它的日志体系比较复杂。 alert.log：$ORA_CRS_HOME/log/hostname/alert.Log，这是首选的查看文件。

Clusterware 后台进程日志

crsd.Log: $ORA_CRS_HOME/log/hostname/crsd/crsd.Log
ocssd.Log: $ORA_CRS_HOME/log/hostname/cssd/ocsd.Log
evmd.Log: $ORA_CRS_HOME/log/hostname/evmd/evmd.Log

Nodeapp 日志位置

$ORA_CRS_HOME/log/hostname/racg/这里面放的是 nodeapp 的日志，包括 ONS 和 VIP，比如：ora.Rac1.ons.Log工具执行日志：$ORA_CRS_HOME/log/hostname/client/

Clusterware 提供了许多命令行工具比如 ocrcheck, ocrconfig,ocrdump,oifcfg 和 clscfg, 这些工具产生的日志就放在这个目录下，还有 $ORACLE_HOME/log/hostname/client/ 和$ORACLE_HOME/log/hostname/racg 也有相关的日志。

RAC 优点

多节点负载均衡
提供高可用性，故障容错及无缝切换功能，将硬件和软件的异常造成的影响最小化。
通过并行执行技术提供事务响应的时间 - 通常用于数据分析系统。
通过横向扩展提高每秒交易数和连接数 - 通常用于 OLTP。
节约硬件成本，可以使用多个廉价的 PC 服务器代替小型机大型机，节约相应的维护成本。
可扩展性好，可以方便添加删除节点，扩展硬件资源。

RAC 缺点

管理更复杂，要求更高
系统规划设计较差时性能可能会不如单节点
可能会增加软件成本(按照 CPU 收费)