Oracle Real Application Clusters (RAC) 是一个共享缓存的集群数据库架构，它突破了传统的无共享和共享磁盘架构的限制，从而能够提供无与伦比的数据库高可用、可伸缩性和可靠性，而且无需对现有的 Oracle 数据库应用程序进行修改。
我们在享受RAC业务连续性、高可用性、可伸缩性优势的同时，往往会因为其架构复杂造成应用性能瓶颈，本篇将着重介绍数据是如何在RAC架构中实现同步转移，各个进程如何协作实现一致性等，了解其中原理，最后我们将通过何种方式去跟踪分析性能瓶颈根结，找到治本的解决方法。
▏概念一览 ▏
▲缓存一致性
● 在一个实例中有多个缓冲区高速缓存（buffer cache），并且ORACLE RAC是采用共享一切的体系结构的。
● 缓存一致性是为保持数据库的一致性。
● 只有一个实例能在当前独占模式（exclusive current mode）下持有一个块。并且这个块只有在这个状态下才能被修改。
● 可以有两个待处理的事务同时修改相同的块，但这个块只能在一个实例中以独占模式被持有。
▲单块读
如果缓冲块不是在本地缓冲区高速缓存中，进程将在这个块头上找到其所属的主节点。然后这个进程会通过心跳网络发送一个请求给此块的主节点上的lms进程。
当发送这个请求时，其并不知道这个块现在存在于哪个实例上。直到LMS响应前，用户进程会等待一个”占位符”的等待事件，诸如gc cr read, gc current read等。
在从LMS进程接收到响应后，之后的时间会被累计到相应的其他等待事件中。如果此块不在任何实例的高速缓存区中，则LMS进程将在这个资源上赋予PR（保护读）模式的锁，并让FG（前台进程）从磁盘上去读取。
FG – Foreground Process （前台进程）
LMD – Lock Manager Daemon （锁管理守护进程）
GRD – Global Resource Directory （全局资源目录）
PR – Protected Read （保护读）
【举个例子】
◐ 以下的跟踪文件显示这个会话等待的是一个2-way grant等待事件，其次是一个磁盘读。
◐ 在从磁盘读取块前，实例先得到了保护读（PR）模式的锁。
▲单块传输
● 如果在远程实例的缓存处于一个兼容模式，则LMS进程会赋予其一个锁。
● 远端的LMS进程传输块给前台进程。
● 前台进程将这个缓存复制到高速缓冲区。
● 拥有该块的实例将会在这个块上获得一个锁（CR块传输不更新GRD）。
● 你可以看到的GC事件，但GC事件之后不会有关于disk磁盘的事件。
▲GCS（Global Cache Service）结构
▲三段单块传输（Single block transfer -3 way）
块在实例3的高速缓存区中，实例2是这个资源的目录实例（directory instance）。LMS进程通过心跳网络从实例3传输块。
▲GRD
在传输之后,GRD更新块的所属，这两个实例都是此块的所有者。
如果块以PR（保护读）模式从一个实例转移到另一个实例，那么这个块的模式被认为是当前模式传输（current mode transfer）。随后，’gc current blocks received’ 统计增加。
▲修改缓存
在修改一个缓存块前，这个缓存块必须以独占模式（Exclusive mode （EX））获得BL锁。
如果这个缓存块已经存在于他的高速缓冲区内，其他实例将会从他们高速缓冲区降级或者刷出这个块。当某个实例以EX模式获得了这个缓存块，则其他实例将会从buffercache中刷出这个块。
▲繁忙度
gc cr block busy, gc current block busy事件表明这些块处于繁忙状态。在这个情况下，这个块是以EX模式存在于另一个实例中，LMS进程申请重做块（undo block）去实现块的一致性，这个块为cr模式的的缓存块。
过多的*busy事件表明应用关联度不好。关联的应用将可以减少这些*busy的等待事件，因为关联的应用会将这些块放在同一个实例中修改。
▲Gcs log flush sync
但如果在缓存块已经传输到其他节点后，发生了实例崩溃，那RAC怎么去维护其一致性呢？
其实，在发送一个当前模式（current mode）块前，LMS进程将会请求LGWR进程去执行一次日志刷出。直到LGWR进程发送一个返回信号给lms进程，这段期间，lms进程都会等待 “gcs log flush”事件。
果块被认为在“忙”，则CR块传输可能需要刷新日志。被认为繁忙的条件之一是这个块是通过申请undo（回滚）记录构造的。
如果两个实例同时修改一个块，但是是这个块的不同行，会发生什么情况？
行级别锁会阻止两个不同的实例去更新相同的行。在一个实例能修改一个块前，这个实例必须在缓存中获得EX模式的锁。没有两个实例可以持有EX模式和兼容的缓冲状态的块。
如果有两个未决的事务，并且来自不同的实例去修改同一个块会发生什么？没有两个实例允许同时持有EX模式GCS锁得xcur模式的缓存。
▏RAC等待事件 ▏
一、数据包的类型
▲块类的数据包：
● Consistent Read blocks
● Current Read blocks
▲消息类的数据包
● Single block grants
● Multi block grants
▲服务类的数据包
● SCN generation
● Row cache updates
● GES layer packets
▲Cr 等待事件
以下是与cr模式传输有关的最多的等待事件：
1.没有阻塞或并发的传输：
gc cr block 2-way
gc cr block 3-way
2.多块读：
gc cr multi block request
3.并发相关
gc cr block busy
gc buffer busy (acquire/release)
4.授权：
gc cr grant 2-way
5.阻塞相关：
gc cr grant congested
gc cr block congested
▲Gc cr block 2/3-way
● ‘gc cr block 2-way’ 统计的时间为，这个块的所有者和其属组在一个实例的活动。
● 如果所有者不在主实例（master 实例），则等待事件为3-way。
● 如果没有其他额外的工作，如创建CR块或争用，则时间统计这些等待事件。
【分析】
● ‘gc cr block 2-way’ 和 ‘gc cr block 3-way’ 事件可以被认为是校对cache fusion性能的基线事件。
● 一般来说，有并发或拥塞的问题是没有这些事件的。
▲建议
● 保持cpu使用率在80%-85%以下。超过80%的cpu使用率，就会产生调度效率低下并且多重的缓存融合（cache fusion）性能问题。
● 可能考虑巨型帧。巨型帧减少组装和拆装的数据包，所以会稍微降低CPU使用率。
● 用OS工具重新检查网络性能。
● 如果有cache fusion流量拥堵，检查私有专用互联。
● 检查cache fusion 拥堵是否和其他网络拥堵有关
▏案例2 ：这两个事件的过量等待 ▏
◐ 如果有巨量的这个等待事件的等待，找到对象和引起这些等待的SQL.▲建议
● 考虑应用程序的关联度，数量庞大的块在实例间来回传输，表明解决应用程序的关联性将会有很大帮助。
● 对于这个工作量，SGA的大小可能偏小，试着增加sga大小是一种选择。
● 集群将因为两个点之间网络的延时而遭受更长的延时。
▲Gc cr block congested（拥挤）/gc cr grants congested
这些等待事件表明，有CPU资源匮乏问题：
● 例如，突然产生的PQ进程会导致cpu 负载，并使得cpu紧张。
● 通过sql语句的调优减少cpu的使用率，计划性的job在不同的时间运行，或根据需要增加新节点。
● 在实际繁忙的环境中，会有许多等待事件，只有在awr或sqltrace显示对这些事件有大量的等待时间，我们才会去关注。
▲Gc cr grants 2-way
如果该块不在缓冲区高速缓存的。这个等待事件统计得到授权后，从磁盘拿到缓存区这段时间。
这段trace 显示这个等待时间在一个磁盘读前，
ORACLE RAC是目前市面上真正唯一做到并行模式的集群，RAC的所有集群成员都可以同时接收客户端请求，这样我们将能使用较低廉的服务器来实现高可用性、高吞吐量的集群环境，这要比通过对某台高端服务器增加硬件实现高可用性、高吞吐量花费的成本低很多。
▲RAC存在的问题虽然RAC有非常多的优点，但由于部署一套RAC会涉及服务器、存储设备、HBA卡、操作系统等多方面的技术，且从实现上要比单实例数据库更复杂，对硬件设备的稳定性、设备之间以及设备与操作系统的兼容性上要求也更高，Oracle的bug也会造成RAC运行出现问题。
所以，从实际的运行情况来看，RAC要比单实例的数据库存在更多的问题，问题的原因也各不相同。
性能是大部分从单机环境迁移到RAC环境比较头疼的问题。在目前普遍使用千兆网 络的硬件环境中，很多时候系统的数据库从原来的单机迁移至RAC环境，系统的性能反而下降。
在这种情况下，数据库管理员应该根据RAC的特点对系统调整提出合理的建议，经过合理的设计、开发，使用RAC是能够提高系统的处理性能的。
通过本篇略窥门径，希望大家能理解RAC架构内部工作原理，更好的找到根结原因，提升性能。——本文为笔者参照外文原著
《advanced rac troubleshooting》
并结合自身观点所写——
联系客服
