\_awrgrpt.sql 在 RAC 上默认不显示 Cache Fusion 等待事件，因其仅查询当前实例 AWR 数据，而 Cache Fusion 是跨实例的全局行为；需使用 awrgrpt.sql（非 \_awrgrpt.sql）并设 inst_num=0 才生成含 Global Cache Statistics 的全局报告。
为什么 _awrgrpt.sql 在 RAC 上默认不显示 Cache Fusion 等待事件？
因为该脚本默认只查当前实例的 awr 数据，而 cache fusion 相关等待（如 gc cr block 2-way、gc buffer busy acquire）本质是跨实例的全局行为，单实例视图会严重低估或完全漏掉。rac 的全局 awr 报告必须显式启用集群模式，否则你看到的只是“拼起来的单机报告”。
实操建议：
- 运行前确认已用
sqlplus / as sysdba连入任一节点，且当前用户有SELECT_CATALOG_ROLE和SELECT ANY DICTIONARY - 执行
@?/rdbms/admin/awrgrpt.sql（注意不是_awrgrpt.sql）——这是官方支持的全局报告入口，会自动识别 RAC 并提示选择DB ID、Instance Number（填0表示全部实例） - 若坚持用
_awrgrpt.sql（比如老版本或定制需求），必须在脚本开头手动设置：DEFINE dbid = &1; DEFINE inst_num = 0;，否则它默认把inst_num设为当前实例号 - 检查生成的报告末尾是否出现
Global Cache Statistics和Global Enqueue Statistics小节，没有就说明没走集群模式
Cache Fusion 等待事件在全局报告里为什么数值异常高或为 0？
不是数据错了，而是统计口径和采样粒度导致的常见错觉：AWR 报告里的 gc * 等待时间，是所有实例上该事件的“本地累计值”，但一个跨实例请求可能在源实例记一次 gc cr request，在目标实例记一次 gc cr grant 2-way，两者相加远超实际耗时。
实操建议：
- 优先看
Global Cache Efficiency中的Buffer Access和Global Cache Blocks Received比率，比单个等待事件的毫秒数更有诊断价值 - 对比
gc cr blocks received和gc current blocks received：前者反映一致性读争用，后者反映当前块传输压力；若前者远高于后者，说明应用存在大量非绑定变量或重复查询老数据 - 避免直接比较不同 RAC 集群的绝对等待时间，因节点数、网络延迟、buffer cache 大小差异极大；应聚焦同一集群升级/配置变更前后的相对变化
- 用
GV$SESSION_WAIT或GV$ACTIVE_SESSION_HISTORY实时抓取正在发生的gc *等待，比 AWR 快照更准——尤其当问题偶发时
如何用 AWR 报告快速定位 Cache Fusion 热点对象？
不能只盯着“Top SQL”，Cache Fusion 压力往往来自低频但高并发的 DML 或索引块争用，SQL 级别看不到，得下钻到段级。
实操建议：
- 在全局 AWR 报告中翻到
Segments by Global Cache Buffer Busy（不是普通Buffer Busy Waits）小节，它列出跨实例争用最激烈的表或索引段 - 重点关注
OBJECT_NAME同时出现在gc buffer busy acquire和gc cr block busy两列的表——这通常意味着该对象的某个热块（如主键索引根块、序列缓存块）被多实例频繁访问 - 结合
dba_objects.object_id查出对应对象类型：SELECT object_type FROM dba_objects WHERE object_id = &object_id;，若为INDEX，优先检查是否缺少REVERSE KEY或用了单调递增的SEQUENCE - 若热点对象是小表的主键索引，考虑用
ALTER INDEX ... CACHE提升其在各实例 buffer cache 中的驻留率，减少跨实例获取
生成报告时遇到 ORA-00942 或 “no rows selected” 怎么办？
这不是脚本坏了，而是 AWR 基础元数据缺失或权限未生效，常见于刚搭建的 RAC 或跨版本升级后。
实操建议：
- 先验证 AWR 是否正常采集：
SELECT COUNT(*) FROM dba_hist_snapshot WHERE dbid = (SELECT dbid FROM v$database);，结果为 0 则 AWR 未启用，需检查STATISTICS_LEVEL是否为TYPICAL或ALL - ORA-00942 通常因
sys用户未授予SELECT ANY DICTIONARY给运行脚本的用户，或脚本在 PDB 中执行但未切换到 CDB$ROOT - “no rows selected” 可能因指定的时间范围无快照（
SELECT MIN(snap_id), MAX(snap_id) FROM dba_hist_snapshot;核对），或inst_num=0时某节点 AWR 数据损坏——尝试指定具体实例号（如inst_num=1）单独生成再合并 - 确认
awrgrpt.sql路径正确：$ORACLE_HOME/rdbms/admin/awrgrpt.sql，而非旧版$ORACLE_HOME/rdbms/admin/awrrpt.sql（后者不支持 RAC 全局模式）
真正难的不是生成报告，而是理解每行数字背后跨实例的数据流路径。Cache Fusion 不是黑盒，但它要求你同时盯着至少两个实例的内存、网络、磁盘三处状态——少看一眼，结论就偏了。
