awr中真正的gc buffer busy acquire需在「global cache and enqueue statistics」节手动查找明确标注项，或查dba_hist_system_event中event = 'gc buffer busy acquire'，不可依赖「top 5 events」中笼统的'gc buffer busy'；须结合多节点对比、平均等待时间（非仅总次数）及ash下钻object_name与current_obj#定位热点块。
怎么看AWR里真正的gc buffer busy acquire
AWR报告里的“gc buffer busy”是10g时代的笼统汇总，11g起已拆成gc buffer busy acquire和gc buffer busy release两类。直接在AWR的「Top 5 Timed Foreground Events」里搜gc buffer busy，看到的可能是混合统计，掩盖真实问题。必须手动过滤：打开「Global Cache and Enqueue Statistics」节，找明确标为gc buffer busy acquire的行；或者导出dba_hist_system_event视图查event = 'gc buffer busy acquire'。
常见错误是只看总等待次数，忽略平均延迟。比如某节点gc buffer busy acquire总等待10万次，但Avg Wait(ms)只有0.2，说明争用轻微；若同样10万次但Avg Wait达15ms，就是严重热点——后者更值得优先处理。
为什么不能只看一个节点的AWR
RAC是多实例协同系统，gc buffer busy acquire本质是本地会话在等远程实例释放块，单看一个节点的AWR，就像只听吵架一方的陈述。必须并排对比所有节点的AWR：比如节点1大量gc buffer busy acquire，节点2对应时段出现高gc current block busy或gc cr block flush time，基本能锁定争用源头在节点2的某块上。
实操建议：
- 用
gv$system_event确认各节点gc buffer busy acquire的time_waited_micro分布，不是只比total_waits - 查节点2的「RAC Statistics」节，重点盯
Avg global cache cr block flush time (ms)，超过5ms就要怀疑LGWR被阻塞或redo写慢 - 若节点2同时有高
log file switch completion等待，大概率是日志切换卡住LGWR，导致current块无法及时刷出，拖慢CR构造
如何从AWR定位到具体数据块
AWR本身不记录file#和block#，但提供了足够线索反推。先在「Global Cache and Enqueue Statistics」里找到gc buffer busy acquire的Top Segments（Segments by Global Cache Buffer Busy），它列出的是被跨实例频繁请求的对象名。但这只是起点——因为同一张表可能有多个热点块，需进一步下钻。
正确路径是结合ASH（哪怕AWR没开，也应启用）：
- 执行
SELECT sql_id, object_name, current_obj#, COUNT(*) FROM dba_hist_active_sess_history WHERE event = 'gc buffer busy acquire' GROUP BY sql_id, object_name, current_obj# ORDER BY COUNT(*) DESC - 拿到高频
object_name后，再查v$segment_statistics确认该对象的gc_buffer_busy累计值是否持续增长 - 若确认是小表或索引（如
SEQ_LOG_ID_IDX），别急着调参数，先检查它的键值分布：单调递增主键+B树索引必然导致右边界块争用
哪些参数在AWR里容易误导判断
AWR里有些统计项看着相关，实则干扰分析。比如gc cr block receive time高，很多人第一反应是网络问题，但实际可能源于远端实例的gc cr block flush time飙升——而后者又常由LGWR阻塞引发。此时改私网MTU或加LMS进程毫无意义。
另一个典型是GCS_SERVER_PROCESSES。AWR的「Instance Activity Stats」里能看到该参数当前值，但数值本身不说明问题。关键要看gv$latch中gcs resources和gcs shadows的gethitratio是否低于95%，以及gv$ges_enqueue的cum_queue_time是否超500ms。前者低说明GCS资源不足，后者高说明GES层已压垮，这时调参数才有效。
真正该盯的AWR硬指标只有三个：gc buffer busy acquire的平均延迟、gc cr block flush time、log file switch completion的等待次数与延迟。其余都算旁证。
