Oracle RAC中GCS/GES进程资源耗尽的问题如何解决？

作者：袖梨 2026-07-14

Oracle RAC中GCS/GES资源耗尽本质是永久性结构静态分配后无法回收的硬性内存瓶颈，需通过v$sgastat精准定位占用量，结合_v$resource_limit评估利用率，并依物理核数与db_cache_size合理设置_gcs_resources等隐含参数，重启生效；禁用shared_pool_duration（12c+）可降低碎片风险。

oracle rac中gcs/ges资源耗尽不是“调大shared_pool_size就能解决”的简单问题，而是共享池里永久性结构（gcs resources、ges enqueues等）被静态分配后无法回收，叠加业务增长或配置失配导致的硬性内存瓶颈。单靠flush shared_pool或重启实例无效。

查清GCS/GES实际占用量，别只看shared_pool_size

共享池里真正吃掉内存的是那些永久分配的GCS/GES结构，它们不参与LRU淘汰。直接查v$sgastat比看总shared_pool更准：

SELECT pool, name, bytes/1024/1024 MB FROM v$sgastat WHERE name IN ('gcs resources', 'gcs shadows', 'ges resource', 'ges enqueues') ORDER BY MB DESC;
如果单个项超200MB，且v$resource_limit里max_utilization接近initial_allocation，说明结构已撑满
v$resource_limit里的current_utilization持续>90%就是危险信号，尤其gcs_resources和ges_enqueues

调整_gcs_resources和_gcs_shadow_locks前必须核对物理核数

这两个隐含参数控制GCS资源初始分配数量，设高了浪费内存，设低了触发ORA-04031；但不能拍脑袋定值：

_gcs_resources建议值 ≈ db_cache_size（GB）× 1000，上限不超过物理CPU核数×200（例如32核服务器不要超过6400）
_gcs_shadow_locks通常设为_gcs_resources的1.2–1.5倍，避免shadow不足引发gc buffer busy acquire
改完必须重启实例生效，且要同步调大shared_pool_size——每增加1000个_gcs_resources，至少多留300MB shared pool
严禁在11g+版本用_lm_ress或_lm_locks强行扩量，这些参数已被废弃，设了反而触发内部校验失败

识别是否真由GCS/GES耗尽引发ORA-04031

ORA-04031常被误判为shared_pool不足，但RAC下大概率是GCS/GES结构挤占了free memory空间：

错误堆栈里出现kgghteInit或seg:kggfaAllocSeg，且v$sgastat显示free memory
错误堆栈里出现kgghstInit或kggfaAllocSeg，同时v$sgastat中gcs resources占比 > 40% → GCS结构吃光内存
AWR里row cache lock和cursor:pin S wait on X飙升，但library cache: mutex X不高 → 典型GCS挤占row cache空间
执行ALTER SYSTEM FLUSH SHARED_POOL无效，SELECT * FROM v$sgastat里free memory几乎不增长 → 基本锁定是perm结构占满