gc current request等待高需优先排查私网延迟（两两互ping avg>0.5ms须干预）、lms进程cpu是否持续>50%、ges队列cum_queue_time是否>100ms，三者同步逼近阈值时须协同优化。
gc current request 等待高，不是 SQL 有问题，而是块不在本地、网络没跟上、或者 LMS 撑不住——先别调执行计划，先查这三件事。
查私网延迟是否超标（ping -c 10 必须跑全链路）
Oracle 对私网延迟极其敏感，gc current request 的首跳耗时直接受其影响。文档明确要求：平均延迟 > 0.5ms 就必须干预。
- 用私网 IP（不是 VIP 或 public IP），在所有节点两两之间执行 ping -c 10，例如 node1 → node2、node1 → node3、node2 → node3
- 只看 avg 值，忽略 mdev；单次抖动不重要，持续偏高才危险
- 若某对节点 avg > 0.5ms，立刻检查交换机 buffer 配置、jumbo frame 是否全链路一致——MTU 必须全是 9000，混用 1500 是高频死因
- 别信“网络没问题”的口头判断，RAC 私网走 UDP，丢包或延迟会直接放大成等待
看 LMS 进程 CPU 是否持续过载（ps -eo pid,pcpu,comm 要盯住单个 PID）
LMS 是 GC 流量的最终承压点，CPU 不是“越高越好”，而是“不能持续 > 50%”。一旦超限，gc current block congested 会指数级上升。
- 用 ps -eo pid,ppid,pcpu,pmem,comm --sort=-pcpu | grep lms 找出持续 > 50% 的 lms0 或 lms1
- 结合 cat /proc/<pid>/stack</pid> 看内核栈：卡在 kslgetl 是锁争用，卡在 skgxp_receive 是网络收包卡住
- 检查 GCS_SERVER_PROCESSES 参数值是否匹配物理 CPU 核数（例如 16 核建议设为 4~6，不是默认的 2）
- 别只看全局 CPU 使用率——LMS 可能被 OS 调度器饿死，需确认其调度优先级是否被压低（Linux 下可用 chrt -r 99 设置实时优先级）
验 GV$GES_ENQUEUE.CUM_QUEUE_TIME 是否积压（高峰采样才有效）
cum_queue_time 是 GES 层消息排队总耗时（单位毫秒），它不反映单次等待，而暴露系统级吞吐瓶颈。> 100ms 是预警线，> 500ms 基本已触发重试风暴。
- 执行：SELECT inst_id, SUM(cum_queue_time) queue_ms FROM gv$ges_enqueue GROUP BY inst_id ORDER BY queue_ms DESC;
- 若某实例 queue_ms 显著高于其他（比如 3 倍以上），优先查该节点的 LMS 和私网
- 若所有实例都高，但私网延迟正常，则大概率是全局热点块（如序列索引页、高频更新配置表）引发的连锁请求
- 注意：该视图必须在等待高峰期间采样，空闲期查不到真实压力——AWR 报告里 Global Cache Load Profile 中的 CR blocks received 只是总量，不体现排队深度
关联等待链是否形成传导（oradebug -g all hanganalyze 3）
gc current request 很少孤立存在。典型恶化路径是：gc current request 延迟升高 → 远程块获取变慢 → 本地会话排队等块 → 触发 gc buffer busy acquire → 更多会话卡住 → LMS 负载反向飙升。
- 执行 oradebug -g all hanganalyze 3，重点识别类似 'gc current request' 的链式等待
- 若发现多条链都指向同一块（<code>p1/p2 相同），立即查对应对象是否为热点：
- SELECT owner, object_name, subobject_name FROM dba_objects WHERE data_object_id = &p1;
- 检查是否为单调序列主键索引、未分区的计数器表、ITL 槽不足的高并发表
真正麻烦的从来不是单点指标超标，而是私网延迟 + LMS CPU + cum_queue_time 三者同步逼近阈值——这时单项优化基本无效，必须协同调整。
