gc buffer busy acquire指本地会话等待远程实例传输数据块，常见于热点索引叶块的高频访问；gc buffer busy release指本地实例刚用完块而远程实例等待其释放锁，多见于短事务密集提交场景。
gc buffer busy acquire 和 release 怎么区分处理
先看等待类型再动手，不能一概而论。acquire 是本地会话等远程实例上的块还没传过来；release 是本地实例刚用完块，但远程实例还在等它释放锁。两者触发点不同：gc buffer busy acquire 多见于高频查询或插入热点索引叶块；gc buffer busy release 更常出现在短事务密集提交、或大事务结束后的资源清理阶段。
查实时会话时重点关注 p1 和 p2：acquire 的 p1 通常是远程实例的 file#，p2 是 block#；release 的 p1 往往是本地对象 ID（object_id），p2 是锁模式（如 6 表示 X 锁）。误判类型会导致优化方向完全跑偏——比如把 acquire 当成 release 去调 GES 队列深度，反而掩盖了真正的网络或热点块问题。
AWR 里 Segments by Global Cache Buffer Busy 看什么
这个报告节不是只看“次数最多”的对象，而是要交叉验证三件事：
- 该对象是否在多个实例上被频繁访问（查
inst_id分布） - 对应 SQL 是否存在跨实例执行倾向（比如绑定变量未启用、SQL 不走绑定变量缓存）
- 该段类型是否天然易热——例如主键索引（尤其单调递增）、小配置表全表扫描、序列生成器所在的索引页
常见陷阱：只看到某张表排第一，就立刻加分区。但如果该表实际只有节点 1 在写、节点 2 在读，且读写分离明确，那根本不需要动表结构，只需检查应用连接路由或 service 的 clb_goal 设置是否合理。
热点块优化为什么不能只靠反向索引或哈希分区
反向索引（REVERSE）和哈希分区确实能打散写入热点，但它们有明确适用边界：
- 反向索引破坏范围扫描能力，如果业务存在大量
WHERE create_time BETWEEN ...查询，性能可能断崖下跌 - 哈希分区数必须与实例数及负载分布匹配——曾有案例将流水表按机构哈希分成 64 分区，但 4 家大机构占 80% TPS，结果 64 个分区里 4 个热分区集中在同一实例，反而加剧
gc buffer busy acquire - 分区键选择错误（如用
user_id分区但查询总带order_id）会导致分区裁剪失效，逻辑读翻倍，间接放大 GC 压力
真正有效的起点是确认热点是否来自单一块（比如索引根块或第一个叶块），可用 SELECT * FROM v$bh WHERE objd = &obj_id AND ts# = &ts_num ORDER BY tch DESC 查缓冲区热度，而不是直接改 DDL。
LMS 进程 CPU 超 50% 怎么快速定位瓶颈
LMS 持续超过 50% CPU 不是“还能撑”，而是 GC 流量已开始积压的明确信号。此时别急着调参数，先做两件事：
- 用
ps -eo pid,ppid,pcpu,pmem,comm --sort=-pcpu | grep lms确认是哪个lms0或lms1单点吃满，不是所有 LMS 均匀负载 - 对高 CPU 的 PID 执行
cat /proc/<pid>/stack</pid>，若栈顶反复出现kslgetl，说明 GES 锁争用严重；若卡在skgxp_receive，基本锁定私网收包瓶颈（交换机 buffer 不足或 jumbo frame 未端到端开启）
注意：GCS_SERVER_PROCESSES 参数调高未必有用——如果底层网络延迟 >0.5ms 或 MTU 混用（部分链路 1500、部分 9000），增加 LMS 数只会让消息排队更深，cum_queue_time 反而飙升。先验网络，再调参数。
真正难处理的不是单点热点，而是多层传导：一个 gc current request 延迟升高 → 触发 gc buffer busy acquire → 排队会话增多 → enq: TX - contention 上升 → LMS 负载反向推高。这种链式反应里，最先被采样的等待事件未必是根因。
