awr报告在rac环境下必须按实例生成，不能依赖全局汇总；awrrpt.sql默认仅输出单节点数据，需用awrrpti.sql指定实例号生成per-instance报告，并结合gc类等待、私网指标等交叉验证节点协同瓶颈。
AWR报告必须按实例生成，不能只看全局汇总
在RAC环境下，awrrpt.sql默认输出的是集群级聚合数据，会把所有节点的DB Time、等待事件简单相加，掩盖节点间负载不均问题。比如节点1 AAS=12、节点2 AAS=0.5，全局AAS显示6.75，看起来“尚可”，实际是单点过载+另一节点空闲。
正确做法是用awrrpti.sql（注意末尾带）生成per-instance报告：在SQL*Plus中执行@?/rdbms/admin/awrrpti，交互时明确选择目标Instance Number。RAC下每个实例ID对应一个节点，漏选或选错就等于没查。
- 确认实例ID：运行
SELECT instance_number, instance_name FROM gv$instance - 生成命令后必须指定
DB ID和Instance Number两个参数，缺一不可 - 若用OEM或ADDM，也要切换到“Per-Instance”视图，否则Top SQL列表里混着多个节点的SQL，执行计划无法对齐
重点关注gc buffer busy acquire而非占比数字
gc buffer busy acquire排在Top 5第9位？别跳过。它不像db file sequential read那样靠占比判断，而是看Avg Wait和触发会话数——平均等待超过10ms、且仅由5~10个活跃会话贡献，基本锁定RAC热点块争用。
这类问题在单实例AWR里根本不会出现，是RAC特有瓶颈。它背后不是IO慢，而是节点间缓存同步延迟：一个节点修改某块，其他节点要读同一块时，得等GCS协调完成。
- 下一步查
Segments by Global Cache Buffer Busy页，定位具体表/索引段 - 结合
GV$BH确认该块是否被频繁跨节点访问（INST_ID列值来回切换） - 避免直接调优SQL——先看是否能通过分区、反向索引或应用层数据分片，把热点数据隔离到单一节点
log file sync高但Avg Wait很低？检查应用事务粒度
log file sync等待总时间占比15%，但Avg Wait只有321 µs、每小时发生280万次——这不是磁盘写入慢，而是应用每条DML后都COMMIT，事务太碎。
RAC下更危险：每次提交都要触发LGWR写日志，再通过私网广播给其他节点确认，高频小事务会把GCS和网络打满。
- 查
SQL ordered by User I/O Wait Time，找INSERT/UPDATE后紧跟COMMIT的SQL - 对比
Executions和Transactions：若前者远大于后者，说明大量单行事务 - 优化方向是批处理（
BULK COLLECT+FORALL）或应用层合并提交，不是调日志文件位置
DB Time差异大但CPU使用率接近？查私网延迟
节点1 DB Time是节点2的3倍，但两节点OS层top显示CPU使用率都是45%——这说明节点1大量时间耗在跨节点通信上，而非本地计算。
RAC性能拐点常卡在私网（Interconnect），不是数据库配置问题。AWR本身不暴露私网指标，需交叉验证：
- 运行
SELECT inst_id, name, value FROM gv$sysstat WHERE name LIKE '%gc%'，重点看gc cr block lost和gc current block lost是否非零 - 查
GV$CLUSTER_INTERCONNECT确认私网状态，ping -s 65507测试MTU和丢包 - 若
gc cr block receive time平均>10ms，优先排查交换机QoS策略或网卡中断绑定
gc类等待的细节、忽略私网指标交叉验证，这三件事做错任何一件，就等于在多节点系统里用单实例思维治病。
