AWR报告中GC等待事件异常升高是Cache Fusion性能问题的关键信号，需重点分析Top 5 Timed Foreground Events和Global Cache and Enqueue Statistics，结合ASH、p1/p2反查物理块、网络与参数配置及应用逻辑综合定位根因。
看AWR报告里GC等待事件是否异常升高
Cache Fusion的性能问题几乎都会在AWR中留下明确等待信号，不查这里就等于闭眼调优。重点盯住「Top 5 Timed Foreground Events」和「Global Cache and Enqueue Statistics」两节。
常见错误是只扫一眼db cpu或log file sync，结果漏掉真正拖慢响应的GC类等待。实际中这几个值一高，基本就能锁定是缓存融合环节出问题：
-
gc current block busy高：说明某节点正以独占模式（current mode）持有并修改块，其他节点在排队等它释放——典型热点行/块争用，比如单点序列、单调主键插入 -
gc cr block busy高：CR（Consistent Read）块构建慢，常因高并发读+未启用_gc_read_mostly_locking，导致反复跨节点拉取和重建CR版本 -
gc buffer busy acquire上升：注意这不是纯GC问题，更多反映本地LRU链竞争加剧，但会放大GC延迟；此时要结合v$segment_statistics查热点对象
AWR默认1小时采样一次，若问题只持续几十秒，必须切到ASH查实时分布：SELECT * FROM dba_hist_active_sess_history WHERE event LIKE 'gc%' AND sample_time > SYSDATE - 1/1440（查过去1分钟）。
用p1/p2反查争用的具体数据块和对象
知道有GC等待只是开始，得定位到物理块才能下手。不同等待事件中p1和p2含义完全不同，硬套会查错地方。
例如：gc current block busy的p1是file#、p2是block#；但gc buffer busy acquire的p1是class#，不能直接拿来查段。务必先确认事件类型：
- 查
v$event_name确认当前等待的p1text和p2text - 拿到正确的
file_id和block_id后，用dba_extents反查对象：SELECT owner, segment_name, partition_name, segment_type FROM dba_extents WHERE file_id = &file_id AND &block_id BETWEEN block_id AND block_id + blocks - 1 - 若查出来是
UNDO段，说明是回滚段争用，得看undo_retention设置和UNDO表空间是否自动扩展
分区表容易漏掉partition_name字段，建议始终带上；另外，如果block_id落在系统表空间（如SYSTEM或SYSAUX），大概率是字典缓存争用，需检查SQL硬解析频率。
检查互联网络与参数配置是否匹配负载特征
Cache Fusion依赖interconnect网络传输buffer，千兆网卡在中高并发下极易成为瓶颈，表现为gc cr/current grant 2-way延迟飙升、gc send time变长，而磁盘IO反而不高。
- 用
oifcfg getif确认interconnect使用的网卡是否专用、是否绑定为私网（非业务网卡混用） - 检查
netstat -s | grep "retrans"是否有重传，ethtool看是否协商成全双工+正确速率 - 关键参数不是越多越好，优先验证：
_gc_read_mostly_locking=TRUE（12cR2+默认开，但升级后可能被覆盖）、gc_files_to_locks是否需显式调大（如小文件多，设"100:10000"避免锁资源耗尽） -
db_cache_size不宜设得过大，否则本地LRU链过长，gc buffer busy acquire会同步上升
很多团队调完参数没验证效果，其实最简单方式就是跑个SELECT * FROM gv$sysmetric WHERE metric_name LIKE '%GC%'，对比调整前后GC CR Block Received Per Second和GC Current Blocks Sent Per Second的吞吐变化。
识别应用层引发的GC放大行为
再好的RAC架构也扛不住错误的应用逻辑。有些写法看似合理，实则在RAC上会指数级放大GC流量。
- 使用单点序列（
SEQUENCE无CACHE）：每次取值都要跨节点协调，gc current block busy直线上升；应设CACHE 1000或改用IDENTITY列 - 单调递增主键+高并发INSERT：所有新行都集中在索引最右端，导致同一index block被反复争用；考虑反转索引、哈希分区或应用层打散
- 未启用TNS连接负载均衡：
LOAD_BALANCE=on没配，所有连接扎堆一个节点，GC压力自然不均 - 并行查询QC（Query Coordinator）长期绑定单一节点：看
gv$session中px_qc_inst_id是否总为1，若是，需检查并行度策略或SQL写法
最容易被忽略的是“读为主”场景未启用_gc_read_mostly_locking。哪怕表99%只读，只要没显式开启，RAC仍按常规锁模式处理，CR构建成本翻倍。这个开关一旦打开，对报表类大表的GC流量压制效果立竿见影。
