升级本身不导致gc cr grant等待升高，而是sql执行计划变更、统计信息失效或drm策略调整暴露了原有设计缺陷；如自动统计收集不足引发全表扫描、_gc_affinity_time默认值降低致块频繁迁移、sql plan baseline失效引发硬解析波动、drm误判存储性能而主动迁块等。
不是升级本身导致gc cr grant等待升高，而是升级后SQL执行计划变更、对象统计信息失效或DRM策略调整，放大了原有设计缺陷。
为什么升级后突然出现大量gc cr grant 2-way？
Oracle 11g RAC 升级（如从10.2.0.5到11.2.0.4）会重置部分隐式参数、刷新共享池、触发自动统计信息收集，并可能启用新的DRM行为。这些变化会让原本“凑合能跑”的SQL和对象设计暴露问题：
-
dbms_stats自动收集在升级后首次运行，若采样率不足或未cascade => TRUE，索引统计缺失 → 全表扫描替代索引访问 → 触发大量冷块磁盘读授权 - 升级后
_gc_affinity_time默认值可能从 300 秒降为 60 秒（取决于补丁集），导致热点块更频繁地被迁移出本地实例 → 主节点不匹配 → 原本本地能读的块变成远程授权 - SQL Plan Baseline 或 SQL Profile 在升级后失效，
cursor_sharing = EXACT下未绑定变量的语句重新硬解析 → 执行计划波动 → 偶发全表扫描 → 大量gc cr grant 2-way+db file scattered read - DRM 在 11g 中默认更激进（尤其启用了
_gc_policy_time），但若底层存储响应慢（ASM磁盘组平均IO时间 > 15ms），DRM会误判“本地访问效率低”，主动把块迁走 → 反而增加跨节点授权
怎么快速确认是升级引发的还是旧病复发？
查 AWR 快照对比：升级前 1 小时 vs 升级后首小时，重点关注三组指标是否同步跳变：
- 等待事件中
gc cr grant 2-way的time_waited_micro是否增长 ≥300%，且db file scattered read等待时间同比上升 -
dba_hist_sqlstat中disk_reads/executions突增的 SQL（尤其是buffer_gets/executions 但 <code>disk_reads/executions > 10000的） -
gv$segment_statistics中CR_BLOCKS_RECEIVED和CURRENT_BLOCKS_RECEIVED都飙升的对象 —— 若两者比值接近 1:1，说明是读写混合热点；若 CR 远高于 CURRENT，大概率是查询类SQL驱动的冷数据访问
哪些参数/配置在升级后最容易踩坑？
11g RAC 升级后几个关键参数的默认行为变化常被忽略：
-
_gc_affinity_time：11.2.0.3+ 默认 60 秒（旧版常设 300），过短会导致块刚热起来就被DRM迁走。验证方法：SELECT name, value FROM gv$parameter WHERE name = '_gc_affinity_time';，生产建议设为 120–300 -
_gc_policy_minimum：控制是否启用亲和性缓存，默认值在补丁集中有差异。若为0，则即使本地访问占比 99% 也允许迁移；设为50更稳妥 -
GCS_SERVER_PROCESSES：11g 默认仍为 2，但若升级后并发DML翻倍，LMS进程数不足会直接表现为gc cr grant busy与gc cr grant 2-way同时高企 -
optimizer_features_enable：升级后默认用新版本优化器，但老SQL可能依赖旧路径。临时回退（如设为'10.2.0.5'）可验证是否为执行计划问题
真正难处理的不是等待本身，而是它背后混杂的三层问题：SQL层的硬解析失控、对象层的分区/索引缺失、系统层的DRM与LMS资源错配。升级只是扳机，不是病因。
