在进行RAC优化之前，你应该...
应用层面的优化（主要是业务的sql语句）
单实例的优化
操作系统的优化
首先是SQL语句的性能，之后是RAC下面每一个单实例的优化，最后是操作系统优化。
上面几个都没有问题就有可能是RAC机制本身导致的性能问题。
RAC的性能--第一个问题
RAC究竟能否提高性能？
看你怎么使用它！
RAC的性能--第二个问题
RAC的节点数和性能是什么关系？
看你怎么使用它！
结论
看你怎么使用它！ （RAC并不是绝对可以提高性能的）
测试才是王道
第一张图，同样是54个任务，单实例和RAC处理所花费的时间比。
第二张图，一个是单实例，一个是RAC，在开始的时候RAC的性能的确比单节点的好些，但是到了某个点RAC性能比较平稳，不再提高，而单节点不断提高性能。
不同的使用场景，相同的RAC，比如研讨个节点RAC在一种场景下表现的很优秀，但是在另外一种业务模式下性能就表现的非常差。
一个RAC是有四个节点，四个节点上面都有业务连接着，那么数据块就会分到四个实例上面去了，四个实例之间的数据块是要相互传递的，因为oracle要保证数据块的一致性，节点越多，数据块被复制到其他节点的机率就越大，最后数据块就要不断的从一个节点复制到另外一个节点。这样RAC就做了额外的大量的工作，这个时候性能看起来还不及单实例。
在另外一种情况Oracle做并行处理，比如一个全表扫描，分为了八个并行度，就是八个进程同时处理这个表，将表分为八块，每一个进程处理一块。假设将这八个进程分配到四个节点上面，每个节点起两个进程，这样是不是比一个节点起八个进程好？有的情况下的确1是好，但不是绝对的。
RAC架构中性能的影响因素
单台数据库物理性能影响因素
– I/O效率
– CPU效率
– 内存效率
– 网络效率
RAC架构物理性能影响因素
– I/O效率
– CPU效率
– 内存效率
• cache fusion效率
– 锁定，数据在内存中的传递，消息的传递。
– 网络效率
• 内连网络效率(interconnection)
– 节点间的负载平衡
内存共享的问题--cache fusion
u 多个物理独立的内存，意味着：
– 内存共享
– 锁定
– 数据传输
在RAC架构里面，最可能影响性能的的因素就是内存共享，即数据块在节点之间的复制。
内连网络--interconnect
稳定的网络传输。
尽可能快的网络传输通道，减少数据在内存间拷贝的时间。
如果内联网传输慢的话，比如说有丢包，这样也会出现效率很低的情况。
内存数据一致性的效率因素：
寻找内存中的数据块
确定RAC的master节点
从interconnect获取数据块
interconnect网络传输速率
interconnect网络延迟
从其它实例接受数据块
创建数据块一致性镜像（image)
内存数据一致性带来的额外代价
数据块访问代价
– 需要访问更多地数据块 -> 消耗更多的时间
锁管理的代价
– 更多的内存锁定 -> 消耗更多的时间内连网络代价
– 网络延迟
– 网速
– 更多地数据需要传递 -> 消耗更多的时间
优化RAC的 cache fusion
– RAC优化的主要关注点：
• GCS ‘Global Cache Service
– Global Cache Services (GCS) Waits
• 说明有多少数据消息在实例内存间传递
Cache Fusion的主要两个进程就是GCS和GES，其中GCS负责实例之间数据块的复制传输，OES复制管理锁，在等待事件当中，具体的表现为GCS产生的等待。
在RAC方面的等待，几乎都是GC开头的，都是因为一个数据块从一个实例传到另外一个实例产生的一些等待事件。如果等待太大了，那么就说明节点和节点之间宇大量数据的传递，如果这种大量数据的传递已经严重影响了业务，那么就要业务分割了。就是让一种业务固定的去连接一个实例，另外一个业务固定去连接另外一个实例。因为几个实例之间使用的是不同的业务，访问的数据块都不一样，就减小了数据块在节点之间的传递，但是这样就不能使用多节点的并行机制处理来提高速度。