调小\_gc\_policy\_time 反而延长GC停顿，因其控制RAC节点间资源再平衡触发间隔，过小（如10秒）导致频繁gcs/ges协商、锁迁移与缓存失效，抢占CPU和网络资源，拖慢业务SQL；默认300秒更稳。
为什么 _gc_policy_time 调小反而让 GC 停顿更长？
因为这个参数控制的是「rac节点间资源再平衡的触发间隔」，不是gc本身耗时。设得太小（比如 10 秒），会导致频繁发起 gcs 和 ges 消息协商、锁资源迁移、重映射数据块归属——这些操作本身要抢 cpu、占网络、触发局部缓存失效，反而拖慢真实业务 sql 的执行。
- 默认值是
300（5 分钟），对大多数 OLTP 系统足够稳 - 低于
60就容易看到gc cr grant 2-way或gc buffer busy acquire等等待陡增 - 调整后必须观察
V$SYSSTAT中global cache logons和global cache gets的突变幅度
_gc_policy_time 和 _gc_affinity_time 到底谁先起作用？
两者协同工作：_gc_affinity_time 决定「一个数据块在某节点上停留多久才允许被赶走」，_gc_policy_time 决定「多久检查一次要不要赶」。前者是门槛，后者是节拍器。
- 如果
_gc_affinity_time是1800（30 分钟），但_gc_policy_time是30，那每 30 秒检查一次，发现没满 30 分钟就跳过，实际不会迁移 - 真正触发迁移需要两个条件同时满足：时间到 + 负载差超过
_gc_policy_limit阈值（默认 50%） - Oracle 11.2.0.4+ 中，这两个参数都已被标记为
Deprecated，官方倾向用DBMS_RESOURCE_MANAGER+INSTANCE_CAGING替代
动态修改 _gc_policy_time 的风险点
它是个隐含参数，ALTER SYSTEM SET _gc_policy_time = 120 SCOPE=BOTH 看似生效，但 RAC 实例间同步有延迟，且不保证所有节点立刻按新值行动。
- 修改后必须查
V$PARAMETER确认每个实例的ISDEFAULT为FALSE，否则可能只是 session 级临时覆盖 - 不能在 DML 密集时段改，尤其避免和
ALTER SYSTEM CHECKPOINT或日志切换同时发生 - 如果用了 ASM，还要注意
_gc_policy_time和 ASM 的ASM_POWER_LIMIT存在隐式耦合——调太激进会放大磁盘 IO 波动
比调参更有效的高并发 GC 优化路径
真正在意吞吐量和响应时间，优先做三件事：应用层绑定、对象级亲和、SQL 访问模式收敛。参数只是兜底手段。
- 用
DBMS_WORKLOAD_REPOSITORY抓出 top 5gc current block 2-way对象，加ALTER TABLE ... STORAGE (BUFFER_POOL KEEP) - 把频繁跨节点访问的表按业务维度分区，并确保查询带分区键，减少跨实例块请求
- 确认应用连接串里没开
SERVER=DEDICATED却又没配CLUSTER_DATABASE=TRUE，这种错配会让 GC 协议退化成低效模式
隐含参数调得再细，也盖不住 SQL 反复扫描全表+跨节点 join 的本质问题。盯住 V$GES_STATISTICS 里的 value 列变化趋势，比死磕单个数字更有意义。
