gc cr request等待高时，应优先排查私网延迟（两两互ping avg＞0.5ms需干预）、lms进程cpu是否持续＞50%、ges队列cum_queue_time是否＞100ms，三者同步逼近阈值时须协同优化。
gc cr request 等待高，不是 SQL 写得差，而是块没在本地、网络没跟上、或 LMS 撑不住——先别调执行计划，先查这三件事。
查私网延迟是否超标（ping -c 10 必须跑全链路）
Oracle 对私网延迟极其敏感，gc cr 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 私网不走 TCP 连接池，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 调度器饿死，需确认其调度优先级是否被压低
验 GES 队列是否积压（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 cr request 很少孤立存在。典型恶化路径是：gc current request 延迟升高 → 远程块获取变慢 → 本地会话排队等块 → 触发 gc buffer busy acquire → 更多会话卡住 → LMS 负载反向飙升。
- 执行
oradebug -g all hanganalyze 3，重点识别类似'gc current request' 的链条 - 如果看到
cr request retry+library cache lock+cursor: pin S wait on X同时出现，大概率是后台任务（如数据泵导出）与前台建索引冲突所致 - 不要只盯着 SQL 执行计划——即使 plan 完全一样，只要服务路由、分区策略或网络状态变了，
gc cr request实际耗时就可能从 0.3ms 涨到 8ms，而这个变化不会体现在display_cursor输出里
真正难处理的从来不是单点参数，而是三者同步逼近阈值：私网延迟刚过 0.5ms、LMS CPU 卡在 48%、GES 队列累计到 90ms——此时任何单项调整都会被其他瓶颈拖回原形。最容易被忽略的是时间窗口：很多问题只在夜间批处理+白天查询叠加时爆发，白天巡检一切正常，不代表没有问题。
