【概念文档】RAC 介绍

博主： lo8ol
发布时间：2021 年 08 月 01 日
2070 次浏览
暂无评论
110469字数
分类： RAC

# 一、集群介绍

## 1.1 集群术语须知

> 服务硬件：
> 指提供计算服务的硬件,比如 PC 机、PC 服务器.
> 服务实体：
> 服务实体通常指服务软体和服务硬体.
> 节点(node)：
> 运行 Heartbeat 进程的一个独立主机称为节点,节点是 HA 的核心组成部分,每个节点上运行着操作系统和Heartbeat 软件服务.
> 资源(resource)：
> 资源是一个节点可以控制的实体,当节点发生故障时,这些资源能够被其他节点接管.如： 磁盘分区、文件系统、IP 地址、应用程序服务、共享存储
> 事件(event)：
> 事件也就是集群中可能发生的事情,例如节点系统故障、网络连通故障、网卡故障和应用程序故障等.这些事件都会导致节点的资源发生转移,HA 的测试也是基于这些事件进行的.

## 1.2 什么是集群

> 集群(cluster)就是一组计算机,它们作为一个整体向用户提供一组网络资源,这些单个的计算机系统就是集群的节点(node).集群提供了以下关键的特性.
> (一) 可扩展性.
> 集群的性能不限于单一的服务实体,新的服务实体可以动态的加入到集群,从而增强集群的性能.
> (二) 高可用性.
> 集群通过服务实体冗余使客户端免于轻易遭遇到“out of service”警告.当一台节点服务器发生故障的时候,这台服务器上所运行的应用程序将在另一节点服务器上被自动接管.消除单点故障对于增强数据可用性、可达性和可靠性是非常重要的.
> (三) 负载均衡.
> 负载均衡能把任务比较均匀的分布到集群环境下的计算和网络资源,以便提高数据吞吐量.
> (四) 错误恢复.
> 如果集群中的某一台服务器由于故障或者维护需要而无法使用,资源和应用程序将转移到可用的集群节点上.这种由于某个节点中的资源不能工作,另一个可用节点中的资源能够透明的接管并继续完成任务的过程叫做错误恢复.

### 1.2.1 分布式与集群的联系与区别

> (一) 分布式是指将不同的业务分布在不同的地方.
> (二) 而集群指的是将几台服务器集中在一起,实现同一业务.
> (三) 分布式的每一个节点,都可以做集群,而集群并不一定就是分布式的.而分布式,从狭义上理解,也与集群差不多,但是它的组织比较松散,不像集群,有一定组织性,一台服务器宕了,其他的服务器可以顶上来.分布式的每一个节点,都完成不同的业务,一个节点宕了,这个业务就不可访问了.

### 1.2.2 集群主要分成三大类

> HA：高可用集群(High Availability Cluster).
> LBC：负载均衡集群/负载均衡系统(Load Balance Cluster)
> HPC：科学计算集群(High Performance Computing Cluster)/高性能计算(High Performance Computing)集群

## 1.3 为什么搭建数据库集群

> 随着经济的高速发展,企业规模的迅猛扩张,企业用户的数量、数据量的爆炸式增长,对数据库提出了严峻的考验.对于所有的数据库而言,除了记录正确的处理结果之外,还面临着以下几方面的挑战.
>
>> 如何提高处理速度,实现数据库的均衡负载.
>> 如何保证数据库的可用性、数据安全性、以及如何实现数据集群可扩性.
>> 怎么综合解决这些问题成为众多企业关注的焦点.
>>
>
> 在数据库上,组建集群也是同样的道理,主要有以下几个原因：
> (一) 伴随着企业的成长,业务量提高,数据库的访问量和数据量快速增长,其处理能力和计算速度也相应增大,使得单一的设备根本无法承担.
> (二) 在以上情况下,若扔掉现有设备,做大量的硬件升级,势必造成现有资源的浪费,而且下一次业务量提升时,又将面临再一次硬件升级的高额投入.于是,人们希望通过几个中小型服务器组建集群,实现数据库的负载均衡及持续扩展;在需要更高数据库处理速度时,只要简单的增加数据库服务器就可以得到扩展.
> (三) 数据库作为信息系统的核心,起着非常重要的作用,单一设备根本无法保证系统的下持续运行,若发生系统故障,将严重影响系统的正常运行,甚至带来巨大的经济损失.于是,人们希望通过组建数据库集群,实现数据库的高可用,当某节点发生故障时,系统会自动检测并转移故障节点的应用,保证数据库的持续工作.
> (四) 企业的数据库保存着企业的重要信息,一些核心数据甚至关系着企业的命脉,单一设备根本无法保证数据库的安全性,一旦发生丢失,很难再找回来.于是,人们希望通过组建数据库集群,实现数据集的冗余,通过备份数据来保证安全性.

## 1.4 数据库集群的分类

> 数据库集群技术是将多台服务器联合起来组成集群来实现综合性能优于单个大型服务器的技术,这种技术不但能满足应用的需要,而且大幅度的节约了投资成本.数据库集群技术分属两类体系：基于数据库引擎的集群技术和基于数据库网关(中间件)的集群技术.在数据库集群产品方面,其中主要包括基于数据库引擎的集群技术的 Oracle RAC、Microsoft MSCS、IBM DB2UDB、Sybase ASE,以及基于数据库网关(中间件)的集群技术的 ICX-UDS 等产品.
>
>> 一般来讲,数据库集群软件侧重的方向和试图解决的问题划分为三大类：
>>
>>> -负载均衡集群(Load Balance Cluster,LBC)侧重于数据库的横向扩展,提升数据库的性能.
>>> -高可用性集群(High Availability Cluster,HAC)侧重保证数据库应用持续不断.大部分的数据库集群侧重与此.
>>> -高安全性集群(High Security Cluster,HSC)侧重于容灾.
>>>
>>
>
> 只有 Oracle RAC 能实现以上三方面

## 1.5 可扩展的分布式数据库架构

### 1.5.1 Oracle RAC

> 其架构的最大特点是共享存储架构(Shared-storage),整个 RAC 集群是建立在一个共享的存储设备之上的,节点之间采用高速网络互联.OracleRAC 提供了非常好的高可用特性,比如负载均衡和应用透明切块(TAF),其最大的优势在于对应用完全透明,应用无需修改便可切换到RAC 集群.但是RAC 的可扩展能力有限,首先因为整个集群都依赖于底层的共享存储,所以共享存储的 I/O 能力和可用性决定了整个集群的可以提供的能力,对于 I/O 密集型的应用,这样的机制决定后续扩容只能是 Scale up(向上扩展)类型,对于硬件成本、开发人员的要求、维护成本都相对比较高.Oracle显然也意识到了这个问题,在 Oracle 的 MAA(Maximum Availability Architecture)架构中,采用 ASM 来整合多个存储设备的能力,使得 RAC 底层的共享存储设备具备线性扩展的能力,整个集群不再依赖于大型存储的处理能力和可用性.

> RAC 的另外一个问题是,随着节点数的不断增加,节点间通信的成本也会随之增加,当到某个限度时,增加节点可能不会再带来性能上的提高,甚至可能造成性能下降.这个问题的主要原因是 Oracle RAC 对应用透明,应用可以连接集群中的任意节点进行处理,当不同节点上的应用争用资源时,RAC 节点间的通信开销会严重影响集群的处理能力.所以对于使用 ORACLE RAC 有以下两个建议：
>
>> 节点间通信使用高速互联网络;
>> 尽可能将不同的应用分布在不同的节点上.
>>

> 基于这个原因,Oracle RAC 通常在 DSS 环境(决策支持系统Decision Support System ,简称DSS)中可以做到很好的扩展性,因为 DSS 环境很容易将不同的任务分布在不同计算节点上,而对于 OLTP 应用(On-Line Transaction Processing联机事务处理系统),Oracle RAC 更多情况下用来提高可用性,而不是为了提高扩展性.

### 1.5.2 MySQL Cluster

> MySQL cluster 和 Oracle RAC 完全不同,它采用 无共享架构Shared nothing(shared nothing architecture).整个集群由管理节点(ndb_mgmd),处理节点(mysqld)和存储节点(ndbd)组 成,不存在一个共享的存储设备.MySQL cluster 主要利用了 NDB 存储引擎来实现,NDB 存储引擎是一个内存式存储引擎,要求数据必须全部加载到内存之中.数据被自动分布在集群中的不同存 储节点上,每个存储节点只保存完整数据的一个分片(fragment).同时,用户可以设置同一份数据保存在多个不同的存储节点上,以保证单点故障不会造 成数据丢失.MySQL cluster 主要由 3 各部分组成：
>
>> SQL 服务器节点
>> NDB 数据存储节点
>> 监控和管理节点
>>

> 这样的分层也是与 MySQL 本身把 SQL 处理和存储分开的架构相关系的.MySQL cluster 的优点在于其是一个分布式的数据库集群,处理节点和存储节点都可以线性增加,整个集群没有单点故障,可用性和扩展性都可以做到很高,更适合 OLTP 应用.但是它的问题在于：
>
>> *NDB(“NDB” 是一种“内存中”的存储引擎,它具有可用性高和数据一致性好的特点.) 存储引擎必须要求数据全部加载到内存之中,限制比较大,但是目前 NDB 新版本对此做了改进,允许只在内存中加 载索引数据,数据可以保存在磁盘上.
>> *目前的 MySQL cluster 的性能还不理想,因为数据是按照主键 hash 分布到不同的存储节点上,如果应用不是通过主键去获取数据的话,必须在所有的存储节点上扫描, 返回结果到处理节点上去处理.而且,写操作需要同时写多份数据到不同的存储节点上,对节点间的网络要求很高.
>>
>
> 虽然 MySQL cluster 目前性能还不理想,但是 share nothing 的架构一定是未来的趋势,Oracle 接手 MySQL之后,也在大力发展 MySQL cluster,我对 MySQL cluster 的前景抱有很大的期待.

### 1.5.3 分布式数据库架构

> MySQL 5 之后才有了数据表分区功能(Sharding), Sharding 不是一个某个特定数据库软件附属的功能,而是在具体技术细节之上的抽象处理,是水平扩展(Scale Out,亦或横向扩展、向外扩展)的解决方案,其主要目的是为突破单节点数据库服务器的 I/O 能力限制,解决数据库扩展性问题.比如 Oracle 的 RAC 是采用共享存储机制,对于 I/O 密集型的应用,瓶颈很容易落在存储上,这样的机制决定后续扩容只能是 Scale Up(向上扩展) 类型,对于硬件成本、开发人员的要求、维护成本都相对比较高.Sharding 基本上是针对开源数据库的扩展性解决方案,很少有听说商业数据库进行 Sharding 的.目前业界的趋势基本上是拥抱 Scale Out,逐渐从 Scale Up 中解放出来.

> Sharding 架构的优势在于,集群扩展能力很强,几乎可以做到线性扩展,而且整个集群的可用性也很高,部分节点故障,不会影响其他节点提供服务.Sharding 原理简单,容易实现,是一种非常好的解决数据库扩展性的案.Sharding 并不是数据库扩展方案的银弹,也有其不适合的场景,比如处理事务型的应用它可能会造成应用架构复杂或者限制系统的功能,这也是它的缺陷所在.读写分离是架构分布式系统的一个重要思想.不少系统整体处理能力并不能同业务的增长保持同步,因此势必会带来瓶颈,单纯的升级硬件并不能一劳永逸.针对业务类型特点,需要从架构模式进行一系列的调整,比如业务模块的分割,数据库的拆分等等.集中式和分布式是两个对立的模式,不同行业的应用特点也决定了架构的思路.如互联网行业中一些门户站点,出于技术和成本等方面考虑,更多的采用开源的数据库产品(如MYSQL),由于大部分是典型的读多写少的请求,因此为 MYSQL 及其复制技术大行其道提供了条件.而相对一些传统密集交易型的行业,比如电信业、金融业等,考虑到单点处理能力和可靠性、稳定性等问题,可能更多的采用商用数据库,比如DB2、Oracle 等.就数据库层面来讲,大部分传统行业核心库采用集中式的架构思路,采用高配的小型机做主机载体,因为数据库本身和主机强大的处理能力,数据库端一般能支撑业务的运转,因此,Oracle 读写分离式的架构相对MYSQL 来讲,相对会少.读写分离架构利用了数据库的复制技术,将读和写分布在不同的处理节点上,从而达到提高可用性和扩展性的目的.最通常的做法是利用 MySQL Replication 技术,Master DB 承担写操作,将数据变化复制到多台 Slave DB上,并承担读的操作.这种架构适合 read-intensive 类型的应用,通过增加 Slave DB 的数量,读的性能可以线性增长.为了避免 Master DB 的单点故障,集群一般都会采用两台 Master DB 做双机热备,所以整个集群的读和写的可用性都非常高.除了 MySQL,Oracle 从11g 开始提供 Active Standby 的功能,也具备了实现读写分离架构的基础.读写分离架构的缺陷在于,不管是 Master 还是 Slave,每个节点都必须保存完整的数据,如 果在数据量很大的情况下,集群的扩展能力还是受限于单个节点的存储能力,而且对于 Write-intensive 类型的应用,读写分离架构并不适合.

> 采用 Oracle 读写分离的思路,Writer DB 和 Reader DB 采用日志复制软件实现实时同步; Writer DB 负责交易相关的实时查询和事务处理,ReaderDB 负责只读接入,处理一些非实时的交易明细,报表类的汇总查询等.同时,为了满足高可用性和扩展性等要求,对读写端适当做外延,比如 Writer DB 采用 HA 或者RAC 的架构模式,目前,除了数据库厂商的集群产品以外,解决数据库扩展能力的方法主要有两个：数据分片和读写分离.数据分片(Sharding)的原理就是将数据做水平切分,类似于 hash 分区的原理,通过应用架构解决访问路由和Reader DB 可以采用多套,通过负载均衡或者业务分离的方式,有效分担读库的压力.

> 对于 Shared-nothing 的数据库架构模式,核心的一个问题就是读写库的实时同步;另外,虽然 Reader DB只负责业务查询,但并不代表数据库在功能上是只读的.只读是从应用角度出发,为了保证数据一致和冲突考虑,因为查询业务模块可能需要涉及一些中间处理,如果需要在数据库里面处理(取决与应用需求和设计),所以Reader DB 在功能上仍然需要可写.下面谈一下数据同步的技术选型问题：

> 能实现数据实时同步的技术很多,基于 OS 层(例如 VERITAS VVR),基于存储复制(中高端存储大多都支持),基于应用分发或者基于数据库层的技术.因为数据同步可能并不是单一的 DB 整库同步,会涉及到业务数据选择以及多源整合等问题,因此 OS 复制和存储复制多数情况并不适合做读写分离的技术首选.基于日志的 Oracle 复制技术,Oracle 自身组件可以实现,同时也有成熟的商业软件.选商业的独立产品还是 Oracle 自身的组件功能,这取决于多方面的因素.比如团队的相应技术运维能力、项目投入成本、业务系统的负载程度等.

> 采用 Oracle 自身组件功能,无外乎 Logical Standby、Stream 以及 11g 的 Physical Standby(Active Data Guard),对比来说,Stream 最灵活,但最不稳定,11g Physical Standby 支持恢复与只读并行,但由于并不是日志的逻辑应用机制,在读写分离的场景中最为局限.如果技术团队对相关技术掌握足够充分,而选型方案的处理能力又能支撑数据同步的要求,采用 Oracle 自身的组件完全可行.选择商业化的产品,更多出于稳定性、处理能力等考虑.市面上成熟的 Oracle 复制软件也无外乎几种,无论是老牌的 Shareplex,还是本土 DSG 公司的RealSync 和九桥公司的 DDS,或是 Oracle 新贵 Goldengate,都是可供选择的目标.随着 GoldenGate 被 Oracle 收购和推广,个人认为 GoldenGate 在容灾、数据分发和同步方面将大行其道.当然,架构好一个可靠的分布式读写分离的系统,还需要应用上做大量设计,不在本文讨论范围内.

### 1.5.4 CAP和BASE理论

> 分布式领域 CAP 理论：
>
>> Consistency(一致性), 数据一致更新,所有数据变动都是同步的
>> Availability(可用性), 好的响应性能
>> Partition tolerance(分区容错性) 可靠性
>>

> 定理：任何分布式系统只可同时满足二点,没法三者兼顾.
> 忠告：架构师不要将精力浪费在如何设计能满足三者的完美分布式系统,而是应该进行取舍.

> 关系数据库的 ACID 模型拥有 高一致性 + 可用性 很难进行分区：
>
>> Atomicity 原子性：一个事务中所有操作都必须全部完成,要么全部不完成.
>> Consistency 一致性. 在事务开始或结束时,数据库应该在一致状态.
>> Isolation 隔离层. 事务将假定只有它自己在操作数据库,彼此不知晓.
>> Durability. 一旦事务完成,就不能返回.
>>

### 1.5.5 跨数据库事务

> 2PC (two-phase commit), 2PC is the anti-scalability pattern (Pat Helland) 是反可伸缩模式的,也就是说传统关系型数据库要想实现一个分布式数据库集群非常困难,关系型数据库的扩展能力十分有限.而近年来不断发展壮大的 NoSQL(非关系型的数据库)运动,就是通过牺牲强一致性,采用 BASE 模型,用最终一致性的思想来设计分布式系统,从而使得系统可以达到很高的可用性和扩展性.那么,有没有可能实现一套分布式数据库集群,既保证可用性和一致性,又可以提供很好的扩展能力呢？

> BASE 思想的主要实现有按功能划分数据库 sharding 碎片BASE 思想主要强调基本的可用性,如果你需要 High 可用性,也就是纯粹的高性能,那么就要以一致性或容错性为牺牲,BASE 思想的方案在性能上还是有潜力可挖的.

> 共同点：都是关系数据库 SQL 以外的可选方案,逻辑随着数据分布,任何模型都可以自己持久化,将数据处理和数据存储分离,将读和写分离,存储可以是异步或同步,取决于对一致性的要求程度.
> 不同点：NOSQL 之类的 Key-Value 存储产品是和关系数据库头碰头的产品 BOX,可以适合非 Java 如 PHP RUBY等领域,是一种可以拿来就用的产品,而领域模型 + 分布式缓存 + 存储是一种复杂的架构解决方案,不是产品,但这种方式更灵活,更应该是架构师必须掌握的.

> 目前,已经有很多分布式数据库的产品,但是绝大部分是面向 DSS 类型的应用,因为相比较 OLTP 应用,DSS 应用更容易做到分布式扩展,比如基于 PostgreSQL 发展的 Greenplum,就很好的解决了可用性和扩展性的问题,并且提供了很强大的并行计算能力.对于OLTP 应用,业务特点决定其要求：高可用性,一致性, 响应时间短,支持事务和 join 等等.数据库和 NoSQL当越来越多的 NoSQL 产品涌现出来,它们具备很多关系型数据库所不具备的特性,在可用性和扩展性方面都可以做到很好.

> 第一,NoSQL 的应用场景非常局限,某个类型的 NoSQL 仅仅针对特定类型的应用场景而设计.而关系型数据库则要通用的多,使用 NoSQL 必须搞清楚自己的应用场景是否适合.
> 第二,利用关系型数据库配合应用架构, 比如 Sharding 和读写分离技术,同样可以搭建出具备高可用和扩展性的分布式数据库集群.
> 第三,关系型数据库厂商依然很强大,全世界有大量的 用户,需求必然会推动新的产品问世.
> 第四,硬件的发展日新月异,比如闪存的技术的不断成熟,未来闪存可以作为磁盘与内存之间的 cache,或者完 全替代磁盘.而内存价格越来越低,容量越来越大,In-memory cache 或 database 的应用越来越广泛,可以给应用带来数量级的性能提升.数据库面临的 IO 问题将被极大改善.

# 二、高可用产品对比

## 2.1 什么是高可用

> HA 是 High Availability可以叫做高可用,或高可用性,高可用(环境), 是分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计减少系统不能提供服务的时间.

> 如果系统每运行100个时间单位,会有1个时间单位无法提供服务,我们说系统的可用性是99%. 很多公司的高可用目标是4个9,也就是99.99%,这就意味着,系统的年停机时间为8.76个小时. 百度的搜索首页,是业内公认高可用保障非常出色的系统,甚至人们会通过baidu能不能访问来判断“网络的连通性”,百度高可用的服务让人留下啦“网络通畅,百度就能访问”,“百度打不开,应该是网络连不上”的印象,这其实是对百度HA最高的褒奖.

> 众所周知,单点是系统高可用的最大的风险和敌人,应该尽量在系统设计的过程中避免单点. 在方法论上高可用保证的原则是“集群化”,或者叫“冗余”. 只有一个单点,挂了服务会受影响；如果有冗余备份,那么挂了还有其它备份能够继续提供服务.

> RAC提供了实例级别的冗余,DG提供了数据存储级别的冗余. 若要保证系统高可用,则架构设计的核心准则是：冗余. 有了冗余之后,还不够,毎次岀现故障需要人工介入恢复势必会增加系统的不可服务实践. 所以,又往往是通过“自动故障转栘″来实现系统的高可用

> Oracle failsafe、Data Guard 和 RAC 均为 ORACLE 公司提供的高可靠性(HA)解决方案.然而之三者之间却存在着很大区别.,但是这几种方案之间却存在着很大区别.

## 2.2 FAILSAFE和RAC的区别

### 2.2.1 操作系统

> Failsafe 系统局限于 WINDOWS 平台,必须配合 MSCS(microsoft cluster server),而 RAC 最早是在 UNIX 平台推出的,目前已扩展至 LINUX 和 WINDOWS 平台,通过 OSD(operating system dependent)与系统交互.对于高端的 RAC 应用,UNIX 依然是首选的平台.

### 2.2.2系统结构

> FAILSAFE 采用的是 SHARE NOTHING 结构,即采用若干台服务器组成集群,共同连接到一个共享磁盘系统,在同一时刻,只有一台服务器能够访问共享磁盘,能够对外提供服务.只要当此服务器失效时,才有另一台接管共享磁盘.RAC 则是采用 SHARE EVERYTHING,组成集群的每一台服务器都可以访问共享磁盘,都能对外提供服务.也就是说 FAILSAFE 只能利用一台服务器资源,RAC 可以并行利用多台服务器资源.

### 2.2.3运行机理

> 组成 FAILSAFE 集群的每台 SERVER 有独立的 IP,整个集群又有一个 IP,另外还为 FAILSAFE GROUP 分配一个单独的 IP(后两个 IP 为虚拟 IP,对于客户来说,只需知道集群 IP,就可以透明访问数据库).工作期间,只有一台服务器(preferred or owner or manager)对外提供服务,其余服务器(operator)成待命状,当前者失效时,另一服务器就会接管前者,包括FAILSAFE GROUP IP与CLUSTER IP,同时FAILSAFE会启动上面的DATABASE SERVICE,LISTENER 和其他服务.客户只要重新连接即可,不需要做任何改动.对于 RAC 组成的集群,每台服务器都分别有自已的 IP,INSTANCE 等,可以单独对外提供服务,只不过它们都是操作位于共享磁盘上的同一个数据库.当某台服务器失效后,用户只要修改网络配置,如(TNSNAMES.ORA),即可重新连接到仍在正常运行的服务器上.但和 TAF 结合使用时,甚至网络也可配置成透明的.

### 2.2.4集群容量

> 前者通常为两台,后者在一些平台上能扩展至 8 台.

### 2.2.5分区

> FAILSAFE 数据库所在的磁盘必须是 NTFS 格式的,RAC 则相对灵活,通常要求是 RAW,然而若干 OS 已操作出了 CLUSTER 文件系统可以供 RAC 直接使用.综上所述,FAILSAFE 比较适合一个可靠性要求很高,应用相对较小,对高性能要求相对不高的系统,而 RAC则更适合可靠性、扩展性、性能要求都相对较高的较大型的应用.

## 2.3 RAC和OPS区别

> RAC 是 OPS 的后继版本,继承了 OPS 的概念,但是 RAC 是全新的,CACHE 机制和 OPS 完全不同.RAC 解决了 OPS 中 2 个节点同时写同一个 BLOCK 引起的冲突问题. 从产品上来说 RAC 和 OPS 是完全不同的产品,但是我们可以认为是相同产品的不同版本

## 2.4 双机热备、RAC、DG、OGG的区别

> RAC和DG是高可用体系中的常用的两种工具,每个工具既可以独立应用,也可以相互配合使用. 但是它们各自的侧重点不同,适用场景也不同.

> RAC是本地的高可用集群,每个节点用来分担不同或相同的应用,以解决运算效率低下、单点故障这样的问题,它是几台硬件相同或不相同的服务器加一个共享存储来构成的. RAC的强项在于解决单点故障和负载均衡,所以,RAC方案常用于7*24的核心系统,但RAC方案中的数据只有一份,尽管可以通过RAID等机制避免存储故障,但是数据本身是没有冗余的,因此需要加强备份.

> DG是Oracle的远程复制技术,它有物理和逻辑之分,但是总的来说,它需要在异地有一套独立的系统,是一种异地容灾的解决方案. DG通过冗余数据的方式来提供数据保护,通过日志同步机制保证冗余数据和主库之间的同步,这种同步可以是实时、延时、同步或异步等多种形式. DG常用于异地容灾和小企业的高可用性方案,可以在备库上执行只读地查询操作,从而分散主库的性能压力.

> OGG软件是一种基于日志的结构化数据复制备份软件,它通过解析源数据库在线日志或归档日志获得数据的增量变化,再将这些变化应用到目标数据库,从而实现源数据库与目标数据库的同步. OGG可以实现一对一、广播(一对多)、聚合(多对一)、双向复制、层叠、点对点、级联等多种灵活的拓扑结构,可以实现只复制某几个表的功能.

|                  | 双机热备                                           | OPS                           | RAC                                                                              | Dataguard                                                                                   | OGG                                |
| ------------------ | ---------------------------------------------------- | ------------------------------- | ---------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | ------------------------------------ |
| 共享存储         | 不是                                               | 有                            | 有                                                                               | 有                                                                                          | 不是                               |
| 高可用           | 有                                                 | 有                            | 有                                                                               | 有                                                                                          |                                    |
| 保护类型         | 热备只是一个实例,一个数据库,做不了并发和负载均衡   | 实例冗余,负载均衡             | 实力层冗余                                                                       | 数据库层冗余                                                                                | Schema或表级别冗余                 |
| 需要的软硬件资源 | 只有两台机器和磁盘整列,有一个漂移的IP,不能共享存储 | 两台机器和磁盘阵列,两个虚拟IP | 可有多台机器和磁盘阵列,一个节点有一个虚拟IP                                      | 有独立的机器和独立的磁盘                                                                    | 有独立机器和独立存储               |
| 优缺点           | Failsafe是免费的,一台服务器闲置硬件浪费较大        | 在并发读写性能上较差          | 读写并发性能较好,但是对维护人员的技能和专业要求较高,要单独购买Oracle Cluster软件 | 是一个轻量级的容灾系统,在10g以上的版本中还能在备用节点上提供,读写功能和自动进行故障转移功能 | 可以在表或者schema级别实现实时复制 |

### 2.4.1 双机热备份方式

> 这种方式的主要缺点在于:
> 由于需要重新启动数据库在双机热备份方式下, **数据库系统平时只能在一台服务器** (例如服务器A上运行,另一台服务器无法直接访问数据库,自然也无法进行负载分担.当服务器A由于故障失效时,由相应的操作系统软件控制,将服务器A管理的存储设备(如硬盘)转交给服务器B控制,同时在服务器B上启动另一个数据库实例,管理数据库.这种切换并启动新的数据库核心的过程一般需要几十秒到几分钟.

> *核心进程,无法保证数据库系统连续不间断地运行;
> *在系统切换的过程中,客户端与服务器之间的数据库连接会中断,需要重新进行数据库的连接和登录工作;
> *由于数据库系统只能在一台服务器上运行,另一台服务器无法分担系统的负载,实际上造成了客户投资的浪费.在有些系统中,为了解决双机负载分担的问题,将应用系统人为分割为两个数据库系统分别在两台服务器上运行.这种方式在一定程度上解决了负载分担的问题,但给系统管理、统计分析等业务处理带来了很多额外的复杂性

### 2.4.2 RAC方式

> RAC 是 real application cluster 的简称,它是在多个主机上运行一个数据库的技术,即是一个 db 多个instance.它的好处是可以由多个性能较差的机器构建出一个整体性能很好的集群,并且实现了负载均衡,那么当一个节点出现故障时,其上的服务会自动转到另外的节点去执行,用户甚 至感觉不到什么.

> 在并行服务器方式下,两台(或多台)服务器上各自运行一个数据库核心进程,但共同管理、操作一个数据库.客户端无论连接到哪个服务器都可以在数据库中进行操作.当服务器A由于故障失效时,数据库系统本身并未停止工作,连接在服务器B上的客户端还可以继续进行正常工作.同时,服务器B上也不需要再启动新的数据库服务器进程,因此也没有“切换时间″.对于一些特殊应用中严格要求前端应用不能中断的情况,orac1e并行服务器还提供了一种“预连接(pre-connect)"方式,以这种方式连接的客户端当服务器端发生故障时,客户端与数据库服务器的连接不会中断,会被orac1e并行服务器软件自动转接到还在正常工作的其它服务器上,不需要重新输入用户名及口令.

#### 2.4.2.1 相对于双机热备份方式

> 同样有许多操作系统平台支持并行服务器方式的高可用性方案,例如HP MC Service Guard OPS Edition与双机热备份方式相比,Orac1e Real Application cluster并行服务器方式有以下优点:
>
>> 1).各服务器共享—个数据库,在正常运行时可以进行负载分担,无需考虑应用数据的人为分割
>> 2).并行服务器方式对应用完全透明,在应用程序设计和开发的过程中也不需要进行特殊编程,简化了开发的复杂程度,同时今后系统扩展也无需修改应用程序
>> 3).不需要重新启动数据库核心进程,缩短了故障造成的停机时间
>>

#### 2.4.2.2 RAC的好处

> 具有 Cache fusion体系结构的 Oracle Real Application Clusters为企业应用开发提供了以下好处
> 1).
> 应用系统灵活和毫不费力的伸缩性;应用用户可以登录到单独的虛拟高性能集群服务器.向数据库切加节点非常容易,并且当需要添加处理器节点或者业务需求变化时,不用手工对数据进行分区.对于所有的应用即时提供集群的可伸缩性--不用修改应用程序
> 2).
> 较之传统集群数据库体系结构的高可用性解決方案;该体系结枃为客户提供了几乎连续的数据访可,使硬件和软件故障导致的业务中断最小化.系统具备对多个节点失败的容错能力,使部件失败屏蔽开最终用户
> 3).
> 单独的管理实体;为了进行所有管理操作,在集群中保持一个单独的系统映像.DBA一次性地进行安装、配置、备份、升级以及监控等功能,然后σ racle将管理功能自动分配到适宜的节点.这意味着DBA只管理着一个虚拟服务器.
> 4).
> Cache fusion保存了所有orac1e客户在他们应用中学习和开发orac1e的投资.所有单节点数据库功能都保留下来,并且应用程序使用相同标准的σ racle接口连接到数据库上.

#### 2.4.2.3 可伸缩性

> 基于RAC应用的用户或者中间层应用服务器客户,可以通过虚拟数据库服务连接到数据库上.Oracle在集群中多个节点之间自动平衡用户负载.不同节点上的 Real Application Clusters数据库实例预订所有数据库服务或者部分子集数据库服务.这使得DBA高度灵活地选定,连接到特定数据库服务的特定应用程序客户是否可以连接到某些或者全部的数据库节点.虽然毎一个节点有一个不同的物理IP地址时,应用客户仍可以在一个逻辑数据库服务名的水平上进行连接.因此客户端对于不相关的事情如多服务器的多个地址可以毫不关心.随着业务的增长,应用系统可以从容地增加处理能力.Cache fusion体系结构直接地利用新节点的CPU和内存资源.DBA无需用手工对数据重新分区.这个优点是这种体系结构的副产品,因为有透明度的数据存取是 Cache fusion的一项基本功能.Cache fusion体系机构自动适应快速变化的应用需求及随之而来的工作负荷的改变.DBA也不必因为工作负荷变化而对数据进行手工的重新分区.Real Application Clusters通过动态地重新分配数据库资源,从而在节点之间用最小化的磁盘I/O和低的延迟通信来优化利用集群系统资源.这使得Real Application Clusters可以从容实现增加的应用吞吐量和优化的响应时间

#### 2.4.2.4 高可用

> Real Application Clusters提供了真正的高可用性解决方案,关键的突破是在大多数数据库恢复期间能提供完整的数据库访问,这使得Real Application Clusters成为应用所要求的24x7可用性的最佳平台.

> Real Application clusters在高可用性上在三个关键领域胜出
> 1).提供了数据库恢复期间的数据块访问
> 2).透明的失效转移对最终用户屏蔽了系统失效
> 3).N-1节点失效的容错能力

> 只要有一个数据库节点幸存,Real Application Clusters就能够提供完全的数据库访问和相对不间断的操作.

#### 2.4.2.5 可管理性

> Real Application cluster实现了真正意义上的一个单系统访问数据库,它提供了从任何节点到所有磁盘设备和远程高速缓存进行无缝数据访问的能力.此单系统映像延伸到所有数据库管理操作.安装、配置、备份、升级以及监控等操作只需进行一次,然后会自动发布到集群中所有节点上去.各种race工具(如Oracle Universal Installer、Database Configuration Assistant以及Recovery Manager)将发现集群数据块中所有不同的节点并以它们为目标分配给想得到的任务.通过为特定的管理操作选择多个目标节点,管理任务在数据库集群中多个节点上执行.这为应用系统管理其环境带来了极大的可伸缩性上的经济实惠.例如,向数据库集群添加一个节点只会增加最小的管理任务.这样,Real Application Clusters支持在线商务应用和决策支持之类的应用,并且为数据访问和管理提供了单一的虚拟高性能服务器.

#### 2.4.2.6 总结

> 1).对于硬件来说基本上一样,共享存储、光纤线(也有还用SCSI线的)、多台小型机(可以做多节点的相互热备,也可以做多节点的RAC)、光纤交换机(如果是用光纤卡的话);但做RAC,在主机之间,最好使用高带宽网络交换机(虽然不用也可以做成),硬件成本相差不大.
> 2).软件如果是双机热备,必须买操作系统級的双机管理软件;如果是RλC目前还是建议购买双机管理软件(尽管10g的εrs+asm可以摆脱双机软件了,但ASM目前实在太难伺候了),当然还得买RAC License.

# 三、Oracle集群概念和原理

## 3.1Oracle的三种高可用集群方案

### 3.1.1 RAC(Real Application Clusters)

![请输入图片描述](https://cdn.jsdelivr.net/gh/klausyao/imageshosting/oracle/rac/rac/image01.gif)

> 多个Oracle服务器组成一个共享的Cache,而这些Oracle服务器共享一个基于网络的存储.这个系统可以容忍单机/或是多机失败.不过系统内部的多个节点需要高速网络互连,基本上也就是要全部东西放在在一个机房内,或者说一个数据中心内.如果机房出故障,比如网络不通,那就坏了.所以仅仅用RAC还是满足不了一般互联网公司的重要业务的需要,重要业务需要多机房来容忍单个机房的事故.

### 3.1.2 Data Guard(最主要的功能是冗灾)

![](https://cdn.jsdelivr.net/gh/klausyao/imageshosting/oracle/rac/rac/image02.gif)

?Data Guard这个方案就适合多机房的.某机房一个production的数据库,另外其他机房部署standby的数据库.Standby数据库分物理的和逻辑的.物理的standby数据库主要用于production失败后做切换.而逻辑的standby数据库则在平时可以分担production数据库的读负载.

### 3.1.3 MAA

![](https://cdn.jsdelivr.net/gh/klausyao/imageshosting/oracle/rac/rac/image03.gif)

> MAA(Maximum Availability Architecture)其实不是独立的第三种,而是前面两种的结合,来提供最高的可用性.每个机房内部署RAC集群,多个机房间用Data Guard同步.

## 3.2 RAC概述

> RAC(Real application Clusters)实时应用集群是高可用的一种,9i前RAC称为OPS(Oracle Parallel Server),RAC和OPS最大的区别是,RAC采用了 Cashe Fusion(缓存容和) 技术 ,节点已经取出的数据块更新后没有写入磁盘前,可以被另外一个节点更新,然后以最后的版本写入磁盘.在 OPS 中,节点间的数据请求需要先将数据写入磁盘,然后发出请求的节点才可以读取该数据.使用Cache fusion时,RAC的各个节点的数据缓冲区通过高速、低延迟的内部网络进行数据块的传输.

> 下图是一个典型的 RAC 对外服务的示意图,一个Oracle RAC Cluster 包含了如下的部分

````bash
集群的节点(Cluster node)			——2个到N个节点或者主机运行Oracle Database Server.
私有网络(Network Interconnect)		——RAC之间需要一个高速互联的私有网络来处理通信和Cache Fusion.
共享存储(shared Storage)			——RAC需要共享存储设备让所有的节点都可以访问数据文件.
对外服务的网络(Production Network)	——RAC对外服务的网络.客户端和应用都通过这个网络来访问.
````

![](https://cdn.jsdelivr.net/gh/klausyao/imageshosting/oracle/rac/rac/image04.gif)

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

## 3.3 RAC集成集群件管理

> Oracle RAC 10g 在 Oracle 数据库 10g 运行的所有平台上提供了一个完整集成的集群件管理解决方案.这一集群件功能包括集群连接、消息处理服务和锁定、集群控制和恢复,以及一个工作负载管理框架(将在下文探讨).Oracle RAC 10g 的集成集群件管理具有以下优势：
>
>> (一) 成本低.Oracle 免费提供这一功能.
>> (二) 单一厂商支持.消除了相互推诿的问题.
>> (三) 安装、配置和持续维护更简单.Oracle RAC 10g 集群件使用标准 Oracle 数据库管理工具进行安装、配置和维护.这一过程无须其它的集成步骤.
>> (四) 所有平台,质量始终如一.与第三方产品相比,Oracle 对新软件版本进行了更严格的测试.
>> (五) 所有平台,功能始终如一.例如,一些第三方集群件产品限制了集群内可以支持的节点的数量.借助Oracle RAC 10g,所有平台可以支持多达 64 个节点.用户还可以在所有平台上获得一致的响应体验,从而有效解决了高可用性挑战,包括服务器节点故障、互连故障以及 I/O 隔离现象等.
>> (六) 支持高级功能.这包括集成监视和通知功能,从而在发生故障时,在数据库和应用层之间实现快速协调的恢复.
>>

## 3.4 RAC的体系结构

### 3.4.1 RAC结构图

> RAC 是 Oracle 数据库的一个群集解决方案,是有着两个或者两个以上的数据库节点协调运作能力的.如下图所示的 RAC 结构图：

![](https://cdn.jsdelivr.net/gh/klausyao/imageshosting/oracle/rac/rac/image05.gif)

![](https://cdn.jsdelivr.net/gh/klausyao/imageshosting/oracle/rac/rac/image06.gif)

> 集群管理器(Cluster Manager)在集群系统中对其他各个模块进行整合,通过高速的内连接来提供群集节点之间的通信.各节点之间内连接使用心跳线互联,心跳线上的信息功能确定群集逻辑上的节点成员信息和节点更新情况,以及节点在某个时间点的运行状态,保证群集系统正常运行.通信层管理节点之间的通信.它的职责是配置,互联群集中节点信息,在群集管理器中使用由心跳机制产生的信息,由通信层负责传输,确保信息的正确到达.还有一些群集监视进程不断验证系统的不同领域运行状况.例如,心跳监测不断验证的心跳机制的运作是否良好.在一个应用环境当中,所有的服务器使用和管理同一个数据库,目的是分散每一台服务器的工作量.硬件上至少需要两台以上的服务器,而且还需要一个共享存储设备;同时还需要两类软件,一类是集群软件,另外一类就是 Oracle 数据库中的 RAC 组件.同时所有服务器上的 OS 都应该是同一类 OS,根据负载均衡的配置策略,当一个客户端发送请求到某一台服务的 listener 后,这台服务器根据负载均衡策略,会把请求发送给本机的 RAC组件处理,也可能会发送给另外一台服务器的 RAC 组件处理,处理完请求后,RAC 会通过群集软件来访问共享存储设备.逻辑结构上看,每一个参加群集的节点有一个独立的实例,这些实例访问同一个数据库.节点之间通过集群软件的通信层(Communication Layer)来进行通信.同时为了减少 I/O 的消耗,存在一个全局缓存服务,因此每一个数据库的实例,都保留了一份相同的数据库 cache.

### 3.4.2 RAC后台进程

> Oracle RAC 有一些自己独特的后台进程,在单一实例中不发挥配置作用.如下图所示,定义了一些 RAC 运行的后台进程.这些后台进程的功能描述如下.

![](https://cdn.jsdelivr.net/gh/klausyao/imageshosting/oracle/rac/rac/image07.gif)

#### 3.4.2.1 LMS(Global cache service processes全局缓存服务进程)

> RAC中特别的实例进程,控制到远端实例的消息的流量,管理全局数据块的访问.还用于在不同实例的缓冲区之间传递 BLOCK 的映射.

> 进程主要用来管理集群内数据块的访问,并在不同实例的 Buffer Cache 中传输数据块镜像.直接从控制的实例的缓存复制数据块,然后发送一个副本到请求的实例上.并保证在所有实例的 Buffer Cache 中一个数据块的镜像只能出现一次.LMS进程靠着在实例中传递消息来协调数据块的访问,当一个实例请求数据块时,该实例的 LMD 进程发出一个数据块资源的请求,该请求指向主数据块的实例的 LMD 进程,主实例的 LMD 进程和正在使用的实例的 LMD 进程释放该资源,这时拥有该资源的实例的 LMS 进程会创建一个数据块镜像的一致性读然后把该数据块传递到请求该资源的实例的BUFFER CACHE 中.LMS 进程保证了在每一时刻只能允许一个实例去更新数据块,并负责保持该数据块的镜像记录(包含更新数据块的状态FLAG).RAC 提供了 10 个 LMS 进程(0~9),该进程数量随着节点间的消息传递的数据的增加而增加.

#### 3.4.2.2 LMON(Lock Monitor Process,锁监控进程)

> 监视全局队列和集群间的资源交互,执行全局队列的恢复操作.
> 是全局队列服务监控器,各个实例的 LMON 进程会定期通信,以检查集群中各个节点的健康状况,当某个节点出现故障时,负责集群重构、GRD 恢复等操作,它提供的服务叫做 Cluster Group Service(CGS).

> LMON主要借助两种心跳机制来完成健康检查.
> (一) 节点间的网络心跳(Network
> Heartbeat)：可以想象成节点间定时的发送 ping 包检测节点状态,如果能在规定时间内收到回应,就认为对方状态正常.
> (二) 通过控制文件的磁盘心跳(controlfile heartbeat)：每个节点的 CKPT 进程每隔 3 秒钟更新一次控制文件的数据块,这个数据块叫做 Checkpoint Progress Record,控制文件是共享的,所以实例间可以互相检查对方是否及时更新来判断.

#### 3.4.2.3 LMD(the global enqueue service daemon,锁管理守护进程)

> 管理全局队列和全局资源访问.对于每个实例,LMD 管理来自远端的资源请求.

> 是一个后台进程,也被称为全局的队列服务守护进程,因为负责对资源的管理要求来控制访问块和全局队列.在每一个实例的内部,LMD 进程管理输入的远程资源请求(即来自集群中其他实例的锁请求).此外,它还负责死锁检查和监控转换超时.

#### 3.4.2.4 LCK(the lock process,锁进程)

> 管理除 Cache Fusion 以外的非数据块资源请求,比如数据文件,控制文件,数据字典试图,library 和 row cache 的请求.

> 管理非缓存融合,锁请求是本地的资源请求.LCK 进程管理共享资源的实例的资源请求和跨实例调用操作.在恢复过程中它建立一个无效锁元素的列表,并验证锁的元素.由于处理过程中的 LMS 锁管理的首要职能,只有一个单一的 LCK 进程存在每个实例中.

#### 3.4.2.5 DIAG(the diagnosability daemon,诊断守护进程)

> 在实例中捕获进程失败的诊断数据.

> 负责捕获 RAC 环境中进程失败的相关信息.并将跟踪信息写出用于失败分析,DIAG 产生的信息在与 Oracle Support 技术合作来寻找导致失败的原因方面是非常有用的.每个实例仅需要一个 DIAG 进程.

#### 3.4.2.6 GSD(the global service daemon,全局服务进程)

> 在每个节点上都运行一个全局服务后台进程,用于接收客户端如DBCA、EM 等发出的管理消息,并完成相应的管理任务,比如实例的启动和关闭.

> 与 RAC 的管理工具 dbca、srvctl、oem 进行交互,用来完成实例的启动关闭等管理事务.为了保证这些管理工具运行正常必须在所有的节点上先start gsd,并且一个 GSD 进程支持在一个节点的多个 rac.gsd 进程位ORACLEHOME/bin目录下,其log文件为ORACLE_HOME/srvm/log/gsdaemon.log.GCS 和GES 两个进程负责通过全局资源目录(Global Resource Directory GRD)维护每个数据的文件和缓存块的状态信息.当某个实例访问数据并缓存了数据之后,集群中的其他实例也会获得一个对应的块镜像,这样其他实例在访问这些数据是就不需要再去读盘了,而是直接读取 SGA 中的缓存.GRD 存在于每个活动的 instance 的内存结构中,这个特点造成 RAC 环境的 SGA 相对于单实例数据库系统的 SGA 要大.其他的进程和内存结构都跟单实例数据库差别不大.

### 3.4.3 RAC全局服务

#### 3.4.3.1 Global Enqueue Service

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

#### 3.4.3.2 Global Cache Service

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

#### 3.4.3.3 RAC的GES/GCS原理

> 本地资源协调的机制和单实例 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(异步锁陷阱)来锁定进程,这样可以要求这些进程把当前的持有锁置为较低级限制的模式.资源是内存结构,这些结构代表了数据库中的组件,对这些组件的访问必须为限制模式或者串行化模式.换一句话说,这个资源只能被一个进程或者一直实例并行访问.如果这个资源当前是处于使用状态,其他想访问这个资源的进程必须在队列中等待,直到资源变得可用.队列是内存结构,它负责并行化对特殊资源的访问.如果这些资源只被本地实例需求,那么这个队列可以本地来获得,而且不需要协同.但是如果这个资源被远程实例所请求,那么本地队列必须变成全球化.

#### 3.4.3.4 GCS和GES特性

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

## 3.5 RAC中的特点

> 1).每一个节点的实例都有自己的SGA;
> 2).每一个节点的实例都有自己的后台进程
> 3).每一个节点的实力都有自己的redo logs
> 4).每一个节点的实例都有自己的undo 表空间
> 5).所有节点都共享一份datafiles 和 controlfiles

## 3.6RAC优缺点

#### 3.6.1 优点

> 1).RAC是一种<span style='color:green'>双机并行模式</span>,并非主备模式
> 也就是说,RAC集群的所有成员都可以同时接受客户端的请求.所以,RAC实现了容错、单点故障解决(如果有节点挂掉,那么其它节点可以继续提供服务)和多节点负载均衡(不同节点可以相互配合,分担负载)
> 2).提供高可用:
> 故障容错和无缝切換功能将硬件和软件错误造成的影响最小化,能够保证在集群中只要有一个节点存活,就能正常对外提供服
> 3).通过并行执行技术提高事务响应时间,通常被用于OLAP系统
> 4).通过横向扩展提高每秒交易数和连接数,通常被用于LTP系统
> 5).扩展了机器的负載能力,节约了硬件成本,可以用多个廉价PC( PersonalComputer)服务器代替昂贵的小型机或大型机,同时节约相应维护成本
> 6).易伸缩、可扩展性好,可以方便添加、删除节点,扩展硬件资源
> 7).实现了业务分割处理
> 8).低成本.
> 能使用较低廉的服务器来实现高可用性、高吞吐量的集群环境,这要比通过对某台高端服务器增加硬件实现高可用性、高吞吐量花费的成本低很多
> 9).高吞吐量.
> 随着节点数的増加,整个RAC的吞吐量也在不断増长.

### 3.6.2 缺点

> 1).相对单机,由于底层技术复杂,所以,管理更复杂,对DBA的技术要求更高
> 2).可能会増加软件成本 (如果使用高配置的PC服务器,那么orac1e一般按照CPU个数收费)
> 3).在RAC系统规划设计较差时性能可能会不如单节点,存在资源争用(Cache Fusion)

# 四、RAC相关组件

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

## 4.1 集群软件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 组成的集群.

### 4.1.1 集群软件

> 从 Oracle10g 起,Oracle 提供了自己的集群软件,叫做 Oracle Clusterware,简称 CRS,这个软件是安装 oraclerac 的前提,而上述第三方集群则成了安装的可选项.

> 同时提供了另外一个新特性叫做ASM,可以用于 RAC 下的共享磁盘设备的管理,还实现了数据文件的条带化和镜像,以提高性能和安全性 (S.A.M.E: stripe and mirror everything ) ,不再依赖第三方存储软件来搭建 RAC系统.尤其是 Oracle11gR2 版本不再支持裸设备,Oracle将全力推广 ASM,彻底放弃第三方集群组件支持.

#### 4.1.2 Clusterware的启动脚本

```bash
#自动启动的脚本/etc/inittab里定义：
OCSSD(Clustery Synchronization Service)	提供心跳机制监控集群状态
CRSD(Clustery Ready Service)		提供高可用、干预、关闭、重启、转移服务.
DISK HEARTBEAT
NETWORK HEARBEAT
#资源包括
nodeapps、database-related		前者每个节点只需要一个即可正常工作,后一个与数据库相关,不受节点限制,可以为多个.
EVMD					该进程负责发布 CRS 产生的各种事件,还是 CRS 和 CSS 两个服务之间通信的桥梁
RACGIMON				该进程检查数据库健康状态,包括数据库服务的启动、停止和故障转移.属于持久连接,定期检查 SGA.
OPROCD(Process Monitor Daemon)		检测 CPU hang(非Linux平台使用)
```

### 4.1.3 Clusterware后台进程

#### 4.1.3.1 OPROCD

> 集群进程管理 —Process monitor for the cluster. 用于保护共享数据 IO fencing.仅在没有使用 vendor 的集群软件状态下运行

#### 4.1.3.2 EVMD

> 事件检测进程,由 oracle 用户运行管理

#### 4.1.3.3 CRS/CRSD

> Cluster Ready Service(CRS,集群准备服务)是管理集群内高可用操作的基本程序. 其进程是CRSD.
> CRS负责集群的高可用操作,管理的 crs 资源包括数据库、实例、监听、虚拟 IP,ons,gds 或者其他,操作包括启动、关闭、监控及故障切换.
> 该进程由 root 用户管理和启动.crsd 如果有故障会导致系统重启.

> CRS是根据存储于OCR中的资源配置信息来管理这些资源的.这包括启动、关闭、监控及故障切换(start、stop、monitor 及 failover)操作.当一资源的状态改变时,CRS 进程生成一个事件.当你安装 RAC 时,CRS 进程监控Oracle 的实例、监听等等,并在故障发生时自动启动这些组件.默认情况下,CRS 进程会进行 5 次重启操作,如果资源仍然无法启动则不再尝试.

```bash
Event Management(EVM)			：发布 CRS 创建事件的后台进程.
Oracle Notification Service(ONS)	：通信的快速应用通知
Fast Application Notification (FAN)	：事件的发布及订阅服务.
RACG					：为clusterware进行功能扩展以支持Oracle的特定需求及复杂资源.它在FAN事件发生时执行服务器端的调用脚本(server callout script)
Process Monitor Daemon(OPROCD)		：此进程被锁定在内存中,用于监控集群(cluster)及提供 I/O 防护(I/Ofencing).OPROCD 执行它的检查,停止运行,且如果唤醒超过它所希望的间隔时,OPROCD 重置处理器及重启节点.一个 OPROCD 故障将导致 Clusterware 重启节点.
```

#### 4.1.3.4 CSS/CSSD

> Cluster Synchronization Service(CSS)：CSS 集群同步服务,管理集群配置.其进程是CSSD
> 管理各节点的关系,用于节点间通信,节点在加入或离开集群时通知集群.是集群环境中进程间通信的基础.
> 该进程由 oracle 用户运行管理.发生故障时 cssd 也会自动重启系统.

> 同样,CSS 也可以用于在单实例环境中处理 ASM 实例与常规 RDBMS 实例之间的交互作用.
> 在集群环境中,CSS 还提供了组服务,即关于在任意给定时间内哪些节点和实例构成集群的动态信息,以及诸如节点的名称和节点静态信息(这些信息在节点被加入或者移除时被修改).
> CSS 维护集群内的基本锁功能(尽管大多数锁有 RDBMS 内部的集成分布式锁管理来维护).

> 除了执行其他作业外,CSS 还负责在集群内节点间维持一个心跳的程序,并监控投票磁盘的split-brain 故障.
> 在安装 clusterware 的最后阶段,会要求在每个节点执行 root.sh 脚本,这个脚本会在/etc/inittab 文件的最后把这 3 个进程加入启动项,这样以后每次系统启动时,clusterware 也会自动启动,其中 EVMD 和CRSD 两个进程如果出现异常,则系统会自动重启这两个进程,如果是 CSSD 进程异常,系统会立即重启.

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

## 4.2 RAC共享存储

> 共享存储文件系统(NFS),或甚至集群文件系统(如：OCFS2)主要被用于存储区域网络(所有节点直接访问共享文件系统上存储器),这就使得节点失效而不影响来自其他节点对文件系统的访问,通常,共享磁盘文件系统用于高可用集群.

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

> RAC共享存储独立于实例之外的信息,如ocr和votedisk以及数据文件都存放在这个共享存储里的.有OCFS、OCFS2、RAW、NFS、ASM 等这样的一些存储方式.

> OCFS(Oracle Cluster File System) 和 OCFS2 就是一个文件系统而已,和 NFS 一样,提供一种集群环境中的共享存储的文件系统.
> RAW 裸设备也是一种存储方式,是 oracle11g 之前的版本中 RAC 支持的存储方式,在 Oralce9i 之前,OPS/RAC的支持只能使用这样的方式,也就是把共享存储映射到 RAW Device,然后把 Oracle 需要的数据选择 RAW device存储,但是 RAW 相对于文件系统来说不直观,不便于管理,而且 RAW Device 有数量的限制,RAW 显然需要有新的方案来代替,这样就有了 OCFS 这样的文件系统.当然,这只是 Oracle 自己的实现的集文件系统而已,还有其他厂商提供的文件系统可以作为存储的选择方案.

> ASM 只是数据库存储的方案而已,并不是 cluster 的方案,所以这里 ASM 应该是区别于 RAW 和 OCFS/OCFS2同一级别的概念,RAW 和 OCFS/OCFS2 不仅可以作为数据库存储的方案,同时也可以作为 Clusterware 里的存储方案,是 CRS 里需要的 storage,而 ASM 仅作为数据库的存储而已,严格来说仅是 RAC 中的一个节点应用(nodeapps).ASM 对于 clusterware 安装时需要的 ocr 和 votedisk 这两项还不支持,毕竟 ASM 本身就需要一个实例,而 CRS 是完全在架构之外的,这也就是为什么使用了 ASM 的方案,却总还要加上 OCFS/OCFS2 和 RAW 其中的一个原因.

> 各种 RAC 共享存储方式的对比如下：
>
> ```bash
> 集群文件系统		——支持 windows 和 Linux 的 OCFS/OCFS2
> AIX 下的 GPFS 等方式	——优点是管理方便,表示也很直观,但缺点是基于文件系统管理软件,又要经过 OS 的 cache 处理,性能上和稳定性上都有欠缺,所以不适合在生产环境下使用.可以支持 CRS 集群软件文件和数据库文件.
> RAW 裸设备方式		——通过硬件支持的共享存储系统,直接用 RAW 设备存储,可以支持集群软件文件和数据库文件.
> 网络文件系统(NFS)	——通过 NFS 实现共享存储,不过需要经过 Oracle 认证的 NFS 才行,可以支持CRS 集群软件文件和数据库文件.
> ASM			——集合 RAW 方式 I/O 高性能和集群文件系统易管理等优点,Oracle10g 下推出的共享存储方式,但是本身 ASM 就是需要 Oracle 的实例支持,所以 ASM 仅支持数据库文件,而不支持 CRS 文件.
>
> ```

## 4.3 集群IP的网络通信

### 4.3.1 规划

> 从oracle开始,安装RAC至少需要7个地址两块网卡(块公网网卡,一块私网卡),其中pub1ic、vip和scan都在同一个网段,使用的是公网网卡,private在另一个网段,使用的是私网网卡.主机名不能包含下横线,如：RAC_01是不允许的.通过执行ifconfig -a检查两个节点的网络设备名称是否致.另外,在配置了/etc/hosts文件后,在安装RAC之前,公网、私网共4个IP可以ping通,其它3不能ping通才是正常的.在安装RAC时,其Ip地址的规划类似于下表所示：

| Host Name | Interface Name | Type         | IP Address     |
| ----------- | ---------------- | -------------- | ---------------- |
| rac01     | rac01          | 公共/Public  | 192.168.10.101 |
| rac01     | rac01-vip      | 虚拟/Virtual | 192.168.10.201 |
| rac01     | rac01-priv     | 私有/Private | 192.168.20.101 |
| rac02     | rac02          | 公共/Public  | 192.168.10.102 |
| rac02     | rac02-vip      | 虚拟/Virtual | 192.168.10.202 |
| rac02     | rac02-priv     | 私有/Private | 192.168.20.102 |
| scan      | scan           | scan         | 192.168.10.100 |

> 在hosts如下所示配置
>
> ```bash
> #Public IP
> 192.168.10.101	rac01
> 192.168.10.102	rac02
> #Private IP
> 192.168.20.101	rac01-priv
> 192.168.20.102	rac02-priv
> Virtual IP
> 192.168.10.201	rac01-vip
> 192.168.10.202	rac02-vip
> #Scan IP
> 192.168.10.100	scan
> ```

### 4.3.2 节点间的通信(Interconnect)

#### 4.3.2.1 通信网络

> 通常在 RAC 环境下,在公用网络的基础上,需要配置两条专用的网络用于节点间的互联,在 HACMP/ES 资源的定义中,这两条专用的网络应该被定义为"private".在实例启动的过程中,RAC 会自动识别和使用这两条专用的网络,并且如果存在公用"public"的网络,RAC 会再识别一条公用网络.当 RAC 识别到多条网络时,RAC会使用 TNFF (TransparentNetwork Failvoer Failback) 功能,在 TNFF 下所有的节点间通信都通过第一条专用的网络进行,第二条( 或第三条等) 作为在第一条专用的网络失效后的备份.RAC 节点间通信如下图所示.

![](https://cdn.jsdelivr.net/gh/klausyao/imageshosting/oracle/rac/rac/image08.gif)

> CLUSTER_INTERCONNECTS是在 Oracle RAC 中的一个可选的初始化(init.ora) 参数.此参数可以指定使用哪一条网络用于节点间互联通信,如果指定多条网络,RAC 会在这些网络上自动进行负载均衡.然而,当CLUSTER_INTERCONNECTS 设置时,TNFF 不起作用,这将降低 RAC 的可用性,任何一条节点间互联网络的失效,都会造成 RAC 一个或多个节点的失效.ORACLE RAC 用于 INTERCONNECT 的内网卡的物理连接方式的选择：采用交换机连接或是网线直连.直连的弊端是,一旦一个节点机的内网卡出现故障,oracle 从 OS 得到两个节点的网卡状态都是不正常的,因而会导致两个实例都宕掉.在INTERCONNECT 线路出现问题的时候,oracle一般情况下会启动一个竞争机制来决定哪个实例宕掉,如果宕掉的实例正好是好的实例的话, 这样就会导致两个实例都宕掉.在 9i 中,oracle 在启动竞争机制之前,会先等待一段时间,等待 OS 将网络的状态发给 oracle,如果在超时之前,oracle 获得哪个实例的网卡是 down 的话,则将该实例宕掉,这样的话,则可以保留正常的那个实例继续服务,否则还是进入竞争机制.

> 综上所述节点间通信分为两种情况：
> 1).是接在交换机上面,此时一般情况下,是会保证正常的实例继续服务的,但有的时候如果 os 来不及将网卡状态送到 oracle 时,也是有可能会导致两个节点都宕掉的.
> 2).如果是直连的话,则会导致两个实例都宕掉.

#### 4.3.2.2 CSS心跳

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

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

### 4.3.3 Public IP

> Public IP称为公网IP,它是网卡上的真实IP.每个节点在安装Oracle软件之前都需要事先配置Public IP.Oracle通过Public IP对外提供网络服务.如果RAC中Public IP所在的网卡设备故障,那么该节点将无法继续对外提供服务,所以,建议通过开启操作系统层面的多网卡绑定技术来实现IP Failover.如果是双节点RAC环境,那么需要在tnsnames.ora文件中写入对应两个节点的Public IP、端口号以及通信协议.如果没有开启负载均衡功能(软/硬件),那么当tnsnames.ora文件中第一个ADDRESS对应的主机故障或关机,那么在客户端连接时,Oracle会等待一个网络超时,然后继续连接第二个ADDRSS对应的数据库实例.即使RAC一个节点依然可以对外提供服务,用户每次连接都需要等待几秒钟.网络超时会让用户体验相当不好.所以,在Oracle 10g RAC中VIP(Virtual IP)的出现完美地解决了这个问题.

### 4.3.4 Private IP

> 专用网络

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

> 对于Oracle集群,私网通信是非常重要的,因为节点和节点之间的通信绝大部分都是要通过私网来实现的.私网通信基本上可以分为两种：第一种是集群层面之间的通信；第二种是数据库实例之间的通信.第一种通信(例如：节点间的网络心跳)的主要特点是持续存在、实时性要求高,但是数据量比较小,所以通过TCP/IP协议传递就可以了.第二种通信是缓存融合(Cache Fusion)造成的实例之间的数据传输,其特点是数据量很大,而且速度要求非常高,TCP/IP协议此时已经不能满足要求了,所以需要使用UDP或者RDS,同时Oracle也一直建议用户对集群的私网进行高可用性和负载均衡的配置.

> 与Public IP一样,Private IP称为私网IP或心跳IP,它也是网卡上的真实IP,每个节点在安装Oracle集群软件之前都需要事先配置Private IP.Private IP用于集群间多节点心跳同步和Cache Fusion等任务,在Oracle 12c中还需要担任Flex ASM的任务.当然,如果不设置Private IP而是由Public IP也可以去完成这些任务.但是,这样做只会使Public IP所在网卡负载过大,一旦网卡设备发生故障,集群将会分裂踢出掉一部分节点保证一致性,使RAC性能不稳定.对于Oracle 10g和11gR1版本的集群,Oracle并不提供私网的高可用性和负载均衡特性,而是建议用户在操作系统层面配置(例如Linux bonding、AIX etherchannel等),从而开启操作系统层面的多网卡绑定技术实现IP Failover.从Oracle 11.2.0.2版本开始推出的HAIP技术提供了私网的高可用性和负载均衡特性,从而替代了操作系统层面的网卡绑定技术,功能更强大更兼容.

### 4.3.5 Virtual IP(VIP)

#### 4.3.5.1 概述

> VIP是Oracle 10g RAC的新特性,称为虚拟IP.VIP是在Public IP所在的网卡上由Oracle集群软件虚拟出来的一个IP,需要和Public IP设置在同一个子网网段中.Oracle集群软件安装之前只需定义好(/etc/hosts文件)即可,而无需事先配置.

> 在正常情况下,VIP和Public IP的功能是一样的.后台进程PMON对每个节点的VIP所在的监听器注册实例信息,本地监听器中会看到两个地址host,一个是Public IP,一个是VIP.

> 当节点故障时,Oracle集群软件会把VIP自动飘逸到其它节点上,但是本地监听器却没有飘逸到其它节点上.客户端tnsnames.ora文件中host选项不再需要配置Public IP而选择配置VIP,这样做的好处是在双节点RAC架构中当第一个节点故障时,第二个节点会有两个VIP,客户端连接第一个VIP失败后会立即连接第二个VIP对应的实例,整个切换过程是非常短暂的,用户完全感受不到RAC架构中有节点故障.

> 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 的连接请求.
>>

> 整个连接过程可以说对用户是透明了.但是并非真正意义上的透明,用户还是可以知道整个RAC架构是由多少个节点组成,所以,Oracle 11g RAC中推出了SCAN IP的新概念,可以实现对用户连接的透明性,用户不再需要知道整个RAC架构中是由多少个节点组成的.

#### 4.3.5.2 VIP的特点

```bash
VIP是通过VIPCA脚本创建的.
VIP作为Nodeapps类型的CRS Resource注册到OCR中,并由CRS维护状态.
VIP会绑定到节点的Public网卡上,故Public网卡有两个地址.
当某个节点发生故障时,CRS会把故障节点的VIP转移到其它节点上.
每个节点的LISTENER会同时监听Public网卡上的Public IP和VIP.
客户端的tnsnames.ora一般会配置指向节点的VIP.
```

```bash
#可以使用如下命令让节点1的VIP强制漂移到节点2上去：
crsctl relocate resource ora.r01.vip -n ra02 -f
#以下命令针对Oracle 11g版本之前：
crs_relocate ora.rac01.vip -c rac02 -f
```

#### 4.3.5.3 VIP漂移实验

### 4.3.6 SCAN IP

> 从Oracle 11gR2 RAC开始引入SCAN(Single Client Access Name,集群的单客户端访问名称)IP的概念,相当于在客户端和数据库之间增加一层虚拟的网络服务层,即是SCAN IP和SCAP IP LISTENER.在客户端的tnsnames.ora配置文件中,只需要配置SCAN IP,然后用户即可访问数据库.客户端通过SCAN IP、SCAN IP LISTENER来负载均衡地连接到RAC数据库.同之前各版本的RAC相比,使用SCAN IP的好处就是,当后台RAC数据库添加、删除节点时,客户端配置信息无需修改.SCAN提供一个域名来访问RAC,域名可以解析1个到3个(注意,最多3个)SCAN IP,可以通过DNS、GNS或/etc/hosts文件来解析实现.需要注意的是,SCAN IP、VIP和Public IP必须属于同一子网.

### 4.3.7 GNS VIP

> GNS VIP是Oracle 11g RAC新特性.在传统RAC架构中,Public IP、Private IP、Virtual IP、SCAN IP都是预先配好的.如果开启了GNS服务只需要预先配置Public IP、Private IP即可,Virtual IP、SCAN IP都是由GNS服务从DHCP服务器动态获取的.配置GNS服务需要事先配置DNS和DHCP服务,GNS VIP可以绑定在任意一个节点的Public网卡上来实现GNS服务,如果没有配置GNS服务就不需要配置GNS VIP.配置起来相对传统架构来说复杂一些,所以,在Oracle 11g RAC架构中很少会看到GNS VIP.12c Flex Cluster架构必须配置GNS VIP.

### 4.3.8 HAIP(Highly Available IP)

#### 4.3.8.1 概述

> 在Oracle 11.2.0.2之前,私网的冗余一般是通过在OS上做网卡绑定(如Bond等)来实现的,从Oracle 11.2.0.2版本开始推出HAIP(Highly Available IP)技术替代了操作系统层面的网卡绑定技术,功能更强大、更兼容.HAIP通过其提供的独特的169.254.*网段的IP地址实现集群内部链接的高可用及负载均衡.所以,在11.2.0.2或更高版本安装RAC的时候需要注意169.254.*的IP地址不能被占用.有了HAIP技术则可以不再需要借助任何第三方的冗余技术来实现私网网卡的冗余.

> 资源ora.cluster_interconnect.haip将会启动一个到四个本地HAIP地址附在Private网络适配器上(私网网卡).通过HAIP完成Oracle RAC和ASM等内部通讯.如果某一个私有网卡物理损坏,那么该网卡上的HAIP地址会漂移到其它的可用的私有网络上.多个私网网卡可以在安装阶段定义,也可以在GRID配置完成之后,通过调用$GRID_HOME/bin/oifcfg setif工具(命令为：oifcfg setif -global eth2/192.168.1.0:cluster_interconnect)来配置HAIP.

> HAIP的个数取决于GRID激活的私网网卡的个数.如果只有1块私网网卡,那么GRID将会创建1个HAIP.如果有两块私网网卡,那么GRID将会创建两个HAIP.若超过两块私网网卡则GRID创建4个HAIP.GRID最多支持4块私网网卡,而集群实际上使用的HAIP地址数则取决于集群中最先启动的节点中激活的私网网卡数目.如果选中更多的私网网卡作为Oracle的私有网络,那么多余4个的不能被激活.

> 管理ora.cluster_interconnect.haip资源的是ohasd.bin进程.
> 其对应的log位于这两个位置.
> GRID_HOME/log/<nodename>/ohasd/ohasd.log
> GRID_HOME/log/<nodename>/agent/ohasd/orarootagent_root/orarootagent_root.log

> 在HAIP资源online以后,通过操作系统命令ifconfig -a就能查看到多了类似于eth1:1的虚拟网卡,HAIP地址为169.254.X.X.当然也可以在数据库级别通过GV$CLUSTER_INTERCONNECTS视图查看HAIP的地址.HAIP对应的地址由系统自动分配,无法由用户手工进行指定.

> Oracle数据库和ASM实例可以通过HAIP来实现私网通讯的高可用性和负载均衡.私网的流量会在这些私网网卡上实现负载均衡,如果某个网卡出现了故障,它上面的HAIP会自动切换到别的可用的私网网卡上,从而不影响私网的通讯.Windows平台目前不支持HAIP技术.

> 在有些客户环境下,私网是通过VLAN划出来的,而出于网络管理要求,VLAN的IP地址与网卡必须是绑定的,私网IP也必须是固定的IP地址(虽然按Oracle RAC的安装要求,私网应该是独立隔离的网络),这时HAIP会无法分配,导致依赖它的ASM资源无法启动.HAIP存在不少Bug,若不幸碰到,则可以将HAIP功能禁用掉.如果用户使用的是操作系统级别的绑定或者没有使用私网的绑定,那么可以通过在RDBMS和ASM的参数文件中设置CLUSTER_INTECONNECTS指定私网地址将HAIP覆盖(如果有多个私网地址,请用英文冒号分隔).虽然说HAIP本身依然存在,但是ASM实例和RDBMS实例以后就不会使用HAIP.

#### 4.3.8.2 HAIP漂移实验

#### 4.3.8.3 禁用HAIP

### 4.3.9 透明应用切换(TAF)

> 透明应用故障转移(Transport Application Failover,TAF)是 oracle 数据提供的一项,普遍应用于 RAC 环境中,当然也可以用于 Data Guard 和传统的 HA 实现的主从热备的环境中.TAF 中的 Transparent 和 Failover,点出了这个高可用特性的两大特点：
> 1).TAF 是用于故障转移的,也就是切换.当 Oracle 连接的会话由于数据库发生故障不可用时,会话能够自动切换到 RAC 中的其他可用的节点上,或者切换到 Standby 上面,或者切换到 HA 方式中的另一个可用的节点上面.
> 2).TAF 的故障转移,对应用来说是透明的,应用系统不需要进行特别的处理就能够自动进行故障转移.

> 但是,TAF 是完美的吗？是不是使用了 TAF,应用就能真的无缝地进行切换呢？对应用和数据库有没有其他什么要求？要回答这些问题,我们需要全面地了解、掌握 TAF.我始终认为,要用好一个东西,首先得掌握这个东西背后的工作原理与机制.

> 首先来看看 Failover.Failover 有两种,一种是连接时 Failover,另一种则是运行时Failover.前者的作用在于,应用(客户端)在连接数据库时,如果由于网络、实例故障等原因,连接不上时,能够连接数据库中的其他实例.后者的作用在于,对于一个已经在工作的会话(也就是连接已经建立),如果这个会话的实例异常中止等,应用(客户端)能够连接到数据库的其他实例(或备用库).

### 4.3.10 TAF配置测试

### 4.3.11 连接负载均衡

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

## 4.4 集群心跳

> Oracle Clusterware 使用两种心跳设备来验证成员的状态,保证集群的完整性.
> l  一是对 voting disk 的心跳,ocssd 进程每秒向 votedisk 写入一条心跳信息.
> l  二是节点间的私有以太网的心跳.

> 两种心跳机制都有一个对应的超时时间,分别叫做 misscount 和 disktimeout：
> l  misscount 用于定义节点间心跳通信的超时,单位为秒;
> l  disktimeout ,默认 200 秒,定义 css 进程与 vote disk 连接的超时时间;

> reboottime ,发生裂脑并且一个节点被踢出后,这个节点将在reboottime 的时间内重启;默认是 3 秒.用下面的命令查看上述参数的实际值：
> l  # crsctl get css misscount
> l  # grep misscount $CRS_HOME/log/hostname/cssd/ocssd.log

> 在下面两种情况发生时,css 会踢出节点来保证数据的完整,：
> (一) Private Network IO time > misscount,会发生 split brain 即裂脑现象,产生多个“子集群”(subcluster) ,这些子集群进行投票来选择哪个存活,踢出节点的原则按照下面的原则：节点数目不一致的,节点数多的 subcluster 存活;节点数相同的,node ID 小的节点存活.
> (二) VoteDisk I/O Time > disktimeout ,踢出节点原则如下：失去半数以上 vote disk 连接的节点将在
> reboottime 的时间内重启.例如有 5 个 vote disk,当由于网络或者存储原因某个节点与其中>=3 个 vote disk 连接超时时,该节点就会重启.当一个或者两个 vote disk 损坏时则不会影响集群的运行.

### 4.4.1 ocssd和css

> OCSSD是一个管理及提供Cluster Synchronization Services (CSS)服务的或者Unix进程.使用Oracle用户来运行该进程并提供节点成员管理功能,一旦该进程失败,将导致节点重启.CSS服务提供2种心跳机制,一种为网络心跳,一种为磁盘心跳.两种心跳都有最大延时,网络心跳的延时叫MC(Misscount), 磁盘心跳延时叫作IOT (I/O Timeout). 这2个参数都以秒为单位,缺省时情况下Misscount <Disktimeout.

### 4.4.2 三种心跳

> 在几乎所有高可用的环境中都有心跳的存在,心跳的主要目的是为了检测集群中节点的状态.如果检测失败,那么管理软件会认为某个节点存在故障,并根据一定的算法来做出适当地处理,避免对环境的破坏,即高可用性软件进行自动修复.

> Oracle集群有3种心跳机制,分别为网络心跳(Network HeartBeat,NHB)、磁盘心跳(Disk HeartBeat,DHB)和本地心跳(Local HeartBeat,LHB)

| 心跳类型                                                                            | 简介                                                                                                                                                          | 参数及查询语句                             | 默认值                |
| ------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------- | ----------------------- |
| 网络心跳 (Network Heartbeat,NHB)                                                    | 网络心跳主要是为了通过私有网络来确定集群节点之间的连通性,以便节点之间了解彼此的状态.对于Oracle集群,ocssd.bin守护进程会每秒通过**私网**向其他节点发送网路心跳. | MC (misscount)**crsctl get css misscount** | 之前60s 11gR2 之后30s |
| 磁盘心跳 (Disk Hearbeat,DHB)                                                        | 为了当集群发生脑裂时可以帮助指定脑裂的解决方案.每个节点都会向集群的所有表决盘(voting                                                                          |                                            |                       |
| disk)注册本节点的磁盘心跳信息(写个记录到表决盘).通常每个节点也要赌一次磁盘心跳数据. | LIOT (Long I/O Timeout)或disktimeount**crsctl get css disktimeout**                                                                                           | 200s                                       |                       |
| 本地心跳 (Local Heartbeat LHB)                                                      | 11gR2引入的,作用是监控ocssd.bin进程以及本地节点的状态.                                                                                                        | MC (misscount)**crsctl get css misscount** | 30s                   |

```bash
[grid@rac01 rac01]$ crsctl get css misscount
CRS-4678: Successful get misscount 30 for Cluster Synchronization Services.

[grid@rac01 rac01]$ crsctl get css disktimeout
CRS-4678: Successful get disktimeout 200 for Cluster Synchronization Services.
```

> 在默认情况下,上表中的参数是Oracle自动判定的,并且不建议调整(可以通过命令“crsctl set css”来调整).由于本地心跳和网络心跳都是由相同的线程来发送的,所以,本地心跳和网络心跳的延迟时间是一样的,默认都是30s.网络心跳和磁盘心跳是由OCSSD进程来检测的.所以,网络和存储的稳定是一方面,OCSSD进程的稳定对RAC的稳定运行也至关重要.

### 4.4.3 网络心跳机制

> 故名思义即是通过私有网络来检测节点的状态.如果私有网络硬件、软件导致集群节点间私有网络在一定时间内无法进行正常通信,由此而导致脑裂.由于集群环境中的存储为共享存储,因此此时必须要将故障节点从 集群隔离出来,以避免数据灾难.

> 上面的查询结果表明,如果集群各节点间内联网络延迟大于30s,Oracle认为节点间发生了脑裂,需要将故障节点逐出集群.

> 如何寻找故障节点,Oracle则通过投票算法来决定,下面是一个算法描述示例,描述参考大话Oracle RAC.

> 集群中各个节点需要心跳机制来通报彼此的"健康状态",假设每收到一个节点的"通报"代表一票.
> 对于三个节点的集群,正常运行时,每个节点都会有3票.当结点A心跳出现故障但节点A还在运行,这时整个集群就会分裂成2个小的partition. 节点A是一个,剩下的2个是一个. 这是必须剔除一个partition才能保障集群的健康运行. 对于这3个节点的集群, A心跳出现问题后, B 和 C 是一个partion,有2票, A只有1票. 按照投票算法, B 和C 组成的集群获得控制权, A 被剔除.

> 如果只有2个节点,投票算法就失效了. 因为每个节点上都只有1票. 这时就需要引入第三个设备：**Quorum Device.** Quorum Device 通常采用的是共享磁盘,这个磁盘也叫作Quorum disk. 这个Quorum Disk 也代表一票. 当2个结点的心跳出现问题时, 2个节点同时去争取Quorum Disk 这一票, 最早到达的请求被最先满足.故最先获得Quorum Disk的节点就获得2票.另一个节点就会被剔除.

> 节点一旦被隔离之后,在11gR2之前通常是重启故障节点.而在11gR2中,ClusterWare会首先尝试关闭该节点的所有资源,尝试对集群中失败的组建进行清理,即重启失败的组件.如果清理失败的组件未成功,为了强制清理,则再对节点进行重启.

### 4.4.4 磁盘心跳机制

> 每个节点会每一秒钟更新一次表决磁盘.共享的表决磁盘用于检查磁盘心跳.如果ocssd进程更新表决磁盘的时间超过200s,即disktimeout设定的值,Oracle会认为该表决磁盘脱机,同时在Clusterware的告警日志中生成表决磁盘脱机记录.如果当前节点表决磁盘脱机的个数小于在线表决磁盘的个数,该节点能够幸存,如果脱机表决磁盘的个数大于或等于在线表决磁盘的个数,则clusterware认为磁盘心跳出现问题,故障节点会被逐出集群,执行自动修复过程.

> 比如有3个表决磁盘,节点A有表决磁盘出现了脱机,此时脱机磁盘(1个)<在线磁盘(2),clusterware会在告警日志中生成脱机记录,但不采取任何行动.如果当前节点有2个或2个以上表决磁盘脱机,此时脱机磁盘(2个)>在线磁盘(1个),那节点A被踢出集群.

### 4.4.5 Reboottime

关于心跳还有一个参数为reboottime(short I/O timeout),该参数表示节点被踢出之后,节点开始重启允许的最大时间,默认为3s,如下所示

```bash
[grid@rac01 rac01]$ crsctl get css reboottime
CRS-4678: Successful get reboottime 3 for Cluster Synchronization Services.
```

> 从结果可以看出,当前节点被踢出集群之后允许开始重启的最大时间是3秒.
> 在下面两种情况发生时,css 会踢出节点来保证数据的完整,：
> (一) Private Network IO time > misscount,会发生 split brain 即裂脑现象,产生多个“子集群”(subcluster) ,这些子集群进行投票来选择哪个存活,踢出节点的原则按照下面的原则：节点数目不一致的,节点数多的 subcluster 存活;节点数相同的,node ID 小的节点存活.
> (二) VoteDisk I/O Time > disktimeout ,踢出节点原则如下：失去半数以上 vote disk 连接的节点将在
> reboottime 的时间内重启.例如有 5 个 vote disk,当由于网络或者存储原因某个节点与其中>=3 个 vote disk 连接超时时,该节点就会重启.当一个或者两个 vote disk 损坏时则不会影响集群的运行.

### 4.4.6 查看心跳配置

```sql_more
#对于一个已经有的系统,可以用下面几种方法来确认数据库实例的心跳配置,包括网卡名称、IP 地址、使用的网络协议.
#最简单的方法,可以在数据库后台报警日志中得到.使用 oradebug
SQL> oradebug setmypid
Statement processed.
SQL> oradebug ipc
Information written to trace file.
SQL> oradebug tracefile_name
/oracle/admin/ORCL/udump/orcl2_ora_24208.trc
#找到对应 trace 文件的这一行：socket no 7 IP 10.0.0.55 UDP 16878
#从数据字典中得到：
SQL> select * from v$cluster_interconnects;
SQL> select * from x$ksxpia;

```

### 4.4.7 心跳调优和设置

> 为了避免心跳网络成为系统的单一故障点,简单地我们可以使用操作系统绑定的网卡来作为Oracle 的心跳网络,以 AIX 为例,我们可以使用 etherchannel 技术,假设系统中有 ent0/1/2/3 四块网卡,我们绑定 2 和 3 作为心跳：在 HPUX 和 Linux 对应的技术分别叫 APA 和 bonding

> UDP 私有网络的调优当使用 UDP 作为数据库实例间 cache fusion 的通信协议时,在操作系统上需要调整相关参数,以提高 UDP传输效率,并在较大数据时避免出现超出 OS 限制的错误：

> (一) UDP 数据包发送缓冲区：大小通常设置要大于(db_block_size*db_multiblock_read_count )+4k,
> (二) UDP 数据包接收缓冲区：大小通常设置 10 倍发送缓冲区;
> (三) UDP 缓冲区最大值：设置尽量大(通常大于 2M)并一定要大于前两个值;

> 各个平台对应查看和修改命令如下：
>
> ```bash
> #Solaris 查看 
> ndd /dev/udp udp_xmit_hiwat udp_recv_hiwat udp_max_buf ;
> #修改 ndd -set /dev/udp udp_xmit_hiwat 262144
> ndd -set /dev/udp udp_recv_hiwat 262144
> ndd -set /dev/udp udp_max_buf 2621440
> #AIX 查看 
> no -a |egrep “udp_|tcp_|sb_max”
> #修改 no -p -o udp_sendspace=262144
> no -p -o udp_recvspace=1310720
> no -p -o tcp_sendspace=262144
> no -p -o tcp_recvspace=262144
> no -p -o sb_max=2621440
> #Linux 查看 文件/etc/sysctl.conf
> #修改 sysctl -w net.core.rmem_max=2621440
> sysctl -w net.core.wmem_max=2621440
> sysctl -w net.core.rmem_default=262144
> sysctl -w net.core.wmem_default=262144
> #HP-UX 不需要
> #HP TRU64 查看 
> /sbin/sysconfig -q udp
> #修改： 编辑文件/etc/sysconfigtab
> inet: udp_recvspace = 65536
> udp_sendspace = 65536
> #Windows 不需要
> ```

## 4.5 集群日志体系

### 4.5.1 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 的这个节点必须能够访问到故障节点的连接日志,只有把联机日志放在共享存储上才能满足这个要求.

### 4.5.2 Archive log

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

> 1).使用NFS
> 使用NFS 的方式将日志直接归档到存储,例如两个节点,每个节点都有 2 个目录,Arch1,Arch2 分别对应实例 1 和实例 2 产生的归档日志.每个实例都配置一个归档位置,归档到本地,然后通过 NFS 把对方的目录挂到本地.
> 2).实例间归档(CrossInstance Archive CIA)
> 实例间归档(Cross Instance
> Archive)是上一种方式的变种,也是比较常见的一种配置方法.两个节点都创建 2 个目录 Arch1 和 Arch2 分别对应实例 1 和实例 2 产生的归档日志.每个实例都配置两个归档位置.位置 1对应本地归档目录,位置 2 对应另一个实例
> 3).使用ASM使用 ASM 将日志归档到共享存储,只是通过 Oracle 提供的 ASM,把上面的复杂性隐藏了,但是原理都一样.

### 4.5.3 Trace log

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

### 4.5.4 12c之前日志位置

> 在Oracle RAC环境中,对集群中的日志进行定期检查是必不可少的.通过查看集群日志,可以早期定位集群环境中出现的问题,以便将问题消灭在萌芽状态.下面简单介绍一下有关Oracle集群环境中日志的结构,有助于方便快速地查找所需的日志文件

#### 4.5.4.1 alert.log

```bash
[grid@rac01 rac01]$ cd $ORACLE_HOME/log/$HOSTNAME/
```

#### 4.5.4.2 Clusterware后台进程日志

```bash
crsd.log    ：$ORACLE_HOME/log/$HOSTNAME/crsd/crsd.log
ocssd.log   ：$ORACLE_HOME/log/$HOSTNAME/cssd/ocsd.log
evmd.log    ：$ORACLE_HOME/log/$HOSTNAME/evmd/evmd.log
gpnpd.log   ：$ORACLE_HOME/log/$HOSTNAME/gpnpd/gpnpd.log
```

#### 4.5.4.3 Nodeapp日志

```bash
$ORACLE_HOME/log/$HOSTNAME/racg/
```

#### 4.5.4.4 工具执行日志

```bash
$ORACLE_HOME/log/$HOSTNAME/client/
$ORACLE_HOME/log/$HOSTNAME/client/
$ORACLE_HOME/log/$HOSTNAME/racg
```

#### 4.5.5 12c之后日志位置

集群的告警日志已经归于ADR中,目录位置在ORACLE_BASE/diag/crs/$HOSTNAME/crs/trace中

```sql_more
[grid@rac01 ~]$ cd $ORACLE_BASE/diag/crs/$HOSTNAME/crs/trace
[grid@rac01 trace]$ pwd
/u01/app/grid/diag/crs/rac01/crs/trace
--或者使用adrci查看
[grid@rac01 rac01]$ adrci
ADRCI: Release 19.0.0.0.0 - Production on Tue Sep 14 22:30:41 2021
Copyright (c) 1982, 2019, Oracle and/or its affiliates.  All rights reserved.
ADR base = "/u01/app/grid"
adrci> show home
ADR Homes: 
diag/rdbms/_mgmtdb/-MGMTDB
diag/asm/+asm/+ASM1
diag/crs/rac01/crs
diag/clients/user_grid/host_2990272284_110
diag/clients/user_root/host_2990272284_110
diag/tnslsnr/rac01/asmnet1lsnr_asm
diag/tnslsnr/rac01/listener_scan1
diag/tnslsnr/rac01/listener_scan2
diag/tnslsnr/rac01/listener_scan3
diag/tnslsnr/rac01/listener
diag/tnslsnr/rac01/mgmtlsnr
diag/asmcmd/user_grid/rac01
diag/asmcmd/user_oracle/rac01
diag/kfod/rac01/kfod
adrci>
```

## 4.6集群(RAC)的时间同步

> 从Oracle 11gR2 RAC开始,Oracle集群的时间同步可以采用操作系统的NTP(Network Time Protocol)服务,也可以使用Oracle自带的服务CTSS(Cluster Time Synchronization Service).在Oracle 11gR2前,集群的时间是由NTP同步的,而在11gR2后,Oracle引入了CTSS组件.如果NTP没有启用,那么Oracle会自动启用自己的ctssd进程来同步集群时间.

> 当安装程序发现NTP协议处于非活动状态时,安装集群时间同步服务将以活动模式(ACTIVE Mode)自动进行安装并同步所有节点的时间.如果发现配置了NTP,那么以观察者模式(Observer Mode)启动集群时间同步服务CTSS.

> 在RAC中,集群的时间应该是保持同步的,否则可能导致很多问题,例如：依赖于时间的应用会造成数据的错误,各种日志打印的顺序紊乱,这将会影响问题的诊断,严重的可能会导致集群宕机或者重新启动集群时节点无法加入集群.

> NTP和CTSS是可以共存的,且NTP的优先级要高于CTSS,也就是说,如果系统中同时有NTP和CTSS,那么集群的时间是由NTP同步的,而CTSS会处于观察者模式模式,只有当集群关闭所有的NTP服务,CTSS才会处于活动模式.在一个集群中,只要有一个节点的ntp处于活动状态,那么集群的所有节点的CTSS都会处于观察者模式.

> 需要注意的是,要让CTSS处于活动模式,则不仅要关闭NTP服务(/sbin/service ntpd stop),还要删除/etc/ntp.conf文件(mv/etc/ntp.conf /etc/ntp.conf.bak),否则不能启用CTSS.

### 4.6.1 CTSS同步模式

```bash
#可以执行如下命令来关闭NTP服务,启用CTSS同步：
/sbin/service ntpd stop 
mv /etc/ntp.conf /etc/ntp.conf.bak
service ntpd status
chkconfig ntpd off
#可以使用如下命令查看CTSS是否处于ACTIVE状态：
ps -ef|grep ctss
crsctl stat res -t -init
crsctl check ctss
#也可以查看CTSS进程的日志文件：
$GRID_HOME/log/$HOSTNAME/ctssd/octssd.log
#可以使用如下的命令来校验集群的时间：
cluvfy comp clocksync -n all -verbose
```

### 4.6.2 NTP同步模式

```bash
#可以执行如下命令来关闭CTSS服务,开启NTP：
mv /etc/ntp.conf.bak /etc/ntp.conf
service ntpd status
/sbin/service ntpd start
chkconfig ntpd off
ps -ef|grep ntp
#可以使用如下的命令来重启CTSS进程：
crsctl stop res ora.ctssd -init 
crsctl start res ora.ctssd -init
```

### 4.6.3 模拟集群时间不一致

> 如果在生产系统中碰到集群时间不一致,而且差异比较大的时候,CTSS或NTP服务就不能自动来同步这些时间,则此时需要手动来同步集群的时间.在集群时间差异较大的时候,会在ASM和DB的alert日志中产生了类似如下的告警信息,并生成vktm的trace文件：
> Time drift detected. Please check VKTM trace file for more details.
> 通过阅读相关的trace文件也可以获取时间的同步信息

## 4.7 OCR、OLR和VF

### 4.7.1 OCR概念

> Oracle集群使用两种类型的文件来管理集群资源和节点：OCR(Oracle Cluster Registry,Oracle集群注册表)和VF(Voting File,表决磁盘文件).这两种文件必须存放在共享存储上.其中,**OCR** **相当于集群的控制文件,**  **用于解决健忘问题** ,**VF** **用于解决脑裂问题** .在Oracle 11.2中引入一个新的文件,称作OLR(Oracle Local Registry,Oracle本地注册表),它只允许存放在本地.

> Oracle集群软件(Clusterware)把整个集群的配置信息放在共享存储上,这个存储就是OCR磁盘(OCR Disk).

> OCR是Oracle RAC配置信息仓库,它管理集群节点的相关信息及实例到节点的映射信息.因此,OCR的内容非常的重要,对OCR的操作必须确保OCR内容完整性.在整个集群运行过程中,并不是所有节点都能操作OCR磁盘,而只有一个节点能对OCR磁盘进行读写操作,这个节点叫作Master Node.在每个节点的内存中都有一份OCR内容的拷贝,这份拷贝叫作OCR Cache.同时,每个节点都有一个**OCR Process**来读写OCR Cache,但只有一个节点的OCR Process能读写OCR磁盘中的内容.当OCR内容发生改变时,由Master Node的OCR Process负责更新本地和其它节点的OCR Cache内容.

> 需要注意的是,OCR和VF的信息不会被分布到多块磁盘上,如果用一块磁盘保存OCR或VF的话,那么一定会保存完整的OCR和VF信息.

> 所有需要OCR内容的其它进程,比如OCSSD、EVM等都被叫作Client Process.这些进程不会直接访问OCR Cache,而是向OCR Process发送请求,借助OCR Process获得内容.如果想要修改OCR内容,也要由该节点的OCR Process向Master node的OCR process提交申请,由Master OCR Process完成物理的读写,并同步所有节点OCR Cache中的内容.

#### 4.7.1.1 OCR结构

> (一) OCR KEY是树形结构.
> (二) OCR PROCESS 每个节点都有 OCR CACHE的复制,由 ORC MASTER 节点负责更新到 OCR DISK

OCR的结构如下图所示

![](https://cdn.jsdelivr.net/gh/klausyao/imageshosting/oracle/rac/rac/image09.gif)

#### 4.7.1.2 文件位置

> OCR 中保存整个集群的配置信息,配置信息以”Key-Value”的形式并且采用树形结构来保存保存,并没有类似于数据文件的块的概念.其中.在 Oracle 10g 以前,这个文件叫作 Server Manageability Repository(SRVM). 在 Oracle 10g,这部分内容被重新设计,并重名为 OCR.

> 在Oracle Clusterware安装的过程中,安装程序会提示用户指定OCR位置.用户指定的这个位置会被记录在/etc/oracle/ocr.loc(Linux或AIX)或者/var/opt/oracle/ocr.loc(Solaris系统)文件中.Oracle Clusterware在启动时会根据这里面的内容从指定位置读入OCR内容.

```bash
[grid@rac01 trace]$ cd /etc/oracle
[grid@rac01 oracle]$  ls -l 
total 4108
drwxrwx--- 2 root oinstall      58 Feb 28  2021 lastgasp
drwxrwxrwt 2 root oinstall       6 Feb 28  2021 maps
-rw-r--r-- 1 root oinstall     174 Feb 28  2021 ocr.loc
-rw-r--r-- 1 root root           0 Feb 28  2021 ocr.loc.orig
-rw-r--r-- 1 root oinstall      89 Feb 28  2021 olr.loc
-rw-r--r-- 1 root root           0 Feb 28  2021 olr.loc.orig
drwxrwxr-x 5 root oinstall      44 Feb 28  2021 oprocd
drwxr-xr-x 3 root oinstall      19 Feb 28  2021 scls_scr
-rws--x--- 1 root oinstall 4195264 Mar  4  2021 setasmgid
[grid@rac01 oracle]$ more /etc/oracle/ocr.loc
#Device/file +OCR getting replaced by device +OCR/rac-cluster/OCRFILE/registry.255.1065732193 
ocrconfig_loc=+OCR/rac-cluster/OCRFILE/registry.255.1065732193
local_only=false
```

> 其中,ocrconfig_loc指定OCR的位置.如果为OCR指定了镜像(Mirror),那么还会出现选项ocrmirrorconfig_loc,用于定义OCR镜像的位置.local_only指定是否是RAC系统,如果这个值为FALSE,那么表示是RAC系统,如果这个值为TRUE,那么表示是单实例系统(在使用ASM时需要).

#### 4.7.1.3 OCR key文件信息

> 整个OCR的信息是树形结构,有3个大分支.分别是SYSTEM,DATABASE和CRS.每个分支下面又有许多小分支.这些记录的信息只能由root用户修改.
> OCR中通常包含下列内容：
> v 节点成员信息
> v 数据库实例、节点以及其它的映射关系
> v ASM
> v 资源配置信息(vip、services等等)
> v 服务特性(Service characteristics)
> v Oracle集群中相关进程的信息
> v CRS控制的第三方应用程序信息
> 可以使用命令
> ocrdump -local -stdout -xml|more|grep -i \<name\>|sed -e 's/\<NAME\>//g' -e 's/\<\/NAME\>//g'|awk -F . '{print $1,$2,$3}'|uniq

> 将OCR中的内容输出到屏幕上,如下所示：
>
> ```bash
> [grid@rac01 oracle]$ ocrdump -local -stdout -xml|more|grep -i \<name\>|sed -e 's/\<NAME\>//g' -e 's/\<\/NAME\>//g'|awk -F . '{print $1,$2,$3}'|uniq
> <>SYSTEM</>  
> <>SYSTEM crs</> 
> <>SYSTEM crs usersecurity</>
> <>SYSTEM crs deny</>
> <>SYSTEM ORA_CRS_HOME</> 
> <>SYSTEM WALLET</> 
> <>SYSTEM WALLET cssnk</>
> <>SYSTEM GNS</> 
> <>SYSTEM version</> 
> <>SYSTEM version localhost</>
> <>SYSTEM version localhost
> <>SYSTEM version activeversion</>
> <>SYSTEM version activeversion
> <>SYSTEM GPnP</> 
> <>SYSTEM GPnP profiles</>
> <>SYSTEM GPnP profiles
> <>SYSTEM css</> 
> <>SYSTEM css startepochtime</>
> <>SYSTEM css birth_incar</>
> <>SYSTEM css vfpathname</>
> <>SYSTEM css nodenum_hint</>
> <>SYSTEM network</> 
> <>SYSTEM network haip</>
> <>SYSTEM network haip
> <>SYSTEM ASM</> 
> <>SYSTEM credentials</> 
> <>SYSTEM credentials domains</>
> <>SYSTEM credentials domains
> <>SYSTEM credentials targets</>
> <>SYSTEM credentials targets
> <>SYSTEM SITES</> 
> <>SYSTEM SITES rac-cluster</>
> <>SYSTEM SITES rac-cluster
> <>SYSTEM CLUSTER_PROPERTIES</> 
> <>SYSTEM CLUSTER_PROPERTIES CLUSTER_CLASS</>
> <>SYSTEM CLUSTER_PROPERTIES NODE_LIST</>
> <>SYSTEM CLUSTER_PROPERTIES NODE_PRIVIP_LIST</>
> <>SYSTEM CLUSTER_PROPERTIES MULTICAST</>
> <>SYSTEM CLUSTER_PROPERTIES CW_SECURITY</>
> <>SYSTEM CLUSTER_PROPERTIES CW_BASEPORT</>
> <>SYSTEM CLUSTER_PROPERTIES CW_FIXEDPORT</>
> <>SYSTEM CLUSTER_PROPERTIES CW_DISABLED_TLSCIPHERSUITE</>
> <>SYSTEM OPCTTTL</> 
> <>SYSTEM OLR</> 
> <>SYSTEM OLR MANUALBACKUP</>
> <>SYSTEM OLR MANUALBACKUP
> <>SYSTEM OLR BACKUP</>
> <>SYSTEM OLR BACKUP
> <>SYSTEM OCR</> 
> <>SYSTEM OCR OLR_SYNC_KEYS</>
> <>SYSTEM OCR MANUALBACKUP</>
> <>SYSTEM OCR MANUALBACKUP
> <>DATABASE</>  
> <>DATABASE NODEAPPS</> 
> <>DATABASE VIP_RANGE</> 
> <>DATABASE LOG</> 
> <>DATABASE ASM</> 
> <>DATABASE DATABASES</> 
> <>CRS</> 
> ```

### 4.7.2 OCR命令

#### 4.7.2.1 ocrdump

> 该命令能以ASCII的方式打印出OCR的内容,但是这个命令不能用作OCR的备份恢复,也就是说产生的文件只能用作阅读,而不能用于恢复.

> 命令格式：ocrdump [-stdout][filename] [-keyname name] [-xml]
> 参数说明：
> -stdout:把内容打印输出到屏幕上
> Filename：内容输出到文件中
> -keyname：只打印某个键及其子健内容
> -xml：以xml格式打印输出

示例：把SYSTEM.css键的内容以.xml格式打印输出到屏幕
这个命令在执行过程中,会在$CRS_HOME/log/<node_name>/client目录下产生日志文件,文件名ocrdump_<pid>.log,如果命令执行出现问题,可以从这个日志查看问题原因

```bash
[grid@rac01 oracle]$ ocrdump -stdout -keyname SYSTEM.css -xml|more
<OCRDUMP>
<TIMESTAMP>09/14/2021 22:57:07</TIMESTAMP>
<COMMAND>/u01/app/19.3.0/grid/bin/ocrdump.bin -stdout -keyname SYSTEM.css -xml </COMMAND>
<KEY>
<NAME>SYSTEM.css</NAME>
<VALUE_TYPE>UNDEF</VALUE_TYPE>
<VALUE><![CDATA[]]></VALUE>
<USER_PERMISSION>PROCR_ALL_ACCESS</USER_PERMISSION>
<GROUP_PERMISSION>PROCR_CREATE_SUB_KEY</GROUP_PERMISSION>
<OTHER_PERMISSION>PROCR_CREATE_SUB_KEY</OTHER_PERMISSION>
<USER_NAME>root</USER_NAME>
<GROUP_NAME>root</GROUP_NAME>

<KEY>
<NAME>SYSTEM.css.interfaces</NAME>
<VALUE_TYPE>UNDEF</VALUE_TYPE>
<VALUE><![CDATA[]]></VALUE>
<USER_PERMISSION>PROCR_ALL_ACCESS</USER_PERMISSION>
<GROUP_PERMISSION>PROCR_CREATE_SUB_KEY</GROUP_PERMISSION>
<OTHER_PERMISSION>PROCR_READ</OTHER_PERMISSION>
<USER_NAME>grid</USER_NAME>
<GROUP_NAME>oinstall</GROUP_NAME>

<KEY>
<NAME>SYSTEM.css.interfaces.global</NAME>
<VALUE_TYPE>UNDEF</VALUE_TYPE>
<VALUE><![CDATA[]]></VALUE>
<USER_PERMISSION>PROCR_ALL_ACCESS</USER_PERMISSION>
<GROUP_PERMISSION>PROCR_ALL_ACCESS</GROUP_PERMISSION>
<OTHER_PERMISSION>PROCR_READ</OTHER_PERMISSION>
<USER_NAME>grid</USER_NAME>
<GROUP_NAME>oinstall</GROUP_NAME>
```

#### 4.7.2.2 ocrcheck

> ocrcheck命令用于检查OCR内容的一致性,命令执行过程会在$CRS_HOME/log/nodename/client目录下产生ocrcheck_pid.log日志文件. 这个命令不需要参数.
>
> ```bash
> [grid@rac01 ~]$ ocrcheck
> Status of Oracle Cluster Registry is as follows :
>          Version                  :          4
>          Total space (kbytes)     :     491684
>          Used space (kbytes)      :      84616
>          Available space (kbytes) :     407068
>          ID                       : 1360080956
>          Device/File Name         :       +OCR
>                                     Device/File integrity check succeeded
>
>                                     Device/File not configured
>
>                                     Device/File not configured
>
>                                     Device/File not configured
>
>                                     Device/File not configured
>
>          Cluster registry integrity check succeeded
>
>          Logical corruption check bypassed due to non-privileged user
>
> ```

#### 4.7.2.3 ocrconfig

> 该命令用于维护OCR磁盘,安装clusterware过程中,如果选择External Redundancy冗余方式,则只能输入一个OCR磁盘位置.但是Oracle允许配置两个OCR磁盘互为镜像,以防止OCR磁盘的单点故障.OCR磁盘和Votedisk磁盘不一样,OCR磁盘最多只能有两个,一个Primary OCR和一个Mirror OCR.

### 4.7.3 OCR备份恢复

#### 4.7.3.1 (自动备份)物理ocrconfig

> 在缺省情况下,OCR自动备份在$CRS_HOME/CRS/CDATA/cluster_name目录下,可以通过ocrconfig -backuploc<directory_name>命令修改到新目录

> 与Oracle数据库的备份恢复相似,OCR的备份也有物理备份和逻辑备份,因此有两种备份方式和两种恢复方式.物理备份是自动进行的,逻辑备份需要手动进行.

> 因为OCR的内容如此重要,所以Oracle每4个小时对其做一次物理备份,并且保留最后的3个物理备份,以及前一天,前一周的最后一个物理备份.用户不能自定义物理备份频率以及备份文件的副本数.这个备份由Master Node CRSD进程完成,备份的默认位置在$GRID_HOME/cdata/<cluster_name>目录下,也可由命令ocrconfig -showbackup获取备份的位置.每次备份后,备份文件名自动更改,以反映备份时间顺序,最近一次的备份叫作backup00.ocr.这些备份文件除了保存在本地,DBA还应该在其它存储设备上保留一份,以防止意外的存储故障.备份目录可以通过命令“ocrconfig -backuploc <directory_name>”修改.

> 下例为物理备份OCR

bash> 物理恢复OCR的过程一般有如下几个步骤

```bash
#手动进行物理备份
ocrconfig -manualbackup 
#查看物理备份
ocrconfig -showbackup
#检查OCR组件
cluvfy comp ocr -n all -verbose  
#2个节点都停止CRS
crsctl stop crs -f  
#排它模式启动CRS
crsctl start crs -excl -nocrs  
crsctl stop resource ora.crsd -init
# 此处是在FS下的文件
ocrconfig -restore /oracle/app/11.2.0/grid/cdata/ZFTPCCDB-crs/backup_20160701_152358.ocr
crsctl stop has -f
crsctl start crs
```

#### 4.7.3.2 (手动备份)逻辑导入导出

```bash
ocrconfig -export /tmp/ocr_bak
ocrconfig -import /tmp/ocr_bak
```

> 使用ocrconfig -export方式产生的备份,统称之为逻辑备份.对于OCR的配置发生重大的变化前后,如添加删除节点,修改集群资源,创建数据库等,都建议使用逻辑备份.对于由于错误配置而导致的OCR被损坏的情形,可以使用ocrconfig -import方式进行恢复.逻辑备份的恢复方式和物理备份的恢复方式一致.

#### 4.7.3.3 dd备份恢复

```bash
备份表决磁盘
dd if=/dev/raw/raw3 of=/tmp/votedisk01.bak bs=1024k count=4
恢复表决磁盘
dd if=/dev/raw/votedisk01.bak of=/tmp/raw3 bs=1024k count=4
```

#### 4.7.3.4 kred恢复磁盘头

#### 4.7.3.5 md_backup和md_restore

### 4.7.4 OLR

#### 4.7.4.1 概念

> OCR是用于保存CRSD所管理的资源的注册表,但是在CRSD启动之前集群还有很多初始化资源(例如ASM实例)需要启动,所以,只有OCR是不够的.因此,Oracle在11gR2版本中推出了另一种注册表OLR(Oracle Local Registry,Oracle本地注册表).OLR类似于Oracle集群注册表,但是OLR只存储与本地节点有关的信息.OLR不与集群中的其它节点共享.OLR存储了集群启动初期ohasd(Oracle High Availability Service)使用的重要环境,如Oracle集群件的版本、配置等.如果OLR丢失或损坏,那么将会导致ohasd进程启动失败.所以,OLR的主要作用就是为ohasd守护进程提供集群的配置信息和初始化资源的定义信息.

> Oracle在一个名为/etc/oracle/olr.loc(Linux或AIX)或者/var/opt/oracle/olr.loc(Solaris系统)的文本文件中存储了OLR配置文件的位置.当集群启动时,ohasd会从该文件中读取OLR的位置.对于集群环境(GI Cluster)而言,OLR的文件名一般为GRID_HOME/cdata/<hostname.olr>,而对于单节点(GI Standalone,Oracle Restart)而言,OLR的文件名一般为$GRID_HOME/cdata/localhost/<hostname.olr>.下例为集群环境的配置：

```bash
[grid@rac02 /]$ more /etc/oracle/olr.loc
olrconfig_loc=/u01/app/11.2.0/grid/cdata/rac02.olr
crs_home=/u01/app/11.2.0/grid
```

> OLR的结构仍然沿用了和OCR相同的树形结构,而且其中的信息组织形式和OCR也是相同的.所以,其维护类似于OCR的维护过程.它们常用到的维护工具有ocrconfig、ocrdump和ocrcheck.其中,加上-local表示对OLR的操作,否则是对OCR的操作.
>
>> ocrcheck 对OCR/OLR执行快速健康检查,并输出空间使用统计信息.
>> ocrdump 将OCR/OLR的内容转储到一个操作系统文件.
>> ocrconfig 对OCR/OLR执行导入、导出、添加、替换、删除、恢复和显示备份操作
>>

#### 4.7.4.2 OLR备份恢复

> OLR的备份策略和OCR的有所不同,默认情况下GI在初始安装时会在路径$GRID_HOME/cdata/<节点名>下产生一个备份
>
> ```bash
> [root@orcl orcl]# cd
> [root@orcl ~]# cd /u01/app/11.2.0/grid/cdata/orcl
> [root@orcl orcl]# ll
> total 5608
> -rw------- 1 grid oinstall 5742592 May  1  2015 backup_20150501_174602.olr
> ```

> OLR不会被自动备份,如果在集群的一些配置信息发生改变后,需要使用下面的命令手动进行备份：
>
> ```bash
> [root@orcl orcl]# ocrconfig -local -manualbackup
> orclalhr    2017/03/09 10:21:51 /u01/app/11.2.0/grid/cdata/orcl/backup_20170309_102151.olr
> orclalhr    2015/05/01 17:46:02 /u01/app/11.2.0/grid/cdata/orcl/backup_20150501_174602.olr
> ```

> 建议在集群的重要配置信息(例如：集群私网配置)发生改变之后,使用命令ocrconfig -local -manualbackup手动备份OLR.当OLR丢失之后,可以使用命令“ocrconfig -local –restore <OLR备份文件>”来恢复,不能从集群的其它节点复制OLR到本地节点,这是因为OLR中保存的一些信息是针对本地节点的.如果需要验证OLR的一致性,那么可以使用ocrcheck -local命令.简单地说,所有适用于OCR的命令同样适用于OLR,但是需要增加-local选项.
> 对于OLR的备份恢复简单过程如下所示(MOS：1193643.1和1368382.1)：

```bash
<GI_HOME>/bin/ocrconfig -local -manualbackup
<GI_HOME>/bin/ocrconfig -local -showbackup
ps -ef| grep ohasd.bin
<GI_HOME>/bin/crsctl stop crs -f  <========= for GI Cluster
<GI_HOME>/bin/crsctl stop has  <========= for GI Standalone
<GI_HOME>/bin/ocrconfig -local -restore <olr-backup>
<GI_HOME>/bin/crsctl start crs   <========= for GI Cluster
<GI_HOME>/bin/crsctl start has  <========= for GI Standalone, this must be done as grid user.
```

### 4.7.5 VF (Voting File)表决磁盘文件

> 表决磁盘(Voting Disk)也叫仲裁盘(Quorum Disk),表决磁盘的作用是保存VF(Voting File,表决磁盘文件).VF的作用是实现集群的磁盘心跳,主要用于记录节点成员状态信息,例如,包含哪些节点成员,节点添加删除信息的记录等.在集群出现脑裂时,VF可以用来决定哪个节点获得控制权,其它的节点必须从集群中剔除,即在集群出现脑裂时,可以提供解决方案.表决磁盘存储在ASM中,有如下几点要求：

> 1).表决磁盘文件必须全部放入ASM中.
> 2).表决磁盘存在ASM中的个数不能修改,而是通过ASM的NORMAL、HIGH、EXTERNAL冗余级别决定的.例如：在NORMAL中必须有3个故障组3个表决磁盘,在HIGH中必须要有5个故障组5个表决磁盘,在EXTERNAL只有1个表决磁盘.
> 3).表决磁盘文件在Oracle
> 11gR2中不再支持dd命令对其进行备份和还原,而是支持crsctl相关命令或自动备份.在Oracle 11gR2之前的版本,如果要备份表决磁盘的内容那么只有使用dd命令进行备份.
> 4).表决磁盘文件的个数必须是奇数,便于投票选举,且表决磁盘文件的个数最多为15个,但一般没必要超过5个.

在安装集群时也会提示指定表决磁盘的位置.安装完成后可以通过如下命令来查看表决磁盘的位置.

```bash
[root@node1 ~]# crsctl query css votedisk
##  STATE    File Universal Id                File Name Disk group
--  -----    -----------------                --------- ---------
 1. ONLINE   47308575b8f34fe9bf0fc5f669d46987 (ORCL:OVDISK) [OVDISK]
Located 1 voting disk(s).
```

另外,也可以从V$ASM_DISK这个视图中查询,VOTING_FILE列为Y的表示包含表决磁盘

```sql_more
SQL> col path format a30
SQL> SELECT GROUP_NUMBER,PATH,VOTING_FILE FROM  V$ASM_DISK;
GROUP_NUMBER PATH                           V
------------ ------------------------------ -
           1 ORCL:ARCHDISK                  N
           2 ORCL:DATADISK                  N
```

> 最后需要说明的一点是,如果表决磁盘损坏,而OCR或OLR的备份不可用,那么可以通过重新执行root.sh脚本的方式来修复OCR,修复之后除OCR磁盘组外的所有磁盘组,只要磁盘头没有损坏,就都可以直接对磁盘组进行MOUNT操作来恢复业务数据库.因此,强烈建议OCR磁盘和其它存放数据库数据的磁盘分开存放.

下表对OCR和VF做简单比较

|                                                | **OCR(Oracle Cluster Registry,Oracle****集群注册表)**                                                                              | **VF(Voting File,** **表决磁盘文件)** |
| ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------- |
| **简介**                                       | OCR相当于集群的控制文件,保存了集群中绝大部分资源的配置信息,用于解决健忘问题.在Oracle 11.2中引入一个新的文件,称作OLR(Oracle Local   |                                       |
| Registry,Oracle本地注册表),它只允许存放在本地. | 表决磁盘(Voting Disk)的作用是保存VF.VF的作用是实现集群的磁盘心跳,主要用于记录节点成员状态信息.在集群出现脑裂时,VF可以提供解决方案. |                                       |
| **查找命令**                                   | ocrcheck                                                                                                                           | crsctl query                          |
| css votedisk                                   |                                                                                                                                    |                                       |
| **解决**                                       | 健忘问题                                                                                                                           | 脑裂问题                              |
| **共性**                                       | 1.OCR和VF的信息不会分布到多块磁盘上 2.都可以通过root.sh脚本来修复                                                                  |                                       |

### 4.7.6 替换OCR磁盘组的步骤

#### 4.7.6.1 添加新存储

#### 4.7.6.2 多路径绑定配置

#### 4.7.6.3 ASMLib 配置或udev绑定

#### 4.7.6.4 备份OCR

#### 4.7.6.5 新建OCR卷组

#### 4.7.6.6 替换VOTE在其中一个节点,root用户下执行

```bash
[root]# crsctl query css votedisk   -----修改前确认表决磁盘的位置
        ##  STATE    File Universal Id                File Name Disk group
        -  -----    -----------------                --------- ---------
        1. ONLINE   904eec4b28014f51bf5c23fbdb330aef (/dev/asm-disk1) [OCR]
        Located 1 voting disk(s).
[root@cwhxdb2 bin]# crsctl replace votedisk +FRA
        Successful addition of voting disk 8324947e1f494f06bf6c01f6bd5940c9.
        Successful deletion of voting disk 904eec4b28014f51bf5c23fbdb330aef.
        Successfully replaced voting disk group with +FRA.
        CRS-4266: Voting file(s) successfully replaced
[root@cwhxdb2 bin]# ./crsctl query css votedisk    -----修改后确认表决磁盘的位置
        ##  STATE    File Universal Id                File Name Disk group
        --  -----    -----------------                --------- ---------
        1. ONLINE   8324947e1f494f06bf6c01f6bd5940c9 (/dev/asm-disk5) [FRA]

```

#### 4.7.6.7 替换OCR 在grid或root用户下执行,只需要在一个节点上操作即可

```bash
#主要命令：
ocrconfig -add +newocr
more /etc/oracle/ocr.loc
ocrconfig -delete +ocr
more /etc/oracle/ocr.loc
ocrcheck

[root@cwhxdb2 bin]# ./ocrconfig -add +fra
[root@cwhxdb2 bin]# more /etc/oracle/ocr.loc
        #Device/file  getting replaced by device +fra 
        ocrconfig_loc=+OCR
        ocrmirrorconfig_loc=+fra
        local_only=false
[root@cwhxdb2 bin]# ocrconfig -delete +ocr
[root@cwhxdb2 bin]# ocrcheck
        Status of Oracle Cluster Registry is as follows :
        Version                  :          3
        Total space (kbytes)     :     262120
        Used space (kbytes)      :       2948
        Available space (kbytes) :     259172
        ID                       :  495741472
        Device/File Name         :       +fra
        Device/File integrity check succeeded
        Device/File not configured
        Device/File not configured
        Device/File not configured
        Device/File not configured
        Cluster registry integrity check succeeded   
[root@cwhxdb2 bin]# more /etc/oracle/ocr.loc
        #Device/file +OCR getting replaced by device +fra 
        ocrconfig_loc=+fra
        local_only=false
```

#### 4.7.6.8 迁移ASM Spfile   (和实例的spfile是两码事)grid用户执行

```bash
[root]# su - grid 
[root]# asmcmd
    >spget    ----找到ASM spfile的位置
    >spcopy -u +OCR/rac-scan/asmparameterfile/registry.253.1050699607 +FRA/rac-scan/asmparameterfile/spfileasm.ora
    >spset +FRA/rac-scan/asmparameterfile/registry.253.1050699607
#[grid@cwhxdb1 ~]$ asmcmd
     ASMCMD> spget
     +OCR/rac-scan/asmparameterfile/registry.253.1050699607
     ASMCMD> spcopy -u +OCR/rac-scan/asmparameterfile/registry.253.1050699607 +FRA/rac-scan/asmparameterfile/spfileasm.ora
     ASMCMD> spset +FRA/rac-scan/asmparameterfile/spfileasm.ora
     ASMCMD> spget
     +FRA/rac-scan/asmparameterfile/spfileasm.ora
```

#### 4.7.6.9 确认老的OCR磁盘组是否还有其他文件

```bash
ASMCMD> cd ocr
ASMCMD> ls
rac-scan/
ASMCMD> cd ra*
ASMCMD> ls
ASMPARAMETERFILE/
OCRFILE/
ASMCMD> cd asm*
ASMCMD> ls
REGISTRY.253.1050699607    #### 不用管,已迁移
ASMCMD> cd ..
ASMCMD> ls
ASMPARAMETERFILE/
OCRFILE/
ASMCMD> cd ocrfile
ASMCMD> ls
REGISTRY.255.1050699611    #### 不用管,已迁移
```

#### 4.7.6.10 删除老OCR卷组

```bash
#在节点1和节点2分别重启集群
crsctl stop crs
crsctl start crs
--节点2：
su - grid
sqlplus / as sysasm
alter diskgroup OCR dismount;
exit

#节点1：
su - grid
sqlplus / as sysasm
drop diskgroup ocr;  #看执行结果,不行就执行下一条命令
drop diskgroup OCR INCLUDING CONTENTS;  #看执行结果,不行就执行下一条命令
drop diskgroup OCR FORCE INCLUDING CONTENTS;

```

#### 4.7.6.11 删除磁盘

> 任意一节点ROOT用户下操作：
> /usr/sbin/oracleasm dropdisk OCR
> 删除多路径绑定配置,删除配置/etc/multipatch.conf中原有OCR盘内容
> 最后从存储上删除2个节点的映射

#### 4.7.6.12 删除crs记录

> crsctl delete res ora.OCR.dg

## 4.8 GPnP

> 网格即插即用(Grid Plug and Play,GPnP)是Oracle 11gR2 RAC提供的新组件,该组件的功能由gpnpd.bin守护进程实现.GPnP可以提供一个动态的GI环境,能随着负载的增加而动态改变GI环境.GPnP能非常容易地添加、替换或者移除集群中的节点,就像电源插头一样即插即用.

### 4.8.1 组成

> GPnP主要由GPNPD、mDNS、SCAN和GNS组成.
> l   mDNS(Multicast Domain Name Service)负责在节点内部进行IP的解析,在添加节点的时候不需要手动修改每个节点的/etc/hosts文件.
> l   GPNPD服务提供的是集群配置信息管理,新的节点添加进来会根据现有的GPnP profile配置信息来配置新的节点,同时更新所有节点的GPnP profile文件.
> l   一旦新添加的节点加入到集群,SCAN机制动态地将连接分配给该节点,所有的客户端都不需要进行任何配置的变更,就能实现节点的负载均衡.
> l   GNS(Grid Naming Service)能动态地为新添加的节点分配VIP地址,利用DHCP管理公共网络中的IP地址.这些服务共同构成了“网格即插即用”的特性.

> GPnP profile存储了整个集群的配置信息,它是一个XML文件,该文件中包括了集群名称、网络类型(public/private)、ASM和CSS的存储信息、数字签名,以及ASM实例的SPFILE文件位置等.在集群中,CSS、GPnP等服务的启动都依赖于GPnP profile文件,该文件引导节点加入集群.如果GPnP profile文件被破坏或丢失,那么集群将无法正常启动.在集群启动期间,CSS守护进程将使用GPnP profile文件中的DiscoveryString参数发现表决磁盘文件,所以,若DiscoveryString参数配置不正确,则CSS守护进程无法启动,进而导致整个CRS无法启动.

> GPnP profile文件默认的保存位置是：
>
> ```bash
> $GRID_HOME/gpnp/$HOSTNAME/profile/peer/profile.xml
> $GRID_HOME/gpnp/profiles/peer/profile.xml  #全局备份
> ```

> 不能手动修改profile.xml文件,否则可能导致集群不能正常运行,可以使用命令gpnptool来修改该文件,使用命令“gpnptool get”可以获取profile.xml文件的内容.当集群配置发生变化时(例如,oifcfg改变网络信息、ASM添加存储等),所有节点的该文件会被自动更新(通过gpnpd.bin进程复制GPnP profile到所有的其它节点.注意：gpnpd是一个多线程的进程).
> 如果GPnP出现问题,那么可以使用cluvfy comp gpnp组件验证命令检查在集群中所有节点网格即插即用的完整性

```bash
cluvfy comp gpnp [-n node_list][-verbose]
```

### 4.8.2 GPnP用途

# 五、缓存融合技术

## 5.1Cache Fusion原理

> 前面已经介绍了 RAC 的后台进程,为了更深入的了解这些后台进程的工作原理,先了解一下 RAC 中多节点对共享数据文件访问的管理是如何进行的.要了解 RAC 工作原理的中心,需要知道 Cache Fusion 这个重要的概念,要发挥 Cache Fusion 的作用,要有一个前提条件,那就是互联网络的速度要比访问磁盘的速度要快.否则,没有引入 Cache Fusion 的意义.而事实上,现在 100MB 的互联网都很常见.

> Cache Fusion 就是通过互联网络(高速的Private interconnect)在集群内各节点的 SGA 之间进行块传递,这是RAC最核心的工作机制,他把所有实例的SGA虚拟成一个大的SGA区,每当不同的实例请求相同的数据块时,这个数据块就通过 Private interconnect 在实例间进行传递.以避免首先将块推送到磁盘,然后再重新读入其他实例的缓存中这样一种低效的实现方式(OPS 的实现).当一个块被读入 RAC 环境中某个实例的缓存时,该块会被赋予一个锁资源(与行级锁不同),以确保其他实例知道该块正在被使用.之后,如果另一个实例请求该块的一个副本,而该块已经处于前一个实例的缓存内,那么该块会通过互联网络直接被传递到另一个实例的 SGA.如果内存中的块已经被改变,但改变尚未提交,那么将会传递一个 CR 副本.这就意味着只要可能,数据块无需写回磁盘即可在各实例的缓存之间移动,从而避免了同步多实例的缓存所花费的额外 I/O.很明显,不同的实例缓存的数据可以是不同的,也就是在一个实例要访问特定块之前,而它又从未访问过这个块,那么它要么从其他实例 cache fusion 过来,或者从磁盘中读入.GCS(Global Cache Service,全局内存服务)和 GES(Global EnquenceService,全局队列服务)进程管理使用集群节点之间的数据块同步互联.

> 这里还是有一些问题需要思考的：
> 1).在所有实例都未读取该块,而第一个实例读取时,是怎么加的锁,加的什么锁？如果此时有另一个实例也要读这个块,几乎是同时的,那么 Oracle 如何来仲裁,如何让其中一个读取,而另一个再从前者的缓存中通过 cache 来得到？
> 2).如果一个块已经被其他实例读入,那么本实例如何判断它的存在？
> 3).如果某个实例改变了这个数据块,是否会将改变传递到其他实例,或者说其他实例是否会知道并重新更新状态？
> 4).如果一个实例要 swapout 某个块,而同时其他实例也有这个块的缓存,修改过的和未修改过的,本实例修改的和其他实例修改的,如何操作? truncate 一张表,drop 一张表... 和单实例有何不同？
> 5).应该如何设计应用,以使 RAC 真正发挥作用,而不是引入竞争,导致系统被削弱？
> 6).RAC 下锁的实现.
>
>> 锁是在各实例的 SGA 中保留的资源,通常被用于控制对数据库块的访问.每个实例通常会保留或控制一定数量与块范围相关的锁.当一个实例请求一个块时,该块必须获得一个锁,并且锁必须来自当前控制这些锁的实例.也就是锁被分布在不同的实例上.而要获得特定的锁要从不同的实例上去获得.但是从这个过程来看这些锁不是固定在某个实例上的,而是根据锁的请求频率会被调整到使用最频繁的实例上,从而提高效率.要实现这些资源的分配和重分配、控制,这是很耗用资源的.这也决定了 RAC 的应用设计要求比较高.假设某个实例崩溃或者某个实例加入,那么这里要有一个比较长的再分配资源和处理过程.在都正常运行的情况下会重新分配,以更加有效的使用资源;在实例推出或加入时也会重新分配.在 alert 文件中可以看到这些信息.而 Cache Fusion 及其他资源的分配控制,要求有一个快速的互联网络,所以要关注与互联网络上消息相关的度量,以测试互联网络的通信量和相应时间.对于前面的一些问题,可以结合另外的概念来学习,它们是全局缓存服务和全局队列服务.
>>
>> 全局缓存服务(GCS):要和 Cache Fusion 结合在一起来理解.全局缓存要涉及到数据块.全局缓存服务负责维护该全局缓冲存储区内的缓存一致性,确保一个实例在任何时刻想修改一个数据块时,都可获得一个全局锁资源,从而避免另一个实例同时修改该块的可能性.进行修改的实例将拥有块的当前版本(包括已提交的和未提交的事物)以及块的前象(post image).如果另一个实例也请求该块,那么全局缓存服务要负责跟踪拥有该块的实例、拥有块的版本是什么,以及块处于何种模式.LMS 进程是全局缓存服务的关键组成部分.
>>
>> 猜想：Oracle 目前的 cache fusion 是在其他实例访问时会将块传输过去再构建一个块在那个实例的 SGA 中,这个主要的原因可能是 interconnect 之间的访问还是从本地内存中访问更快,从而让 Oracle 再次访问时可以从本地内存快速获取.但是这也有麻烦的地方,因为在多个节点中会有数据块的多个 copy,这样在管理上的消耗是很可观的,Oracle 是否会有更好的解决方案出现在后续版本中？如果 interconnect 速度允许的话...)
>>
>> 全局队列服务(GES)：主要负责维护字典缓存和库缓存内的一致性.字典缓存是实例的 SGA 内所存储的对数据字典信息的缓存,用于高速访问.由于该字典信息存储在内存中,因而在某个节点上对字典进行的修改(如DDL)必须立即被传播至所有节点上的字典缓存.GES 负责处理上述情况,并消除实例间出现的差异.处于同样的原因,为了分析影响这些对象的 SQL 语句,数据库内对象上的库缓存锁会被去掉.这些锁必须在实例间进行维护,而全局队列服务必须确保请求访问相同对象的多个实例间不会出现死锁.LMON、LCK 和 LMD 进程联合工作来实现全局队列服务的功能.GES 是除了数据块本身的维护和管理(由 GCS 完成)之外,在 RAC 环境中调节节点间其他资源的重要服务.
>>
>> SQL> select * from gv$sysstat where name like 'gcs %'
>> 这里可以看到 gcs 和 ges 消息的发送个数.(如果没有使用 DBCA 来创建数据库,那么要 SYSDBA 权限来运行CATCLUST.SQL脚本来创建 RAC 相关的视图和表)
>>

## 5.2 锁

> LOCK(锁)是用来控制并发的数据结构,如果有两个进程同时修改同一个数据, 为了防止出现混乱和意外,用锁来控制访问数据的次序.有锁的可以先访问,另外一个进程要等到第一个释放了锁,才能拥有锁,继续访问.总体来说,RAC 里面的锁分两种, 一种是本地主机的进程之间的锁,另外一种是不同主机的进程之间的锁.本地锁的机制有两类,一类叫做 lock(锁),另外一类叫做 latch 闩.

> 全局锁就是指 RAC lock,就是不同主机之间的锁,Oracle 采用了DLM(Distributed Lock Management,分布式锁管理)机制.在 Oracle RAC 里面,数据是全局共享的,就是说每个进程看到的数据块都是一样的,在不同机器间,数据块可以传递.给出了 GRD目录结构.

> 可以看出 Mode、Role、n 构成了 RAC lock 的基本结构:
> 1).Mode 有 N、S、X3 种方式
> 2).Role 有 Local 和 Global 两种
> 3).N 有 PI 和 XI 两种,一般 0 表示 XI,1 表示 PI
> 4).全局内存管理
> 5).RAC 中的数据库文件
> 6).RAC 中读的一致性
> 7).群集就绪服务(CRS)
> 8).全局资源目录

## 5.3 一致性管理

> 数据一致性和并发性描述了 Oracle 如何维护多用户数据库环境中的数据一致性问题.
> 在单用户数据库中,用户修改数据库中的数据,不用担心其他用户同时修改相同的数据.
> 但是,在多用户数据库中,同时执行的多个事务中的语句可以修改同一数据.同时执行的事务需要产生有意义的和一致性的结果.因而,在多用户数据库中,数据并发性和数据一致性的控制非常重要：数据并发性：每个用户可以看到数据的一致性结果.ANSI/IOS SQL 标准(SQL 92)定义了 4 个事务隔离级别,对事务处理性能的影响也个不相同.这些隔离级别是考虑了事务并发执行必须避免的 3 个现象提出的.3 个应该避免的现象为：
>
>> 1).脏读：一个事务可以读取其他事务写入但还没有提交的数据.
>> 2).不可重复读(模糊读)：一个事务重复读到以前读到的和查询到的数据,这些数据是其他的已提交事务已经修改或者删除的数据.
>> 3).幻影读：一个事务重复运行查询返回的一些列行,这些行包括其他已经提交的事务已经插入的额外的行.
>>

> SQL92 根据这些对象定义了 4 个隔离级别,事务运行在特定的隔离级别允许特别的一些表现.如下表表示隔离级别阻止的读现象.

![](https://cdn.jsdelivr.net/gh/klausyao/imageshosting/oracle/rac/rac/image10.gif)

## 5.4 RAC的并发控制

DLM 分布式锁管理.

```bash
Non-Cache Fusion 资源：包括数据文件、控制文件、数据字典视图 、Library Cache、Row Cache
Cache Fusion 资源：包括普通数据块、索引数据块、段头、UNDO 数据块.
GRD(Global Resource Directory)：记录每个数据块在集群间的分布图,在SGA中分master node与shadownode
PCM lock：mode role Past Image
LMS0(LOCK MANAGER SERVICE)：对应服务为 GCS(Global Cache Service),主要负责数据块在实例间传递Cache fusion 参数 GCS_SERVER_PROCESSES
LMD：对应服务为 GES(Global ENQUEUE Service),主要负责传递过程中锁的管理.
LCK：负责 NON-CACHE FUSION 资源同步访问,每个实例有一个进程.
LMON：这个进程定期通信每个实例,对应服务为 CGS(Cluster Group Service).提供节点监控 node monitor,通过 GRD 中用位图 0,1 来标志.0：节点关闭 1：节点正常运行通过 CM 层定期通信.
两种心跳机制：网络心跳和控制文件磁盘心跳 3S 一次.
DIAG：监控状态,写日志 alert.log
GSD：为用户提供管理接口.
```

## 5.5 RAC重构触发条件

> (一) NM(NODE MANAGEMENT)group
> (二) 重构集群触发：有 node 加入或者离开集群,由 NM 触发 Network Heartbeat 异常：因为 LMON 或者 GCS、GES 通信异常 ,由 IMR(Instance Membership Reconfiguration)controlfile heartbeat 触发.

# 六、RAC中的工具

## 6.1 CHM

### 6.1.1 作用

> CHM(Cluster Health Monitor,集群健康监控)是一个Oracle提供的工具,用来自动收集操作系统的资源(CPU、内存、SWAP、进程、I/O以及网络等)的使用情况.CHM会每秒收集一次数据.这些系统资源数据对于诊断集群系统的节点重启、Hang、实例驱逐(Eviction)、性能问题等是非常有帮助的.另外,用户可以使用CHM来及早发现一些系统负载高、内存异常等问题,从而避免产生更严重的问题.CHM也可以用来在系统出现异常时快速收集异常时刻的数据.相对于OSWatcher,CHM直接调用OS的API来降低开销,而OSWatcher则是直接调用UNIX命令；另外,CHM的实时性更强,每秒收集一次数据,从Oracle 11.2.0.3开始改为了每5秒一次.OSWatcher的优点是可以用traceroute命令检测私网间的连通性,而且生成的数据的保留时间可以设置得很长.如果可以的话,最好是两个工具都安装.

> 在Oracle 11.2.0.3之后,AIX和Linux平台在安装Grid时默认安装CHM.常用的命令如下所示：
>
> ```bash
> crsctl stat res ora.crf -init -p	#查看ora.crf状态
> oclumon manage -get master		#查看CHM当前主节点
> oclumon manage -get reppath		#查看CHM数据保存路径
> oclumon manage -repos reploc /shared/oracle/chm #修改CHM数据保存路径
> oclumon manage -get repsize		#查看CHM数据保留时间(s)
> oclumon manage -repos resize 68083	#修改CHM数据保留时间(s)
> ```

> 在集群中,可以通过下面的命令查看CHM对应的资源(ora.crf)的状态
>
> ```bash
> [root@rac2 ~]# crsctl stat res -t -init |grep -1 ora.crf 
> ora.crf
>       1        ONLINE  ONLINE       rac2   
> ```

> CHM主要包括两个服务：
> 1、System Monitor Service(osysmond)：这个服务在所有节点都会运行,osysmond会将每个节点的资源使用情况发送给Cluster

```bash
[root@rac2 ~]# ps -ef|grep osysmond
root     29498     1  1 15:18 ?        00:01:31 /u01/app/11.2.0/grid/bin/osysmond.bin
```

> 2、Cluster Logger Service(ologgerd)：在一个集群中,ologgerd会有一个主节点(Master),还有一个备节点(Standby).当ologgerd在当前的节点遇到问题而无法启动后,它会在备用节点启用.该服务会将osysmond收集的数据保存到CHM资料库中($GRID_HOME/crf/db).

```bash
#主节点：
$ ps -ef|grep ologgerd
root 8257  1  0 Jun05 ?  00:38:26 /u01/app/11.2.0/grid/bin/ologgerd -M -d  /u01/app/11.2.0/grid/crf/db/rac2
#备节点：
$ ps -ef|grep ologgerd
root  8353  1  0 Jun05 ?  00:18:47 /u01/app/11.2.0/grid/bin/ologgerd -m rac2 -r -d    /u01/app/11.2.0/grid/crf/db/rac1
# -M或-m后的节点表示主节点,以上结果表示节点2为主节点.
```

> 获得CHM生成的数据的方法有两种：
>
> ```bash
> #1、一种是使用Grid_home/bin/diagcollection.pl：
> /u01/app/11.2.0/grid/bin/diagcollection.pl --collect --all --incidenttime 12/30/201515:13:00 --incidentduration 00:30
> #其中,“--incidenttime”表示采集数据开始时间,格式为MM/DD/YYYY24HH:MM:SS；“--incidentduration”表示持续时间,格式为HH:MM.生成的文件在当前目录.
>
> #2、另外一种获得CHM生成的数据的方法为oclumon:
> $oclumon dumpnodeview [[-allnodes] | [-n node1 node2] [-last "duration"] | [-s "time_stamp" -e "time_stamp"] [-v] [-warning]] [-h]
> #其中,-s表示开始时间,-e表示结束时间,例如：
> $ oclumon dumpnodeview -allnodes -v -s "2012-06-15 07:40:00" -e "2012-06-15 07:57:00" > /tmp/chm1.txt
>
> #使用root用户执行以下命令可以禁用CHM服务：
>     crsctl stop res ora.crf -init
>     crsctl modify res ora.crf -attr "AUTO_START=never" -init
>     crsctl modify res ora.crf -attr "ENABLED=0" -init
> #使用以下命令可以查看ora.crf相关的属性：
> crsctl stat res ora.crf -init -p
> ```

### 6.1.2 CHM工具

### 6.1.3 OSWatcher工具

## 6.2 cluvfy

### 6.2.1 cluvfy工具介绍

> cluvfy(Cluster Verification Utility,集群检验工具),简称CVU,是随Oracle集群管理软件一起发布的检查工具.它的功能是对整个集群系统实施过程的各个阶段以及各个组件进行检查,并验证是否满足Oracle的要求.cluvfy能对集群提供非常广泛的检查,包括：OS硬件配置、内核参数设置、用户资源限制设置、网络设置、NTP设置、RAC组件健康性等.cluvfy在进行检查时并不会修改系统配置,所以不会对系统造成影响.cluvfy检查的内容可以从两个角度进行分类：阶段(stage)、组件(component).

> 使用命令cluvfy stage -list可以查看所有阶段.使用命令cluvfy comp -list可以查看所有组件.将list修改为help可以查看相应的命令.

```bash
[grid@orcl ~]$ cluvfy stage -list

USAGE:
cluvfy stage {-pre|-post} <stage-name> <stage-specific options>  [-verbose]

Valid Stages are:
      -pre cfs        : pre-check for CFS setup
      -pre crsinst    : pre-check for CRS installation
      -pre acfscfg    : pre-check for ACFS Configuration.
      -pre dbinst     : pre-check for database installation
      -pre dbcfg      : pre-check for database configuration
      -pre hacfg      : pre-check for HA configuration
      -pre nodeadd    : pre-check for node addition.
      -post hwos      : post-check for hardware and operating system
      -post cfs       : post-check for CFS setup
      -post crsinst   : post-check for CRS installation
      -post acfscfg   : post-check for ACFS Configuration.
      -post hacfg     : post-check for HA configuration
      -post nodeadd   : post-check for node addition.
      -post nodedel   : post-check for node deletion.
```

> 比较常用的就是使用cluvfy命令进行安装集群之前的系统检查,如下所示：
>
> ```bash
> $ORACLE_HOME/bin/cluvfy stage  -pre crsinst -n all -r 11gR2 -verbose -fixup
> ```

> 其中,
> -n 选项表示需要检查的节点列表.这里需要所有列出的节点之间的用户等效性已经配置成功.
> -r 表示需要安装的软件版本,可以使用help查看支持的软件版本.
> -verbose 表示列出检查内容的详细信息.

### 6.2.2 cvuqdisk包的作用是什么？

> 在安装RAC的过程中,如果没有安装cvuqdisk包,那么集群检验工具(Cluster Verification Utility,CVU)就不能发现共享磁盘.而且,如果没有安装该包或者安装的版本不对的话,那么当运行集群检验工具的时候就会报错误
>
> ```bash
> “PRVF-10037 : Failed to retrieve storage type for "<devicepath>" on node "<node>"”
> 或“Could not get the type of storage”
> 或“PRVF-07017: Package cvuqdisk not installed”
> ```

cvuqdisk的RPM包含在Oracle Grid Infrastructure安装介质上的rpm目录中.以root用户在RAC的2个节点上都进行安装,如下：

```bash
export CVUQDISK_GRP=oinstall
rpm -iv cvuqdisk-1.0.9-1.rpm
```

## 6.3 kfed、kfod和amdu

> ASM(Automatic Storage Management)是Oracle目前主推的软件集群存储策略.一般而言,管理ASM的工具包括使用SQL*Plus命令行和asmca图形化界面.一般情况下,ASM安装管理借助上述工具就够了,况且Oracle集群可以确保ASM组建的HA架构.一些特殊场景,如磁盘数据损坏、底层修复和ASM盘发现,需要额外的一些命令行工具.ASM工具包括：kfod、kfed和AMDU.在早期的ASM版本(10gR2)中,一部分工具还需要额外的重新编译和链接才能使用.在11g,这部分工具已经成为默认设置,可以直接使用.

> 在Oracle ASM和Database安装过程中,kfod是会自动被调用,用于进行磁盘发现过程(Disk
> Discovery).如果在安装Grid过程没有成功,那么kfod也会在安装stage文件夹中被找到.目录地址为：<stage_folder>/grid/stage/ext/bin/.命令kfod -h可以查看该命令的解释,使用示例如下所示：

```bash
$ORACLE_HOME/bin/kfod disk=asm s=true ds=true c=true
```

> kfed的全称为Kernel File Metadata Editor.kfed的使用场景比较严峻,就是当ASM Diskgroup不能成功Mount的时候,通过KFED来分析ASM磁盘头信息,来诊断问题.从Oracle 11.1开始,KFED就已经正式成为安装组件的一部分.与kfod的区别是,kfed只有在完全安装完之后,才能使用,在ASM安装阶段无法使用.其使用示例如下所示：

```bash
kfed read /dev/raw/raw1
```

> amdu全称为ASM Metadata Dump Utility.AMDU最大的作用在于可以将ASM Disk Group和DISK所有可用元数据信息导出,并且整理为可读的格式内容.其工作不受到Disk Group是否Mount访问的影响.这个工具之所以被正式公布,主要在于Oracle Support在进行远程支持的时候,需要客户提供上载文件.

# 七、MGMTDB

## 7.1 GIMR概念

![](https://cdn.jsdelivr.net/gh/klausyao/imageshosting/oracle/rac/rac/image11.gif)

> Grid Infrastructure Management Repository
> 在安装12C GI的过程中,会要求安装GIMR的数据库MGMTDB,当然你可能会选NO.
> 在12.1.01版本时是可以选择GIMR不安装
> 但是在12.1.0.2和12.2版本中GIMR成了强制安装,即使在这里选择了NO,这里的YES和NO的区别只是把MTMTDB是存放在OCR ASM DISKGROUP还是独立的创建ASM DISKGROUP.

> 在12.1中,MGMTDB数据库数据文件默认和OCR/Voting disks文件放在相同的存储.
> 在12.1.0.1中,GIMR是可选项,如果在安装GI的时候没有选中该选件,之后也不可以再进行配置该功能;
> 在12.1.0.2中,GIMR选件是必须安装的,安装后不支持取消该功能.

> MGMTDB只是1个CDB包含1个PDB的完整的数据库环境,通常不需要人维护,存储的是GIMR的信息,用于存放cluster health monitor生成的一些操作系统级的负载指标,存储着历史信息用于分析性能和诊断问题,是全集成在EM 12C 中

## 7.2 MGMTDB基本信息

### 7.2.1 什么是管理资料库？

> 管理资料库是一个由12c集群软件管理的单实例数据库. 因为此数据库为单实例数据库,所以它只在集群的—个节点运行. 也正是因为这个数据库是被集群管理的,所以如果数据库运行节点dσw掉,数据库也会被自边切换到另外的节点

> 实际上,MGMTDB是带一个PDB的CDB库,可以使用GI的命令直接去操作MGMTDB对应的PDB

> Oracle Restart环境是没有MGMTDB的.

> Management Repository是受12c Clusterware管理的一个单实例,在 Cluster启动的时会启动MGMT
> DB并在其中一个节点上运行,并受GI管理,如果运行MGMTDG的节点宕机了,GI会自动把 MGMTDB转移到其他的节点上.

> 另外,对于MGMTDB数据库,在目前的版本中,也不需要手工对其进行备份

### 7.2.2 管理资料库作用

> 在12c中,Management Database用来存放Cluster Health Monitor(CHM/OS,ora crf)、Oracle Database QoS Management、Rapid Home Provisoning和其他的数据.
>
>> Ø  Cluster health Monitor收集的实时性能数据
>> Ø  Cluster Health Advisor收集的故障、诊斷和指标数据
>> Ø  有关Oracle Clusterware收集的所有资源的集群范围事件
>> Ø  用于服务质量管理(Qos)的CPU架构数据
>> Ø  Rapid Home Provisioning所需的元数据
>>

### 7.2.3 管理资料库的数据文件位置

> 12.1版本,管理资料库默认和OCR、Voting disk使用一样的共享存储.
> 12.2版本,在安装时可以指定使用单独的 diskgroup
> 默认情况,MGMTDB数据库的数据文件存放在共享的设备,如OCR/Voting的磁盘组中,但后期可以移动位置

### 7.2.4 如果不配置管理资料库会有什么影响？

> 管理资料库在12.1是非强制的,如果在使用OUI安装升级的时候未选择该选项,所有的依赖于管理资料库的功能都会被禁用(比如CHM/OS等)

> 在12.1.0.2中,管理资料库变为强制安装(除了Exadata环境).

> 从 Oracle Grid Infrastructure 19c开始,对于 Oracle Standalone Cluster类型的GI来说,Grid Infrastructure Management Repository(GIMR)不再是强制的,而是可选的. 不过GIMR对于 Oracle domain services clusters来说仍然是必须的.

> 对于ODA18.3和更高版本,GIMR不是强制需要的

### 7.2.5 有没有必要去手动备份或优化资料库？

> 目前没有必要

### 7.2.6 在Oracle Restart环境下,GIR会被默认刨建吗？

> 不.
> 在 Oracle restart环境下GIMR默认不会被创建. 手动创建 MGMTDB也会报错

### 7.2.7 需要分配多少磁盘空间给资料库？

> OCR和管理资料库在外部冗余的情况下
> 至少5.2GB的空间的OCR用来存储资料库(4.5B+30B)Voting fi1+400B0cR),如果节点数超过4,则每个多出的节点多分配500MB的空间. 如六节点的集群应该使用6.2GB空间
> orac1e的文档说明：[https://docs.oracle.com/database/121/CWLIN/storage.htm#CHDDCAHD](https://docs.oracle.com/database/121/CWLIN/storage.htm#CHDDCAHD)

> 注意：在 Oracle18c(12.2.0.2)环境中,至少需要30G的空间

## 7.3 常用命令

### 7.3.1 命令

```bash
#资源信息
srvctl status mgmtdb
oclumon manage -get master
crsctl stop cluster
srvctl status mgmtdb
crsctl start cluster
crsctl stst res -t 
#进程信息
ps -ef | grep pmon_-MGMTDB
ps -ef | grep MGMTLSNR

srvctl start mgmtdb
srvctl stop mgmtdb
srvctl status mgmtdb
srvctl enable mgmtdb
srvctl disable mgmtdb
srvctl config mgmtdb
srvctl modify mgmtdb
srvctl add mgmtdb
srvctl remove mgmtdb
srvctl getenv mgmtdb
srvctl setenv mgmtdb
srvctl unsetenv mgmtdb
srvctl relocate mgmtdb

srvctl start mgmtlsnr
srvctl stop mgmtlsnr
srvctl status mgmtlsnr
srvctl enable mgmtlsnr
srvctl disable mgmtlsnr
srvctl config mgmtlsnr
srvctl modify mgmtlsnr
srvctl add mgmtlsnr
srvctl remove mgmtlsnr
srvctl getenv mgmtlsnr
srvctl setenv mgmtlsnr
srvctl unsetenv mgmtlsnr

```

### 7.3.2 启动关闭MGMTDB

> 正常情况下,MGMTFB会随着GI自动启动,也可以手工管理,使用srvctl操作即可.
> 登陆MGMTDB实例

```sql_more
export ORACLE_SID=-MGMTDB
sqlplus / as sysdba 
select file_name from dba_data_files union select member file_name from V$logfile;
--这里查询的是MGMTDB的路径,也可以直接用如下命令查询：
[grid@rac2 /]$ oclumon manage -get reppath
CHM Repository Path = +OCR_VOTING/_MGMTDB/DATAFILE/sysmgmtdata.260.854939737
--查询MGMTDB用户：
SQL> select username,account_status from dba_users where username like 'CH%';
USERNAME      ACCOUNT_STATUS  
------------- ----------------
CHM           OPEN
CHA           OPEN
```

## 7.4 MGMTDB的Log和trace文件

> cd到管理资料的子目录去查看跟踪文件
> 进入$GRID_HOME下的trace目录. 进入-MGMTDB时,注意不能直接cd:

```sql_more
[grid@rac01 _mgmtdb] cd -MGMTDB
--报错,必须使用./-MGMTDB 
[grid@rac01 _mgmtdb] cd ./-MGMTDB
[grid@rac01 -MGMTDB] ls
[grid@rac01 -MGMTDB] cd trace 
select * from v$diag_info;

[grid@rac01 ~]$ adrci
adrci>show home
```

## 7.5 移动MGMTDB的位置

> 默认情况下,MGMTDB 的数据文件是存放在OCR voting disk的磁盘组里的,为了节省OCR 磁盘组空间,我们也可以把MGMTDB 转移走.
> 当然,这里的移动位置,也是从一个共享位置移动到另一个共享位置.
> 在12.1.0.1 版本中有有问题,升级到12.1.0.2 解决.

> 具体操作如下

### 7.5.1 停止并禁用ora.crf 资源

> 这里的ora.crf就是CHM.
> 在所有节点使用root用户执行如下命令

```bash
crsctl stop res ora.crf -init
crsctl modify res ora.crf -attr ENABLED=0 -init
#注意：ora.mgmtlsnr 和 ora.mgmtdb 资源不能停,否则DBCA 时会报错
```

### 7.5.2 执行DBCA删除MGMTDB

```bash
#查看MGMTDB的运行节点： 
[root@rac1 ~]# srvctl status mgmtdb
Database is enabled
Instance -MGMTDB is running on node rac2
#这里显示在节点2上运行,那么在节点2上,用grid用户,执行dbca 命令,删除MGMTDB.  
[grid@rac2 ~]$ dbca -silent -deleteDatabase -sourceDB -MGMTDB
#如果是使用DBCA 手工创建的MGMTDB,则可能出现不能删除的情况,具体处理过程可以参考MOS： 1631336.1.  
```

### 7.5.3 重建MGMTDB的CDB

> 用grid用户,在任意节点,执行如下命令,重建CDB.

#### 7.5.3.1 12.1.0.1 执行如下命令

```bash
$ dbca -silent -createDatabase -templateName MGMTSeed_Database.dbc -sid -MGMTDB -gdbName _mgmtdb -storageType ASM -diskGroupName <+NEW_DG> -datafileJarLocation /assistants/dbca/templates -characterset AL32UTF8 -autoGeneratePasswords -oui_internal
#注意：
#这里新的磁盘组,建议compatible.asm 和 compatible.rdbms 属性都设置为12.1. 
#上面的命令使用的是磁盘组,如果是使用共享的NFS/CFS, 则使用如下命令：
dbca -silent -createDatabase -templateName MGMTSeed_Database.dbc -sid -MGMTDB -gdbName _mgmtdb -storageType FS -datafileDestination -datafileJarLocation /assistants/dbca/templates -characterset AL32UTF8 -autoGeneratePasswords -oui_internal
```

#### 7.5.3.2 12.1.0.2  执行如下命令

```bash
#ASM 磁盘组：
$ dbca -silent -createDatabase -sid -MGMTDB -createAsContainerDatabase true -templateName MGMTSeed_Database.dbc -gdbName _mgmtdb -storageType ASM -diskGroupName <+NEW_DG> -datafileJarLocation $GRID_HOME/assistants/dbca/templates -characterset AL32UTF8 -autoGeneratePasswords -skipUserTemplateCheck
#共享的NFS/CFS ：
$ dbca -silent -createDatabase -templateName MGMTSeed_Database.dbc -sid -MGMTDB -gdbName _mgmtdb -storageType FS -datafileDestination  -datafileJarLocation /assistants/dbca/templates -characterset AL32UTF8 -autoGeneratePasswords -oui_internal
#示例：
[grid@rac1 ~]$ dbca -silent -createDatabase -sid -MGMTDB -createAsContainerDatabase true -templateName MGMTSeed_Database.dbc -gdbName _mgmtdb -storageType ASM -diskGroupName +OCR -datafileJarLocation /u01/gridsoft/12.1.0.2/assistants/dbca/templates -characterset AL32UTF8 -autoGeneratePasswords -skipUserTemplateCheck
```

### 7.5.4 DBCA创建PDB

```bash
[grid@rac1 templates]$ srvctl status mgmtdb
Database is enabled
Instance -MGMTDB is running on node rac1
[grid@rac1 templates]$
#在任意节点,用grid用户执行dbca 创建PDB,命令如下：
$ dbca -silent -createPluggableDatabase -sourceDB -MGMTDB -pdbName -createPDBFrom RMANBACKUP -PDBBackUpfile /assistants/dbca/templates/mgmtseed_pdb.dfb -PDBMetadataFile /assistants/dbca/templates/mgmtseed_pdb.xml -createAsClone true –internalSkipGIHomeCheck
#查询集群的名称：
[grid@rac1 /]$ cemutlo -n
rac-scan
#注意：默认情况CLUSTER_NAME 都是-,这里比如换成_,我们这里就要换成rac_scan
[grid@rac1 ~]$ dbca -silent -createPluggableDatabase -sourceDB -MGMTDB -pdbName rac_scan -createPDBFrom RMANBACKUP -PDBBackUpfile /u01/gridsoft/12.1.0.2/assistants/dbca/templates/mgmtseed_pdb.dfb -PDBMetadataFile
```

### 7.5.5 验证MGMTDB

```bash
#用grid用户执行如下命令,验证MGMTDB 运行情况：
[grid@rac1 ~]$ srvctl status MGMTDB
Database is enabled
Instance -MGMTDB is running on node rac1
#这里显示的是节点1,那么在节点1上在执行：
[grid@rac1 ~]$ mgmtca
[grid@rac1 ~]$ crsctl stat res -t
[grid@rac1 ~]$ srvctl config mgmtdb
 
[grid@rac1 ~]$ export ORACLE_SID=-MGMTDB
[grid@rac1 ~]$ sqlplus / as sysdba
SQL> select file_name from dba_data_files union select member file_name from V$logfile;
FILE_NAME
--------------------------------------------------------------------------------
+OCR/_MGMTDB/DATAFILE/sysaux.257.865977463
+OCR/_MGMTDB/DATAFILE/system.258.865977473
+OCR/_MGMTDB/DATAFILE/undotbs1.259.865977489
+OCR/_MGMTDB/ONLINELOG/group_1.261.865977635
+OCR/_MGMTDB/ONLINELOG/group_2.262.865977635
+OCR/_MGMTDB/ONLINELOG/group_3.263.865977635
6 rows selected.
SQL>
# 数据文件已经转移到OCR 磁盘组了. 
```

### 7.5.6 启用并启动ora.crf 资源

> 在所有节点,用root用户执行：

```bash
[root@rac1 u01]# crsctl modify res ora.crf -attr ENABLED=1 -init
[root@rac1 u01]# crsctl start res ora.crf -init
CRS-2672: Attempting to start 'ora.crf' on 'rac1'
CRS-2676: Start of 'ora.crf' on 'rac1' succeeded
[root@rac1 u01]# oclumon manage -get master
Master = rac1
[root@rac1 u01]#
```

# 八、Oracle Flex ASM

## 8.1 Flex ASM

### 8.1.1 概述

> Oracle RAC 12c 引入了两个新概念：

> **中心节点：**
> 和以前的版本一样,它们通过专用网络相互连接,并且可以直接访问共享存储. 这些节点可以直接访问 Oracle 集群注册表 (OCR) 和表决磁盘 (VD).

> **叶节点：**
> 这些节点是轻型节点,彼此不互连,也不能像中心节点一样访问共享存储. 每个叶节点与所连接的中心节点通信,并通过所连接的中心节点连接到集群.

> 此拓扑允许松散耦合的应用服务器与紧密耦合的数据库服务器形成一个集群. 紧密耦合的服务器是中心服务器,与集群中的其他中心服务器共享数据库、OCR 和表决设备的存储并进行对等通信. 松耦合的服务器是叶服务器,与集群中的单个中心服务器形成松散通信关联,不需要与集群中的其他中心服务器或叶服务器共享存储,也不需要与之进行对等通信,只与所关联的中心服务器通信. 在 12.1.0.1 中,叶服务器旨在提高应用的高可用性和实现多层资源管理.

> ***在 Oracle 12c 之前,对于要使用 ASM 的数据库实例来说,所有节点上的 ASM 实例必须已处于运行状态,才能启动数据库实例. 如果 ASM 实例未运行,则意味着在存储级使用 ASM 的数据库实例不能启动. 这实际上意味着无论采用何种技术(即 RAC、ASM 和共享存储),均不能访问数据库实例.
> 随着 oracle12c的推出,一个名为 Oracle Flex ASM的特性解除了上述限制,它的一个主要特性是故障切换到集群中的其他节点. 从12c开始,推出的Flex ASM特性,允许RAC节点访问远程节点的ASM实例,而自身无需运行AM实例,例如,有一个2个节点的rac,其中一个节点的As实例挂掉了,那么该节点上的数据库可以自动切换到另一个节点的AsM实例上进行通信.***

> 本质上是一个中心和叶架构,OracleClusterware 通过一个替代 ASM 实例将故障节点的连接将无缝转移到另一个成员节点. 在给定集群中运行的 ASM 实例数被称作 ASM 基数,默认值为 3. 但此基数值可以使用Clusterware 命令修改.
> Flex ASM最重要的特点就是,数据库不再依赖本节点的ASM是否正常运行. 如果某个节点的ASM异常关闭,那么该节点上的数据库会自动连接到其他节点的ASM上继续运行.

> 在oracle 18c之前,Flex ASM是一个可选项,但是从18c开始,安装界面上已经不再提供复选框了,而是默认使用Flex ASM.

> 一般在Flex集群,中心节点运行AsM实例,叶子节点远程访问中心节点的ASM 实例但是中心节点也可以不运行ASM实例而访问其他节点的ASM实例；另外,标准集群也可以启用F sM. 由于有通过网络远程访问ASM实例的状况,因此也形成了AM网络,ASM网络可与 Private网络共用,即AsM&Private网Oracle Flex ASM的本质上是一个中心和叶子架构,Oracle clusterware通过一个替代ASM实例将故障节点的连接将无缝转移到另一个成员节点. 在给定集群中运行的ASM实例数被称作ASM基数,默认值为3,但此基数值可以使用clusterware命令修改.

```bash
srvctl modify asm -count 2
srvctl config asm -detail
```

> 使用 Oracle Flex ASM时,Oracle ASM客户端可以直接访问存储,可以将所有存储需求整合到一组磁盘组中. 所有这些磁盘组由在一个集群中运行的一小组Oracle ASM实例安装和管理. 可以指定具有基数设置的Oracle ASM的数量

### 8.1.2 Oracle Flex ASM的实现方面

> Oracle Flex ASM可通过两种方式实现：
> 1).纯 12c Flex ASM(相同版本)
> Grid Infrasctructure (GI) 和数据库都运行在 Oracle 12c 上
> 2).Oracle 12c 之前的混合版本(不同版本)

> 和平常一样,ASM 实例将在每个节点上运行,Flex 配置支持 12c 之前的数据库. 使用 ASM 磁盘组的兼容性参数管理各数据库实例之间的兼容性.
> 这种方法的优点是,如果 Oracle 12c 数据库实例与一个 ASM 实例的连接断开,数据库连接将故障切换至其他服务器上的另一个ASM 实例. 通过将基数设置为 all 即可以实现这种故障切换.

> 使用 Oracle Flex ASM 的 Oracle RAC 12c
> 标准 Oracle Flex ASM 配置：

![](https://cdn.jsdelivr.net/gh/klausyao/imageshosting/oracle/rac/rac/image12.gif)

> Oracle Flex ASM 配置上的 ASM 实例故障：

## 8.2 Flex 集群

### 8.2.1 概述

> 从架构上来说,Oracle Flex 集群包括一个中心和叶架构,其中只有中心节点可以直接访问 Oracle 集群注册表 (OCR) 和表决磁盘 (VD). 但是应用可以通过叶节点访问数据库,而不必在叶节点上运行 ASM 实例. 通过中心节点连接到数据库使得它对应用透明.

> Flex ASM Cluster需要Flex ASM的支持
> Flex ASM可以在 standardcluster和Flex Cluster运行.

> 下图描绘了一个典型的 Oracle Flex 集群,包含 4 个叶节点和 2 个中心节点. 简单地说,Oracle Flex 集群需要 Oracle Flex ASM.

![](https://cdn.jsdelivr.net/gh/klausyao/imageshosting/oracle/rac/rac/image13.gif)

> 集群是提供组成员资格服务的一组节点. 每个群集都全局唯一的名称每个集群都有一个或多个Hub节点. Hub节点可以访问 Oracle ASM磁盘,每个群集至少有一个私有网络和一个公共网络. 如果集群要使用Oracle ASM进行存储,则它至少有一个Oracle ASM网络. 单个网络可以用作私有和Oracle ASM网络. 出于安全考虑,Oracle ASM网络不应公开. 集群中只能运行一个Oracle Flex ASM配置

> Oracle在12c中使用hub-and-spoken技术实现了Flex Cluster的功能(即RAC集群中的每个节点不再需要既运行ASM实例又运行DB实例,各节点可以扮演不同的角色). 相比12c以前的版本,该功能使集群规模的扩大和缩减变得更加靠谱. 原因如下
>
>> Ø  集群中各节点间网络的互相干扰变得更少
>> Ø  关键的集群组件争用更少,如OCR、VOTING DISK
>> Ø  12c引入的Flex Cluster有两种节点,hub node和leaf node.
>> Ø  hub node可以访问共享存储,leaf node不直接访问共享存储,而是通过某个hub node连入集群.
>> Ø  当leaf node上的集群件启动时,leaf node自动使用GNS来发现所有 hub node,然后通过其中一个 hub
>> node连入集群
>> Ø  如果 hub node挂了,那么通过这个 hub node访向集群的leaf node会自动切换至某存活的hub node继续访问集群
>>

### 8.2.2 Hub Node(中心节点)

> 1).这种节点几乎完全等价于12c以前版本的传统RAC节点,在12c中这种节点就是集群的核心(为什么说是核心呢？因为后面会介绍12c Flex Cluster中的非核心节点——leafnode).
> 2).每个 hub node之间通过私网连接,而且需要配置ssh对等性.
> 3).每个节点需要访问共享存储因为OCR Voting都依赖于共享存储.
> 4).hub node上既运行ASM实例又运行db实例.
> 5).每个Flex cluster至少一个 hub node,最多64个 hub node. 每个Hub节点支持64个Leaf节点,即最多支持4096个Leaf节点.

#### 8.2.3 Leaf Node(叶子节点)

> 1).	相比 hub node,leaf node对于集群来说不是那么核心,与集群耦合度很低,而且 leaf node之间不需要互联
> 2).	每个 leaf node通过—个 hub node连接集群并获取数据.
> 3).	leaf node不能直接访问共享存储
> 4).	他们上面运行着轻量版的集群件
> 5).	leaf node上面不能运行ASM实例,也不能在上面建库,因为上面运行的实例打开方式只能是只读的.
> 6).	leaf node上可运行多种应用,例如中间件、EBS、IM等,leaf node上的应用会在 leaf node挂掉后自动切换到其他leat node
> 7).	一个Flex Cluster中可包含0个或多个leaf node.
> 8).	leaf node和 hub node拥有相同的公网和私网.

> 在 Oracle 18c的环境中,默认都是Hub节点. 在 Oracle19c中,彻底去除了对于 Leaf Node的所有特性支持. 这是一个回退,说明当初的功能设计没有找到足够的用户支持.从实际情况来看,Leaf节点的意义不是很大,不仅占用单独的服务器,而且只提供只读服务,浪费资源.

> 即使Flex cluster中没有一个leaf node,hub node也可以正常的像传统rac节点一样工作. 但如果Flex Cluster中只有leaf node没有一个hub node是万万不可的,因为 leaf node需要通过 hub node上的asm实例获取数据.

> 当集群件启动在leaf node上时,leaf node就会根据GNS信息查找所有 hub node,然后选择其中一个hub node来获取数据(配置GNS是使用 leaf node的重要前提). 一个 hub node同时可能被0个或多个 leaf node连接,而一个 leaf node同时只能连接一个hub node. hub node和 leaf node之间也会交换心跳信息,只有这样 eaf node才能加入集群并作为集群的一部分.

> 标准集群可转换为Flex Cluster,但Flex Cluster无法转为标准集群,除非你重新配置(约等于重装)

## 8.3 ASM监听

> 这里三个ASM实例共用一个服务名,有点类似SCAN的意思
> $ lsnrctl status ASMNET1LSNR_ASM

> 在节点一上通过服务名连接ASM实例

```bash
[grid@ohs1 ~]$ sqlplus sys/oracle@172.16.0.21:10010/+ASM as sysasm
SQL> select instance_name from v$instance;
INSTANCE_NAME
---------------- 
+ASM3
```

> ASM监听service状况
> $ lsnrctl service ASMNET1LSNR_ASM

## 8.4 维护

### 8.4.1 查看当前集群模式是否启用Flex ASM

```bash
crsctl get cluster mode status
crsctl get cluster mode config
amscmd showclustermode
```

#### 8.4.2 查看集群节点成员角色

```bash
crsctl get node role status -all 
crsctl get node role config -all 
```

## 8.5 Flex ASM高可用测试

> 通过实验,任意节点的ASM实例的意外启动关闭都不会影响该节点的数据库状态.
> 如果没有使用Flex ASM不设置SID会出现连接到空实例,但在Flex ASM情况下,asmcmd会随机选择一个

```bash
srvctl status asm -detail
srvctl config asm -detail
srvctl status db -d orcl -detail

srvctl stop asm -node hostname01 -stopoption abort -force 
srvctl status asm
crsctl check  cluster 
srvctl start asm -node hostname01
```

## 8.6 修改ASM实例个数

> ASM至少得有两个实例,这样不至于单点故障.

```bash
srvctl status asm -detail
srvctl modify  asm -h
srvctl modify  asm -count 2
srvctl config asm -detail
crsctl stat res -t 
```

# 九、RAC数据库和单实例区别

> Oracle RAC允许多个实例访问同一个数据库.在多个服务器节点上运行的实例访问一组构成单个数据库的公共数据文件集.在单实例环境中,一个Oracle数据库仅供在服务器上运行的一个实例使用;而访问这个数据库的用户只能通过这一台服务器来连接到数据库.数据库任务能够使用的处理资源(CPU、内存等)仅限于这一台服务器上的处理资源.在Oracle RAC环境中,可以有多个实例使用同一个数据库.这一方案向数据库用户呈现了多个处理资源.

> “实例”就是一台计算机上与数据库有关的内存结构集,数据库是一个物理文件集,数据库与实例之间是一种一对多关系,在Oracle RAC中,一个数据库可以由多个实例并发使用,一个实例只是一个数据库的部分.

> 为了让RAC中的所有实例能够访问数据库,所有的数据文件(Data Files)、控制文件(Control Files)参数文件(spfi1e)和重做日志文件(Redo Log Files)必须保存在共享磁盘上,并且要能被所有节点同时访问.RAC数据库和单实例数据库具体区别如下所示：
>
>> 1).Redo和Undo,至少为每个实例多配置一个Redo线程(例如：两个实例组成的集群至少要4个Redo Log Group,每个实例两个Redo Group),另外要为每一个实例配置_个undo表空间.每个实例在做数据库的修改时都使用自己实例的Redo和Undo,各自锁定自己修改的数据,把不同实例的操作相对的独立开就免了数据不一致.在备份或者恢复时,Redo和Unao也需要按照线程(THREAD)来对待
>> 2).内存和进程,RAC的各个节点的实例都有自己的内存结构(SGA)和进程结构,各节点之间结构是基者相同的.RAC在各个节点之间通过 Cache Fusion(缓存融合)技术同步SGA中的缓存信息达到提高访问速度的效果,同时也保证了数据的一致性.
>> 3).告警(aert)日志和trace志都属于每个实例自己,其它实例不可读写.
>>

**单实例组件与****RAC****组件的对比**

| 组件                   | 单实例环境                                                     | RAC环境                                                                                                                           |
| ------------------------ | ---------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| SGA                    | 实例拥有自己的SGA                                              | 每个实例拥有自己的SGA                                                                                                             |
| 后台进程               | 实例有自己的后台进程集                                         | 实例有自己的后台进程集                                                                                                            |
| 数据文件               | 仅由一个实例访问                                               | 由所有实例共享,所以必须放在共享存储中                                                                                             |
| 控制文件               | 仅由一个实例访问                                               | 由所有实例共享,所以必须放在共享存储中                                                                                             |
| 联机重做日志文件       | 专供一个实例写入和读取                                         | 只有一个实例可以写入.但其他实例可以在恢复和存档期间读取.如果一个实例关闭,那么其他实例的日志切换可以强制对空闲实例重做日志进行存档 |
| 存档后的重做日志       | 专供该实例使用                                                 | 专属于该实例,但在媒介恢复期间,其他实例需要访问所需的存档日志                                                                      |
| 快闪恢复日志           | 仅由一个实例访问                                               | 由所有实例共享,所以必须放在共享存储中                                                                                             |
| 警报日志和其他跟踪文件 | 专供该实例使用                                                 | 专属于每个实例;其他实例永远不会读写这些文件                                                                                       |
| ORACLE HOME            | 同一台计算机上访问不同数据库的多个实例可以使用相同的可执行文件 | 与单个实例相同,但也可以放在共亨文件系统上,允许Oracle RAC环境用户的所有实例共用一个ORACLE                                          |
| HOME                   |                                                                |                                                                                                                                   |

# 十、RAC特殊问题和注意点

## 10.1 共享存储

> 在需要将一个 LUN (逻辑单元号)映射给多个节点、为集群提供一个共享的存储卷时,同一个存储 LUN 在各个主机端的 LUNID 必须是相同的.比如：
>
> (一) 在为多个 ESX 节点创建一个 VMFS 卷的时候
> (二) 在双机 HA 集群创建共享存储的时候

## 10.2 时间一致性

> 集群模式下,各个节点要协同工作,因此,各主机的时间必须一致.因此,各主机的时间必须一致.各个节点之间的时间差不能超时,一般如果超过 30s,节点很可能会重启,所以要同步各节点的时间.例如,需要配置一个 ntp 时钟服务器,来给 RAC 的各个节点进行时间同步.或者让节点之间进行时间同步,保证各个节点的时间同步,但是无法保证 RAC 数据库的时间的准确性.

## 10.3 固件、驱动、升级包的一致性

> 案例：
> XX 市,HPC 集群,运行 LS-DYNA(通用显示非线性有限元分析程序).
> 集群存储系统的环境说明：存储系统的 3 个 I/O 节点通过 FC SAN 交换机连接到一个共享的存储.
> 1).节点使用的 FC HBA 卡为 Qlogic QLE2460;
> 2).光纤交换机为 Brocade 200E
> 3).磁盘阵列为 Dawning DS8313FF

> 故障现象：
> 集群到货后发现盘阵与机器直连能通,两个设备接 200E 交换机不通.后经测试交换机 IOS 版本问题导致不能正常认出盘阵的光纤端口,与交换机的供货商联系更新了两次 IOS,盘阵的端口能正常识别,但盘阵与机器相连还是无法找到盘阵.经过今天的测试发现三台 I/O 节点采用的 HBA 卡 firmware 版本不一致.最早接光纤交换机及与盘阵直连的的 I/O1 的 firmware 为 v4.03.02,今天又拿出来的两台 I/O 节点 firmware 为 v4.06.03.用后两台测试后盘阵、机器、交换机之间可以正常通信,到今天晚上为止没有发现异常情况.从目前的情况判断是QLE2460 firmware 为 v4.03.01 的 HBA 卡与 200E IOS V5.3.1 有冲突者不兼容导致的故障.至于新的 HBA 卡 firmware为 v4.06.03 与 200E IOS V5.3.1 连接的稳定性如何还要做进一步测试.

> 诊断处理结果
> I/O 1 节点HBA卡的fimware升级到v4.06.03后连接200E找不到盘阵的故障已经得到解决.其实是一个FCHBA卡的固件版本不一致引起的问题.

## 10.4 共享文件OCR及Voting Disk

> Oracle Cluster Registry(OCR)：记录 OCR 记录节点成员的配置信息,如 database、ASM、instance、 listener、VIP 等 CRS 资源的配置信息,可存储于裸设备或者群集文件系统上.

> Voting disk： 即仲裁盘,保存节点的成员信息,当配置多个投票盘的时候个数必须为奇数,每个节点必须同时能够连接半数以上的投票盘才能够存活.初次之外包含哪些节点成员、节点的添加和删除信息.

## 10.5 安装

> 在 Oracle RAC 中,软件不建议安装在共享文件系统上,包括 CRS_HOME 和 ORACLE_HOME,尤其是 CRS 软件,推荐安装在本地文件系统中,这样在进行软件升级,以及安装 patch 和 patchset 的时候可以使用滚动升级(rolling upgrade)的方式,减少计划当机时间.另外如果软件安装在共享文件系统也会增加单一故障点.

> 如果使用 ASM 存储,需要为 asm 单独安装 ORACLE 软件,独立的 ORACLE_HOME,易于管理和维护,比如当遇到 asm 的 bug 需要安装补丁时,就不会影响 RDBMS 文件和软件.

## 10.6 脑裂和健忘

### 10.6.1 脑裂(SplitBrain)

> 在集群中,节点间通过心跳来了解彼此的健康状态,以确保各节点协调工作.假设只有“心跳”出现问题,但各个节点还在正常运行,这时, **每个节点都认为其它的节点宕机了** ,自己才是整个集群环境中的“唯一健在者”,自己应该获得整个集群的“控制权”.在集群环境中,存储设备都是共享的,这就意味着数据灾难.简单点说,就是如果由于私有网络硬件或软件的故障,导致集群节点间的私有网络在一定时间内无法进行正常的通信,这种现像称为脑裂.在发生脑裂情况后,集群的某些节点间的网络心跳丢失,但磁盘心跳依然正常,集群根据投票算法(Quorum
> Algorithm)将不正确的节点踢出集群.磁盘心跳的主要目的是当集群发生脑裂时可以帮助指定脑裂的解决方案.

> 私网网络不能正常通信有一个超时时间,称为MC(Misscount),默认为30s(通过命令“crsctl get css
> misscount”查询).该时间允计集群节点间不能正常通信的最大时间为30s,如果超过30s,那么Oracle认为节点间发生了脑裂.在出现脑裂后,集群的重要任务就是保证错误节点与正确节点间的I/O是隔离的,这样才能避免对数据造成不一致的损坏.处理这个问题的方法就是：踢出错误节点执行修复过程.

### 10.6.2 健忘(Amnesia)

> 集群环境的配置文件不是集中存放的,而是每个节点都有一个本地副本,在集群正常运行时,用户可以在任何节点更改集群的配置,并且这种更改会自动同步到其它节点.健忘是由于某个节点更新了OCR(Oracle Cluster Registry,Oracle集群注册)中的内容,而集群中的另外一些节点此时处于关闭、维护或重启阶段,OCR Master进程来不及将其信息更新到这些异常节点缓存而导致的不一致.譬如,A节点发出了添加OCR镜像的命令,在这个时候B节点处于重启阶段.重启后A已经更新完毕,而此时B并不知道已经为OCR增加了一个新的镜像磁盘,健忘由此而生.OCR用于解决健忘问题.

> 说明：Oracle Clusterware把整个集群的配置信息放在共享存储上,这个存储就是OCR Disk.在整个集群中,只有一个节点能对OCR Disk进行读写操作,这个节点叫作Master Node.所有节点都会在内存中保留一份OCR的拷贝,同时有一个OCR Process从这个内存中读取内容.当OCR内容发生改变时,由Master Node的OCR Process负责同步到其它节点的OCR Process.

# 十一、RAC维护Q&A

## 11.1 判断是否RAC库

```sql_more
SQL> show parameter cluster
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
cdb_cluster                          boolean     FALSE
cluster_database                     boolean     TRUE
cluster_database_instances           integer     2
cluster_interconnects                string
```

## 11.2 判断是否ASM实例

```sql_more
SQL> show parameter instance_type
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
instance_type                        string      ASM
```

## 11.3 查看集群的名称

```sql_more
--方法一
[grid@rac02 ~]$ cemutlo
Usage: /u01/app/19.3.0/grid/bin/cemutlo.bin [-n] [-w]
        where:
        -n prints the cluster name
        -w prints the clusterware version in the following format:
                 <major_version>:<minor_version>:<vendor_info>
[grid@rac02 ~]$ cemutlo -w
2:1:
[grid@rac02 ~]$ cemutlo -n
rac-cluster
--方法二
[grid@rac02 ~]$ olsnodes -c
rac-cluster
```

## 11.4 RAC环境下的Redo文件可以放在节点本地吗？

> 不能.同单实例的系统一样,在RAC环境中,每个节点实例都需要至少两组Redo日志文件,且每个节点实例有自己独立的Redo日志线程(由初始化参数THREAD定义),例如

```sql
SQL> SELECT B.THREAD#,A.GROUP#,A.STATUS,A.MEMBER,B.BYTES,B.ARCHIVED,B.STATUS FROM V$LOGFILE A,V$LOG B WHERE A.GROUP#=B.GROUP#;
```

> RAC环境中的Redo日志文件必须部署到共享存储中,而且需要保证可被集群内的所有节点实例访问到.当某个节点实例进行实例恢复或介质恢复的时候,该节点上的实例将可以应用集群下所有节点实例上的Redo日志文件,从而保证恢复可以在任意可用节点进行.

## 11.5 RAC环境下所有数据库实例可以使用同一个Undo表空间吗？

> 不能.
> RAC下的每个节点实例需要有自己单独的Undo表空间.由初始化参数“UNDO_TABLESPACE”指定.同Redo一样,Undo表空间也需要部署到共享存储,虽然每个节点上Undo的使用是独立的,但需要保证集群内其它节点实例能对其访问,以完成构造读一致性等要求,配置如下所示：

```sql
SQL>ALTER SYSTEM SET UNDO_TABLESPACE=UNDO1 SID='orcl1';
SQL>ALTER SYSTEM SET UNDO_TABLESPACE=UNDO2 SID='orcl2';
show parameter undo_tablespace
```

## 11.6 Alter system switch logfile和alter system archivelog current的区别

> 语句的作用是强制系统进行日志切换
> ALTER SYSTEM SWITCH LOGFILE             对单实例数据库或RAC中的当前实例执行日志切换.
> ALTER SYSTEM ARCHIVE LOG CURRENT  会对数据库中的所有实例执行日志切换.
> 在RAC中也可以指定实例切换:
> Alter system archive log instance 'orcl2' current

## 11.7 RAC中如何删除归日志

## 11.8 指定JOB的运行实例

## 11.9 将一个数据库加入crs

## 11.10 clusterware启动顺序

## 11.11 ora.cvu后台进程

## 11.12 RAC中当前实例kill另一个实例中的会话

> 在 oracle11g中很好实现,只需要在命令"ALTER SYSTEM KILL SESSION'SID,SERIAL IMMEDIATE;"中的 SERIAL#后加上实例号即可.如果要杀掉实例2上的“71,20925″的会话,那么在任意一个节点上执行："ALTER SYSTEM DISCONNECT SESSION '171,20925,@2 ' IMMEDIATE;”即可,但是orac1e11g以下版本的RC中就只能连接到相应的实例上才能杀掉当前实例的会话.其实,有一种折中的办就是创建JOB,让该JOB可以在指定的实例上运行 KILL SESSION的命令,这个具体代码留给读者来完成.

```sql
SELECT a SID,
b.SERIAL#,
c.SPID ospid,
c.pid orapid 
FROM v$mystat a,
v$session b ,v$process c
WHERE a SID= b.SID 
and b.PADDR=c.ADDR 
AND rownum=1;

ALTER SYSTEM DISCONNECT SESSION '71,20925,@2' IMMEDIATE;
```

## 11.13 RAC节点被踢出的原因有哪些

> 可能的原因包括：服务器负载严重或内核HANG住、网络心跳丢失、磁盘心跳丢失、CSSD进程HANG住.

## 11.14 集群中的Master Node体现在哪两个方面

> 在RAC中有两种Masters,一种是Clusterware层面的,另一种是Block层面的Masters.

> 首先,对于Clusterware层面的Master Node来说,OCR Master是负责更新OCR的,而且也只有OCR Master才可以更新OCR的内容.默认集群中首先启动的节点就是OCR Master.当OCR Master的crsd.bin进程停止或重启的时候,此时集群中其它存活的crsd.bin进程的节点中Node
> Number最小的就成为了新的OCR Master.

> 有两种办法可以查询OCR Master：
>
>> 第一种办法是查询日志：
>> grep "OCR MASTER" $ORA_CRS_HOME/log/$HOSTNAME/crsd/crsd.log
>> 如果是主节点,那么会显示如下内容：
>> 2018-07-05 20:03:52.078: [  OCRMAS][280024832]th_master:12: I AM THE NEW OCR MASTER at incar 1. Node Number 1
>> 而其它节点有相应的内容：
>> 2018-07-05 20:03:57.819: [  OCRMAS][688592640]th_master: NEW OCR MASTERIS 1
>> 以上日志说明,主节点是节点1.
>> 第二种办法是查询OCR的自动备份.OCR自动备份只发生在Master Node.如果Master Node备份OCR失败,那么OCR备份会在新的Master上进行.可通过执行如下命令查看OCR备份信息：
>> $ocrconfig -showbackup   ---OCR自动备份默认每4小时一次
>> 对于Block层面的Masters主要用于Cache Fusion.任何节点都可以成为特定Block的Master Node,可以通过V$GES_RESOURCE中的MASTER_NODE列查询.
>>

## 11.15 RAC等待事件

> gc buffer busy是RAC数据库中常见的等待事件从 oracle11g开始 gc buffer busy分为 gc buffer
> busy acquire和 gc buffer busy release.

> gc buffer busy acquite是当会话1尝试请求访问远程实例上的数据块,但是在会话1之前已经有相同实例上另外一个会话2请求访问了相同的数据块,并且没有完成,那么会话1等待 gc buffer busy
> acquire .

> gc buffer busy release是在会话1之前已经有***远程实例***的会话2请求访问了相同的数据块,并且没有完成,那么会话1等待 gc buffer busy release.

## 11.16 套接字文件

> 套接字文件(Socket File)在RAC环境中承担着许多集群进程之间的通信任务,这些进程可以来自于集群的不同节点.这些套接字文件一般保存在tmp路径下,不同的操作系统其路径也会不同.Linux环境的套接字文件在/var/tmp/.oracle文件夹下,在其它平台,可能的目录有：/tmp/.oracle/*,/tmp/.oracle或者/usr/tmp/.oracle.若删除这些套接字文件或修改这些套接字文件的权限,则可能引起各种各样的问题,而且这些套接字文件不能手动修复,只能通过重启集群的方式来生成全新的套接字文件,即集群每次在启动的时候都会重新生成新的套接字文件.以下是套接字文件的列表

```bash
[root@node1 tmp]# cd /var/tmp/.oracle
```

## 11.17 oraInventory目录的作用

### 11.17.1 中央目录

> 由于 oracle支持将多个 Oracle软件(或者多版本的数据库软件)安装到同一台服务器上,这就需要个位置统一记录安装的软件信息.中央目录(Centra1 Inventory)实际上就是一台主机上安装的 oracle产品清单.在这个清单里记录了每一个 Oracle软件主目录的名称和位置、安装的组件,以及一些其它的信息.

> OUI在安装产品时会读取中央目录来确认已经安装过的产品信息,确保新安装的产品不会和已存在的产品冲突而且不会覆盖掉原有的产品.另外,oracle的集群和数据库软件在进行升级时,OUI也是通过读取中央目录中的信息来确认哪些软件应被安装的.中央目录(Central Inventory)所有的 Oracle软件安装都依赖于该目录,所以,要确保该目录已经备份,删除或丢失oraInventory目录的内容,都有可能导致安装或升级报错另外,Oracle的软件产品通常比较复杂,包含很多组件,所以还需要一个更加细致的清单来记录每一个ORACLE_HOME下所安装的产品组件.而本地目录(Local Inventory)就是这样一个清单,它记录了每个产品所安装的组件,以及每个组件上应用过的补丁程序信息.

> oraInventor目录的位置是由oraInst.loc文件决定的
> l   AIX和 Linux平台：/etc/orlest.1
> l   Solaris和Hp-Ux平台：/va/opt/oracle/0ans
> l   Windows平台：HKEY LOCALN MACHII
> ftware/Oracle/inst loc默认情况下它保存在.

> CLE BASE上层路径的inVentory路径下,例如

```bash
# ls more/etc/oraInst loc
inventory loc=/u01/app/oraInventory
inst_group=oinstall
```

> 一旦中央目录文件出现了损坏,请尝试使用以下的两种方式恢复该文件：
> 方式1：如果其他节点的 nventory,xm没有损坏,可以将其复制到本地节点以覆盖原有文件
> 方式2：使用$ GRID HOME/oui/bn/runinstaller工具重建 inventory,xm1文件.

> 例如
> 步骤1：删除所有节点下的 inventory.xm1文件
> rm-rf/u01/app/oraInventory/ContentsXML/inventory.xml
> 步骤2：添加 GI_HOME
> ./runInstaller -silent -ignoreSysPrereqs -attachHome
> ORACLE_HOME="/u01/app/11.2.0/grid" ORACLE_HOME_NAME="OraGIllHomel"
> CLUSTER_NODES=test1,test2 CRS=true "INVENTORY_LOCATION **=** /u01/app/oraInventory" LOCAL NODE=test1
> 步骤3：添加 RDBMS_HOME
> ./runInstaller -silent -ignoreSysPreregs -attachHome
> ORACLE_HOME="/u02/app/oracle/product/11.2.0/db_1" ORACLE_HOME_NAME="OraDB1lHomel" CLUSTER_NODES=test1,test2 CRS=true "INVENTORY_LOCATION=/u01/app/oraInventory" LOCAL NODE=test1

> 作者就曾遇到过一次与该目录有关的异常：在RAC环境中,无论使用DBCA图形界面还是采用静默方式来创建数据库,最终创建的数据库都是单实例数据库,不能成功创建所需要地RAC库,最后查到的原因竟然是
> /u0/app/oraInventory/Contents/inventory,xm1文件中缺少了DB的部分
> 其实也可以执行如下脚本修复
> $ORACLE_HOME/oui/bin/attachHome.sh
> 但是,对于RAC环境,改脚本执行完毕后,需要对inventory.xml文件做些修改.

### 11.17.2 本地目录

> Local Inventory用于保存某一个 ORACLE_HOME下所安装的组件清单,它位于ORACLE_HOME/inventory下,由于Local Inventory针对特定的软件主目录所以并不存在inventory.xm文件.

> 文件$ ORACLE_HOME/inventory/Contentsxml/comps.xml记录了对应主目录下安装的历有组件.通常情况下,由于每一个 Oracle产品都包含了很多组件,所以 comps.xml文件的结构也很复杂.

## 11.18 root.sh脚本的作用

> 该脚本主要执行CRS的配置,格式化OCR磁盘,更新/etc/inittab文件,启动ossα进程,新建/oracle/ocr,loc文件等,是RAC安装过程中非常重要的一步.若后期OCR、OLR或表决磁盘出现问题都可以通过重新执行root.sh脚本来修复集群的配置信息.

> crsctl query css votedisk

> 重新执行root.sh脚本的过程如下所示
> --卸载配置信息,除了最后一个节点
> $GRID_HOME/crs/install/rootcrs.pl -deconfig -force -verbose
> --最后一个节点可保留磁盘组
> $GRID_HOME/crs/install/rootcrs.pl -deconfig -force -verbose -lastnode -keepdg

> 重启重新执行
> $GRID_HOME/root.sh
> 需要注意的是,从12.1.0.2开始,rootcrs.pl需要替换为rootcrs.sh,否则在执行时会报错.
> 另外,deconfig执行完成后可以考虑删除以下文件：
> ls -l $GRID_BASE/Clusterware/ckptGridHA*
> find $GRID_HOME/gpnp/* -type f
> find $GRID_HOME/gpnp/* -type f -exec rm -rf {} \;

> 以上也是清除CRS配置信息的步骤

> 集群的配置信息包含在文件 GRID_HOME/crs/install/crsconfig_params中,
> root.sh脚本根据该文件的配置信息设置OCR的内容.在执行root.sh脚本的过程中产生的日志在目录GRID_HOME/cfgtoo11ogs/crsconfig/下,
> 从12.1.0.2开始root.sh脚本产生的日志在目录$ORACLE_HOME/install/下.

> 在root.sh脚本执行完毕后,需要再次将数据库、监听和SERVICE等其它资源添加进集群中:

```bash
srvctl add db -d orcl -r PRIMARY -o $ORACLE_HOME
srvctl add instance -d orcl -i orcl1 -n orcl1 -n hoatname1
srvctl add instance -d orcl -i orcl2 -n orcl2 -n hoatname2
srvctl add listener -l LISTENER -o $ORACLE_HOME
```

最后修改：2022 年 04 月 07 日

如果觉得我的文章对你有用，请随意赞赏

发表评论取消回复

评论 *

私密评论

名称 *

🎲

邮箱 *

地址

【概念文档】RAC 介绍

lo8ol • 2021 年 08 月 01 日

# 一、集群介绍

## 1.1 集群术语须知

## 1.2 什么是集群

### 1.2.1 分布式与集群的联系与区别

### 1.2.2 集群主要分成三大类

## 1.3 为什么搭建数据库集群

## 1.4 数据库集群的分类

## 1.5 可扩展的分布式数据库架构

### 1.5.1 Oracle RAC

### 1.5.2 MySQL Cluster

### 1.5.3 分布式数据库架构

### 1.5.4 CAP和BASE理论

> 定理：任何分布式系统只可同时满足二点,没法三者兼顾.
> 忠告：架构师不要将精力浪费在如何设计能满足三者的完美分布式系统,而是应该进行取舍.

### 1.5.5 跨数据库事务

# 二、高可用产品对比

## 2.1 什么是高可用

> Oracle failsafe、Data Guard 和 RAC 均为 ORACLE 公司提供的高可靠性(HA)解决方案.然而之三者之间却存在着很大区别.,但是这几种方案之间却存在着很大区别.

## 2.2 FAILSAFE和RAC的区别

### 2.2.1 操作系统

### 2.2.2系统结构

### 2.2.3运行机理

### 2.2.4集群容量

> 前者通常为两台,后者在一些平台上能扩展至 8 台.

### 2.2.5分区

## 2.3 RAC和OPS区别

## 2.4 双机热备、RAC、DG、OGG的区别

> RAC和DG是高可用体系中的常用的两种工具,每个工具既可以独立应用,也可以相互配合使用. 但是它们各自的侧重点不同,适用场景也不同.

### 2.4.1 双机热备份方式

### 2.4.2 RAC方式

#### 2.4.2.1 相对于双机热备份方式

#### 2.4.2.2 RAC的好处

#### 2.4.2.3 可伸缩性

#### 2.4.2.4 高可用

> 只要有一个数据库节点幸存,Real Application Clusters就能够提供完全的数据库访问和相对不间断的操作.

#### 2.4.2.5 可管理性

#### 2.4.2.6 总结

# 三、Oracle集群概念和原理

## 3.1Oracle的三种高可用集群方案

### 3.1.1 RAC(Real Application Clusters)

![请输入图片描述](https://cdn.jsdelivr.net/gh/klausyao/imageshosting/oracle/rac/rac/image01.gif)

### 3.1.2 Data Guard(最主要的功能是冗灾)

![](https://cdn.jsdelivr.net/gh/klausyao/imageshosting/oracle/rac/rac/image02.gif)

### 3.1.3 MAA

![](https://cdn.jsdelivr.net/gh/klausyao/imageshosting/oracle/rac/rac/image03.gif)

> MAA(Maximum Availability Architecture)其实不是独立的第三种,而是前面两种的结合,来提供最高的可用性.每个机房内部署RAC集群,多个机房间用Data Guard同步.

## 3.2 RAC概述

> 下图是一个典型的 RAC 对外服务的示意图,一个Oracle RAC Cluster 包含了如下的部分

![](https://cdn.jsdelivr.net/gh/klausyao/imageshosting/oracle/rac/rac/image04.gif)

## 3.3 RAC集成集群件管理

## 3.4 RAC的体系结构

### 3.4.1 RAC结构图

> RAC 是 Oracle 数据库的一个群集解决方案,是有着两个或者两个以上的数据库节点协调运作能力的.如下图所示的 RAC 结构图：

![](https://cdn.jsdelivr.net/gh/klausyao/imageshosting/oracle/rac/rac/image05.gif)

![](https://cdn.jsdelivr.net/gh/klausyao/imageshosting/oracle/rac/rac/image06.gif)

### 3.4.2 RAC后台进程

> Oracle RAC 有一些自己独特的后台进程,在单一实例中不发挥配置作用.如下图所示,定义了一些 RAC 运行的后台进程.这些后台进程的功能描述如下.

![](https://cdn.jsdelivr.net/gh/klausyao/imageshosting/oracle/rac/rac/image07.gif)

#### 3.4.2.1 LMS(Global cache service processes全局缓存服务进程)

> RAC中特别的实例进程,控制到远端实例的消息的流量,管理全局数据块的访问.还用于在不同实例的缓冲区之间传递 BLOCK 的映射.

#### 3.4.2.2 LMON(Lock Monitor Process,锁监控进程)

#### 3.4.2.3 LMD(the global enqueue service daemon,锁管理守护进程)

> 管理全局队列和全局资源访问.对于每个实例,LMD 管理来自远端的资源请求.

#### 3.4.2.4 LCK(the lock process,锁进程)

> 管理除 Cache Fusion 以外的非数据块资源请求,比如数据文件,控制文件,数据字典试图,library 和 row cache 的请求.

#### 3.4.2.5 DIAG(the diagnosability daemon,诊断守护进程)

> 在实例中捕获进程失败的诊断数据.

#### 3.4.2.6 GSD(the global service daemon,全局服务进程)

> 在每个节点上都运行一个全局服务后台进程,用于接收客户端如DBCA、EM 等发出的管理消息,并完成相应的管理任务,比如实例的启动和关闭.

### 3.4.3 RAC全局服务

#### 3.4.3.1 Global Enqueue Service

#### 3.4.3.2 Global Cache Service

#### 3.4.3.3 RAC的GES/GCS原理

#### 3.4.3.4 GCS和GES特性

## 3.5 RAC中的特点

## 3.6RAC优缺点

#### 3.6.1 优点

### 3.6.2 缺点

# 四、RAC相关组件

## 4.1 集群软件ClusterWare架构

### 4.1.1 集群软件

> 从 Oracle10g 起,Oracle 提供了自己的集群软件,叫做 Oracle Clusterware,简称 CRS,这个软件是安装 oraclerac 的前提,而上述第三方集群则成了安装的可选项.

#### 4.1.2 Clusterware的启动脚本

### 4.1.3 Clusterware后台进程

#### 4.1.3.1 OPROCD

> 集群进程管理 —Process monitor for the cluster. 用于保护共享数据 IO fencing.仅在没有使用 vendor 的集群软件状态下运行

#### 4.1.3.2 EVMD

> 事件检测进程,由 oracle 用户运行管理

#### 4.1.3.3 CRS/CRSD

#### 4.1.3.4 CSS/CSSD

## 4.2 RAC共享存储

> RAC共享存储独立于实例之外的信息,如ocr和votedisk以及数据文件都存放在这个共享存储里的.有OCFS、OCFS2、RAW、NFS、ASM 等这样的一些存储方式.

## 4.3 集群IP的网络通信

### 4.3.1 规划

### 4.3.2 节点间的通信(Interconnect)

#### 4.3.2.1 通信网络

![](https://cdn.jsdelivr.net/gh/klausyao/imageshosting/oracle/rac/rac/image08.gif)

#### 4.3.2.2 CSS心跳

### 4.3.3 Public IP

### 4.3.4 Private IP

> 专用网络

### 4.3.5 Virtual IP(VIP)

#### 4.3.5.1 概述

#### 4.3.5.2 VIP的特点

#### 4.3.5.3 VIP漂移实验

### 4.3.6 SCAN IP

### 4.3.7 GNS VIP

### 4.3.8 HAIP(Highly Available IP)

#### 4.3.8.1 概述

#### 4.3.8.2 HAIP漂移实验

#### 4.3.8.3 禁用HAIP

### 4.3.9 透明应用切换(TAF)

### 4.3.10 TAF配置测试

### 4.3.11 连接负载均衡

## 4.4 集群心跳

### 4.4.1 ocssd和css

### 4.4.2 三种心跳

> Oracle集群有3种心跳机制,分别为网络心跳(Network HeartBeat,NHB)、磁盘心跳(Disk HeartBeat,DHB)和本地心跳(Local HeartBeat,LHB)

```bash
[grid@rac01 rac01]$ crsctl get css misscount
CRS-4678: Successful get misscount 30 for Cluster Synchronization Services.

[grid@rac01 rac01]$ crsctl get css disktimeout
CRS-4678: Successful get disktimeout 200 for Cluster Synchronization Services.
```

### 4.4.3 网络心跳机制

> 上面的查询结果表明,如果集群各节点间内联网络延迟大于30s,Oracle认为节点间发生了脑裂,需要将故障节点逐出集群.

> 如何寻找故障节点,Oracle则通过投票算法来决定,下面是一个算法描述示例,描述参考大话Oracle RAC.

### 4.4.4 磁盘心跳机制

### 4.4.5 Reboottime

关于心跳还有一个参数为reboottime(short I/O timeout),该参数表示节点被踢出之后,节点开始重启允许的最大时间,默认为3s,如下所示

```bash
[grid@rac01 rac01]$ crsctl get css reboottime
CRS-4678: Successful get reboottime 3 for Cluster Synchronization Services.
```

### 4.4.6 查看心跳配置

```

### 4.4.7 心跳调优和设置

## 4.5 集群日志体系

### 4.5.1 Redo Thread

### 4.5.2 Archive log

### 4.5.3 Trace log

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

### 4.5.4 12c之前日志位置

#### 4.5.4.1 alert.log

```bash
[grid@rac01 rac01]$ cd $ORACLE_HOME/log/$HOSTNAME/
```

#### 4.5.4.2 Clusterware后台进程日志

#### 4.5.4.3 Nodeapp日志

```bash
$ORACLE_HOME/log/$HOSTNAME/racg/
```

#### 4.5.4.4 工具执行日志

```bash
$ORACLE_HOME/log/$HOSTNAME/client/
$ORACLE_HOME/log/$HOSTNAME/client/
$ORACLE_HOME/log/$HOSTNAME/racg
```

#### 4.5.5 12c之后日志位置

集群的告警日志已经归于ADR中,目录位置在ORACLE_BASE/diag/crs/$HOSTNAME/crs/trace中

## 4.6集群(RAC)的时间同步

> 需要注意的是,要让CTSS处于活动模式,则不仅要关闭NTP服务(/sbin/service ntpd stop),还要删除/etc/ntp.conf文件(mv/etc/ntp.conf /etc/ntp.conf.bak),否则不能启用CTSS.

### 4.6.1 CTSS同步模式

### 4.6.2 NTP同步模式

### 4.6.3 模拟集群时间不一致

## 4.7 OCR、OLR和VF

### 4.7.1 OCR概念

> Oracle集群软件(Clusterware)把整个集群的配置信息放在共享存储上,这个存储就是OCR磁盘(OCR Disk).

> 需要注意的是,OCR和VF的信息不会被分布到多块磁盘上,如果用一块磁盘保存OCR或VF的话,那么一定会保存完整的OCR和VF信息.

#### 4.7.1.1 OCR结构

> (一) OCR KEY是树形结构.
> (二) OCR PROCESS 每个节点都有 OCR CACHE的复制,由 ORC MASTER 节点负责更新到 OCR DISK

OCR的结构如下图所示

![](https://cdn.jsdelivr.net/gh/klausyao/imageshosting/oracle/rac/rac/image09.gif)

#### 4.7.1.2 文件位置

#### 4.7.1.3 OCR key文件信息

### 4.7.2 OCR命令

#### 4.7.2.1 ocrdump

> 该命令能以ASCII的方式打印出OCR的内容,但是这个命令不能用作OCR的备份恢复,也就是说产生的文件只能用作阅读,而不能用于恢复.

#### 4.7.2.2 ocrcheck

#### 4.7.2.3 ocrconfig

### 4.7.3 OCR备份恢复

#### 4.7.3.1 (自动备份)物理ocrconfig

> 在缺省情况下,OCR自动备份在$CRS_HOME/CRS/CDATA/cluster_name目录下,可以通过ocrconfig -backuploc<directory_name>命令修改到新目录

> 与Oracle数据库的备份恢复相似,OCR的备份也有物理备份和逻辑备份,因此有两种备份方式和两种恢复方式.物理备份是自动进行的,逻辑备份需要手动进行.

> 下例为物理备份OCR

bash> 物理恢复OCR的过程一般有如下几个步骤

#### 4.7.3.2 (手动备份)逻辑导入导出

```bash
ocrconfig -export /tmp/ocr_bak
ocrconfig -import /tmp/ocr_bak
```

#### 4.7.3.3 dd备份恢复

```bash
备份表决磁盘
dd if=/dev/raw/raw3 of=/tmp/votedisk01.bak bs=1024k count=4
恢复表决磁盘
dd if=/dev/raw/votedisk01.bak of=/tmp/raw3 bs=1024k count=4
```

#### 4.7.3.4 kred恢复磁盘头

#### 4.7.3.5 md_backup和md_restore

### 4.7.4 OLR

#### 4.7.4.1 概念

```bash
[grid@rac02 /]$ more /etc/oracle/olr.loc
olrconfig_loc=/u01/app/11.2.0/grid/cdata/rac02.olr
crs_home=/u01/app/11.2.0/grid
```

#### 4.7.4.2 OLR备份恢复

### 4.7.5 VF (Voting File)表决磁盘文件

在安装集群时也会提示指定表决磁盘的位置.安装完成后可以通过如下命令来查看表决磁盘的位置.

另外,也可以从V$ASM_DISK这个视图中查询,VOTING_FILE列为Y的表示包含表决磁盘

下表对OCR和VF做简单比较

### 4.7.6 替换OCR磁盘组的步骤

#### 4.7.6.1 添加新存储

#### 4.7.6.2 多路径绑定配置

#### 4.7.6.3 ASMLib 配置或udev绑定

#### 4.7.6.4 备份OCR

#### 4.7.6.5 新建OCR卷组

#### 4.7.6.6 替换VOTE在其中一个节点,root用户下执行

```

#### 4.7.6.7 替换OCR 在grid或root用户下执行,只需要在一个节点上操作即可

```bash
#主要命令：
ocrconfig -add +newocr
more /etc/oracle/ocr.loc
ocrconfig -delete +ocr
more /etc/oracle/ocr.loc
ocrcheck

#### 4.7.6.8 迁移ASM Spfile   (和实例的spfile是两码事)grid用户执行

#### 4.7.6.9 确认老的OCR磁盘组是否还有其他文件

#### 4.7.6.10 删除老OCR卷组

```bash
#在节点1和节点2分别重启集群
crsctl stop crs
crsctl start crs
--节点2：
su - grid
sqlplus / as sysasm
alter diskgroup OCR dismount;
exit

```

#### 4.7.6.11 删除磁盘

#### 4.7.6.12 删除crs记录

> crsctl delete res ora.OCR.dg

## 4.8 GPnP

### 4.8.1 组成

> GPnP profile文件默认的保存位置是：
>
> ```bash
> $GRID_HOME/gpnp/$HOSTNAME/profile/peer/profile.xml
> $GRID_HOME/gpnp/profiles/peer/profile.xml  #全局备份
> ```

```bash
cluvfy comp gpnp [-n node_list][-verbose]
```

### 4.8.2 GPnP用途

# 五、缓存融合技术

## 5.1Cache Fusion原理

## 5.2 锁

## 5.3 一致性管理

> SQL92 根据这些对象定义了 4 个隔离级别,事务运行在特定的隔离级别允许特别的一些表现.如下表表示隔离级别阻止的读现象.

![](https://cdn.jsdelivr.net/gh/klausyao/imageshosting/oracle/rac/rac/image10.gif)

## 5.4 RAC的并发控制

DLM 分布式锁管理.

## 5.5 RAC重构触发条件

# 六、RAC中的工具

## 6.1 CHM

### 6.1.1 作用

> CHM主要包括两个服务：
> 1、System Monitor Service(osysmond)：这个服务在所有节点都会运行,osysmond会将每个节点的资源使用情况发送给Cluster

```bash
[root@rac2 ~]# ps -ef|grep osysmond
root     29498     1  1 15:18 ?        00:01:31 /u01/app/11.2.0/grid/bin/osysmond.bin
```

### 6.1.2 CHM工具

### 6.1.3 OSWatcher工具

## 6.2 cluvfy

### 6.2.1 cluvfy工具介绍

> 使用命令cluvfy stage -list可以查看所有阶段.使用命令cluvfy comp -list可以查看所有组件.将list修改为help可以查看相应的命令.

```bash
[grid@orcl ~]$ cluvfy stage -list

USAGE:
cluvfy stage {-pre|-post} <stage-name> <stage-specific options>  [-verbose]

> 比较常用的就是使用cluvfy命令进行安装集群之前的系统检查,如下所示：
>
> ```bash
> $ORACLE_HOME/bin/cluvfy stage  -pre crsinst -n all -r 11gR2 -verbose -fixup
> ```

### 6.2.2 cvuqdisk包的作用是什么？

cvuqdisk的RPM包含在Oracle Grid Infrastructure安装介质上的rpm目录中.以root用户在RAC的2个节点上都进行安装,如下：

```bash
export CVUQDISK_GRP=oinstall
rpm -iv cvuqdisk-1.0.9-1.rpm
```

## 6.3 kfed、kfod和amdu

```bash
$ORACLE_HOME/bin/kfod disk=asm s=true ds=true c=true
```

```bash
kfed read /dev/raw/raw1
```

# 七、MGMTDB

## 7.1 GIMR概念

![](https://cdn.jsdelivr.net/gh/klausyao/imageshosting/oracle/rac/rac/image11.gif)

## 7.2 MGMTDB基本信息

### 7.2.1 什么是管理资料库？

> 实际上,MGMTDB是带一个PDB的CDB库,可以使用GI的命令直接去操作MGMTDB对应的PDB

> Oracle Restart环境是没有MGMTDB的.

> 另外,对于MGMTDB数据库,在目前的版本中,也不需要手工对其进行备份

### 7.2.2 管理资料库作用

### 7.2.3 管理资料库的数据文件位置

### 7.2.4 如果不配置管理资料库会有什么影响？

> 管理资料库在12.1是非强制的,如果在使用OUI安装升级的时候未选择该选项,所有的依赖于管理资料库的功能都会被禁用(比如CHM/OS等)

> 在12.1.0.2中,管理资料库变为强制安装(除了Exadata环境).

> 对于ODA18.3和更高版本,GIMR不是强制需要的

### 7.2.5 有没有必要去手动备份或优化资料库？

> 目前没有必要

### 7.2.6 在Oracle Restart环境下,GIR会被默认刨建吗？

> 不.
> 在 Oracle restart环境下GIMR默认不会被创建. 手动创建 MGMTDB也会报错

### 7.2.7 需要分配多少磁盘空间给资料库？

> 注意：在 Oracle18c(12.2.0.2)环境中,至少需要30G的空间

## 7.3 常用命令

### 7.3.1 命令

```

### 7.3.2 启动关闭MGMTDB

> 正常情况下,MGMTFB会随着GI自动启动,也可以手工管理,使用srvctl操作即可.
> 登陆MGMTDB实例

## 7.4 MGMTDB的Log和trace文件

> cd到管理资料的子目录去查看跟踪文件
> 进入$GRID_HOME下的trace目录. 进入-MGMTDB时,注意不能直接cd:

```sql_more
[grid@rac01 _mgmtdb] cd -MGMTDB
--报错,必须使用./-MGMTDB 
[grid@rac01 _mgmtdb] cd ./-MGMTDB
[grid@rac01 -MGMTDB] ls
[grid@rac01 -MGMTDB] cd trace 
select * from v$diag_info;

[grid@rac01 ~]$ adrci
adrci>show home
```

## 7.5 移动MGMTDB的位置

> 具体操作如下

### 7.5.1 停止并禁用ora.crf 资源

> 这里的ora.crf就是CHM.
> 在所有节点使用root用户执行如下命令

```bash
crsctl stop res ora.crf -init
crsctl modify res ora.crf -attr ENABLED=0 -init
#注意：ora.mgmtlsnr 和 ora.mgmtdb 资源不能停,否则DBCA 时会报错
```

### 7.5.2 执行DBCA删除MGMTDB

### 7.5.3 重建MGMTDB的CDB

> 用grid用户,在任意节点,执行如下命令,重建CDB.

#### 7.5.3.1 12.1.0.1 执行如下命令

#### 7.5.3.2 12.1.0.2  执行如下命令

### 7.5.4 DBCA创建PDB

### 7.5.5 验证MGMTDB

### 7.5.6 启用并启动ora.crf 资源

> 在所有节点,用root用户执行：

# 八、Oracle Flex ASM

## 8.1 Flex ASM

### 8.1.1 概述

> Oracle RAC 12c 引入了两个新概念：

> 在oracle 18c之前,Flex ASM是一个可选项,但是从18c开始,安装界面上已经不再提供复选框了,而是默认使用Flex ASM.

```bash
srvctl modify asm -count 2
srvctl config asm -detail
```

### 8.1.2 Oracle Flex ASM的实现方面

> 使用 Oracle Flex ASM 的 Oracle RAC 12c
> 标准 Oracle Flex ASM 配置：

![](https://cdn.jsdelivr.net/gh/klausyao/imageshosting/oracle/rac/rac/image12.gif)

> Oracle Flex ASM 配置上的 ASM 实例故障：

## 8.2 Flex 集群

### 8.2.1 概述

> Flex ASM Cluster需要Flex ASM的支持
> Flex ASM可以在 standardcluster和Flex Cluster运行.

> 下图描绘了一个典型的 Oracle Flex 集群,包含 4 个叶节点和 2 个中心节点. 简单地说,Oracle Flex 集群需要 Oracle Flex ASM.

![](https://cdn.jsdelivr.net/gh/klausyao/imageshosting/oracle/rac/rac/image13.gif)

### 8.2.2 Hub Node(中心节点)

#### 8.2.3 Leaf Node(叶子节点)

> 标准集群可转换为Flex Cluster,但Flex Cluster无法转为标准集群,除非你重新配置(约等于重装)

## 8.3 ASM监听

> 这里三个ASM实例共用一个服务名,有点类似SCAN的意思
> $ lsnrctl status ASMNET1LSNR_ASM

> 在节点一上通过服务名连接ASM实例

```bash
[grid@ohs1 ~]$ sqlplus sys/oracle@172.16.0.21:10010/+ASM as sysasm
SQL> select instance_name from v$instance;
INSTANCE_NAME
---------------- 
+ASM3
```

> ASM监听service状况
> $ lsnrctl service ASMNET1LSNR_ASM

## 8.4 维护

### 8.4.1 查看当前集群模式是否启用Flex ASM

```bash
crsctl get cluster mode status
crsctl get cluster mode config
amscmd showclustermode
```

#### 8.4.2 查看集群节点成员角色

```bash
crsctl get node role status -all 
crsctl get node role config -all 
```

## 8.5 Flex ASM高可用测试

```bash
srvctl status asm -detail
srvctl config asm -detail
srvctl status db -d orcl -detail

srvctl stop asm -node hostname01 -stopoption abort -force 
srvctl status asm
crsctl check  cluster 
srvctl start asm -node hostname01
```

## 8.6 修改ASM实例个数

> ASM至少得有两个实例,这样不至于单点故障.

```bash
srvctl status asm -detail
srvctl modify  asm -h
srvctl modify  asm -count 2
srvctl config asm -detail
crsctl stat res -t 
```

# 九、RAC数据库和单实例区别

**单实例组件与****RAC****组件的对比**

# 十、RAC特殊问题和注意点

## 10.1 共享存储

## 10.2 时间一致性

## 10.3 固件、驱动、升级包的一致性

> 诊断处理结果
> I/O 1 节点HBA卡的fimware升级到v4.06.03后连接200E找不到盘阵的故障已经得到解决.其实是一个FCHBA卡的固件版本不一致引起的问题.

## 10.4 共享文件OCR及Voting Disk

## 10.5 安装

> 如果使用 ASM 存储,需要为 asm 单独安装 ORACLE 软件,独立的 ORACLE_HOME,易于管理和维护,比如当遇到 asm 的 bug 需要安装补丁时,就不会影响 RDBMS 文件和软件.

## 10.6 脑裂和健忘

### 10.6.1 脑裂(SplitBrain)

### 10.6.2 健忘(Amnesia)

# 十一、RAC维护Q&A

## 11.1 判断是否RAC库

## 11.2 判断是否ASM实例

## 11.3 查看集群的名称

## 11.4 RAC环境下的Redo文件可以放在节点本地吗？

```sql
SQL> SELECT B.THREAD#,A.GROUP#,A.STATUS,A.MEMBER,B.BYTES,B.ARCHIVED,B.STATUS FROM V$LOGFILE A,V$LOG B WHERE A.GROUP#=B.GROUP#;
```

## 11.5 RAC环境下所有数据库实例可以使用同一个Undo表空间吗？

```sql
SQL>ALTER SYSTEM SET UNDO_TABLESPACE=UNDO1 SID='orcl1';
SQL>ALTER SYSTEM SET UNDO_TABLESPACE=UNDO2 SID='orcl2';
show parameter undo_tablespace
```

## 11.6 Alter system switch logfile和alter system archivelog current的区别

## 11.7 RAC中如何删除归日志

## 11.8 指定JOB的运行实例

## 11.9 将一个数据库加入crs

## 11.10 clusterware启动顺序

## 11.11 ora.cvu后台进程

## 11.12 RAC中当前实例kill另一个实例中的会话

```sql
SELECT a SID,
b.SERIAL#,
c.SPID ospid,
c.pid orapid 
FROM v$mystat a,
v$session b ,v$process c
WHERE a SID= b.SID 
and b.PADDR=c.ADDR 
AND rownum=1;

ALTER SYSTEM DISCONNECT SESSION '71,20925,@2' IMMEDIATE;
```

## 11.13 RAC节点被踢出的原因有哪些

> 可能的原因包括：服务器负载严重或内核HANG住、网络心跳丢失、磁盘心跳丢失、CSSD进程HANG住.

## 11.14 集群中的Master Node体现在哪两个方面

> 在RAC中有两种Masters,一种是Clusterware层面的,另一种是Block层面的Masters.

## 11.15 RAC等待事件

> gc buffer busy是RAC数据库中常见的等待事件从 oracle11g开始 gc buffer busy分为 gc buffer
> busy acquire和 gc buffer busy release.

> gc buffer busy release是在会话1之前已经有***远程实例***的会话2请求访问了相同的数据块,并且没有完成,那么会话1等待 gc buffer busy release.

## 11.16 套接字文件

```bash
[root@node1 tmp]# cd /var/tmp/.oracle
```

## 11.17 oraInventory目录的作用

### 11.17.1 中央目录

> CLE BASE上层路径的inVentory路径下,例如

```bash
# ls more/etc/oraInst loc
inventory loc=/u01/app/oraInventory
inst_group=oinstall
```

### 11.17.2 本地目录

> Local Inventory用于保存某一个 ORACLE_HOME下所安装的组件清单,它位于ORACLE_HOME/inventory下,由于Local Inventory针对特定的软件主目录所以并不存在inventory.xm文件.

## 11.18 root.sh脚本的作用

> crsctl query css votedisk

> 以上也是清除CRS配置信息的步骤

> 在root.sh脚本执行完毕后,需要再次将数据库、监听和SERVICE等其它资源添加进集群中:

【概念文档】RAC 介绍

发表评论取消回复

【DG部署】【RAC+ DG(Single DB & ASM)】

【OPatch】Apply Oracle RAC 19c Patch

【Docker】面试题

【RMAN】一周备份计划

【DG部署】【Single DB+Single DG】

【Doc】【OEM分类】

【概念文档】RAC 介绍

【部署】【卸载Oracle软件】

【RMAN】一周备份计划

【DG部署】【Single DB+Single DG】

【概念文档】RAC 介绍

发表评论 取消回复

【概念文档】RAC 介绍

发表评论取消回复