AWR中RAC相关的部分
对于RAC来说，有几个节点就应该在几个节点上面生成AWR报告。这里面也有RAC的等待事件。
通过上面的报告看上面的值是没有意义的，因为要有对比才能发现问题。对比等待值是正常情况下生成的AWR报告，所以对于性能分析都是相对来说的问题，有比较才有性能。
对于AWR报告来说要与一个基线，需要按照业务正常绘制基线，相对应的指标都需要有一个基线，在出问题的时候对比这个基线指标的值和现在的值就能发现是正常还是异常。
所以单纯的观察AWR上面的值是没有意义的。
RAC的优化设计
一对矛盾体
– 充分利用所有RAC节点的资源
– 尽量减少Interconnect的数据传输
既要充分利用节点的资源和计算能力，又要避免
Interconnect导致的性能下降
按照实际情况进行平衡处理
结论
测试，
测试，
还是测试！
充分利用所有RAC节点的资源和尽量减少Interconnect的数据传输本身就是一对矛盾体。
充分利用所有RAC节点的资源：就是要将任务尽量的分配到多个节点上。分布到多个节点就意味着多个节点的数据就要互相传递，这就需要复制，会导致内连网性能的下降。
到底是资源分配并行执行重要还是尽量减少Interconnect的数据传输重要，这个需要测试。
RAC的优化设计--业务分割
优点
– 避免数据在实例内存间传递导致的性能下降。
劣势
– 数据无法使用全部的节点资源
这个就是为了解决上面的数据块在实例之间的传递导致性能下降问题。
RAC的优化设计--业务分割
根据业务增加各自的服务
客户端连接到各自的服务上
数据查询业务和数据加载业务通常是没有交集的，即数据加载的数据块和数据查询的数据块是几乎不相同的。让这些业务的数据块不全部分布在四个节点，这样会导致cache fusion出现性能问题。这样就可以使用实例1和实例2做数据加载的业务。实例3和实例4用来做查询的业务。
这样的好处在于数据加载的业务的数据块只存在于实例1和实例2，只在这两个节点传递，也即是2 way，就不会在实例3和实例4上面传递，这样就不会出现3 way和4 way的情况发生。
上面就是业务分割，将不同类型等待业务分布在不同的实例上面，具体操作就是通过增加服务的方式来完成。-r选项表示服务在哪两个实例上面运行。
业务分割的优点是避免了大量的数据分布在不同等级节点上面，坏处是没有充分的利用所有的资源。比如上面的查询只在其中两个节点上面，没有将查询分布在所有节点。
RAC的优化设计--并行查询
默认情况下，Oracle会将并行子进程尽可能的放到各个实例上执行,可
能有正面和负面的影响：
– 正面 多个实例处理数据，充分利用系统资源。
– 负面 大量的数据需要在实例的内存间传递，影响性能。
在进行并行查询的时候，所有的slave进程要向QC（协调器）不断的发消息，如果并行启动在多个实例上面，那么也会通过interconnect网络向QC上面发消息。
RAC的优化设计--并行查询
结论：
– 如果充分利用资源更能提高并行效果，就把并行分布到各个实例上执行。
– 如果Interconnect导致严重的性能下降，就考虑把并行开在一个实例上。
RAC的优化设计--并行查询
并行进程的限制
– parallel_instance_group
– instance-group
RAC的优化设计--对象的设计
Hot Table
– 数据块存放少量的行
• 减少数据块在多个实例间的争用。
– partition?
• 让数据落在多个段上，减少段访问的争用（段头热块）。
一个分区就是一个段，要向段里面写数据肯定是需要申请空间，对于一个段来说对于空间的管理是放在段头里面，如果不是分区表那么只有一个段，那么只有一个段头了，要插入的数据都要访问这个段头，那么就会在段头发生争用。不同分区是有不同的段头，不同的会话访问不同的分区就会访问不同的段头。这样有利于减少段头的争用。
比如有1000个会话都去访问一张表，如果这个表没有分区，那么都会去访问这个表的段头。
RAC性能的定位--对象的设计
顺序键值索引
反向索引（无法进行range scan操作）
避免从多个实例访问索引（业务分割）
索引是顺序排的，在数据块里面也是从小到大排列的，这样就可能出现多个键值全部分布在一个数据块里面，而用户查询的数据的键值也全部分布在这个数据块里面。这样数据块就变成了一个热快了。
为了将按照顺序排放的键值全部打撒在不同的数据块里面，这个机制叫做方向索引。这样会话请求的数据块就不是同一个数据块了，避免了数据块的争用。
反向索引不能使用范围扫描了，范围扫描比如id<10，正常索引是按照顺序排序的，在索引上一旦定位到这个10，顺着这个10往前面扫描。一旦反向之后，整个索引键值就乱套了不是按照顺序排的，这样就不能使用范围扫描了。
RAC性能的定位--对象的设计
Hot Sequences
– 将多一些的sequences cache到内存当中。
RAC的优化设计--对象的设计
readonly？
– 将read only的表放到readonly表空间上，减少数据块的一致性维护锁定，避免表空间上的checkpoint操作。
RAC的优化设计--总结
如果可能，业务分割。
如果可能，限制并行在一个实例上运行（测试）
Interconnect速度尽可能的快
Sequence 尽可能cache多一些
表空间的READ ONLY
对于小表，尽可能减少每个数据块中的数据。
避免大表的全表扫描。