RAC中存在较多的Cache fusion，有什么好的建议？

比较实际的：
1. 建议考虑关闭drm
2. 按照不同业务分在不同节点执行
3. 在应用架构设计的时候，就考虑rac，核心表设计不同分区在不同节点之上，减少交互
4. 使用更好的带宽，比如使用ib做心跳等收起

RAC优化原则
RAC优化原则

原则：既要充分利用节点资源与计算能力，又要避免Interconnect、Global Lock、Cache Fusion等导致的性能下降
            
            “既发挥优势，又避免短处”收起

有没有放之四海而皆准的方案呢？
答案：没有

原因：业务逻辑不一样
              数据结构不一样
              SQL语句不一样
            
怎么办：“根据实际情况进行平衡处理”

方法：测试->Tuning->测试->Tuning……收起

业务分割
答：把不同的业务分配到不同的实例上运行

优点：避免数据在实例内存之间传递导致性能下降，尽量减少内联网数据传输

场景：一个实例的数据块另一个实例不会去访问。跑的业务不一样处理的数据就不一样，处理的数据不一样就不会相互访问了。

缺点：无法使用全部的RAC节点资源，因不同业务跑在不同节点上收起

时间去哪里了
Cache Fusion 内存共享的时间
Cache Fusion：多个物理内存融合成一个逻辑大内存，任何实例上都可访问到所有数据。

数据传输
多个实例间需要数据的传递、交叉、镜像复制

块锁定
块资源的锁，不是事务级的锁 TX TM，块传递到目标节点后才可查询

等待事件
比单实例有更多的等待事件，多余的性能消耗收起

RAC的优势
（1）实例级冗余：无缝切换技术，会话级切换&查询级切换

（2）硬件资源优势：多个节点拥有更多的CPU、内存、Cache资源

（3）负载均衡：任务分配到多个实例上并行执行

RAC的劣势（额外性能消耗）
（1）内存共享Cache Fusion：数据块在实例间传递，不仅仅垂直传递还有水平传递
（2）全局锁定Global Locking：一个人在A实例上修改块，另一个人就不能在B实例上同时修改这个块，锁定解除之后才可继续，资源的锁定
（3）内联网Interconnect：数据吞吐量，网络带宽，网络延迟等网络时间消耗收起

还有，优化sql收起