根本原因是资源释放路径卡顿，而非热点块本身；gc buffer busy release发生于本地会话等待远程实例完成块释放，常见于LMD繁忙、私网延迟高、长事务回滚、LMD PGA内存超200MB等场景。
这不是“访问太猛”，而是“释放太慢”——根本原因在资源释放路径卡顿，不是热点块本身。
gc buffer busy release 的真实触发场景
它发生在本地实例会话想访问一个块，但该块正被远程实例持有、且远程端迟迟未完成释放动作。注意：等待方是“等别人松手”，不是“抢着要”。常见于以下情况：
- 事务提交后，LMD进程忙于处理GES队列，来不及广播RELEASE消息
- 私网延迟高（尤其8KB包耗时 >1.5ms），导致释放确认超时或丢包
- 长事务回滚或清理PI块时，需协调多个实例，释放链路变长
- LMD进程PGA内存持续 >200MB（查
gv$process中LMD的pga_used_mem），说明协调能力已饱和
和 acquire 的关键区别在哪
gc buffer busy acquire是“我在等你读完”，gc buffer busy release是“我在等你交出锁”。前者常由SQL逻辑读集中引发，后者几乎从不因SQL写法直接导致——优化SQL对它效果甚微。
- 如果
gv$system_event里两个事件同时高，且gc buffer busy release占比超30%，优先排查LMD/GES，而非改SQL -
SELECT inst_id, event, total_waits, time_waited_micro FROM gv$system_event WHERE event IN ('gc buffer busy acquire','gc buffer busy release')是必须跑的第一句 - 查
gv$ges_blocking_enqueue能暴露阻塞源头，比如某个会话卡在enq: TX - row lock contention上，拖慢了整个释放链
哪些操作会让 release 等待突然飙升
不是所有DDL或DML都一样。以下操作极易诱发释放卡顿：
-
TRUNCATE表（尤其跨实例）：触发全局对象锁重置，LMD需同步大量元数据 - 批量
UPDATE后未及时COMMIT：每个修改块都生成PI，释放时需逐个协调 - 强制
KILL SESSION后残留锁：GES未收到正常清理信号，锁泄漏持续存在 - Oracle Bug（如
Bug 24303124）：特定版本下GES资源清理逻辑缺陷，表现为释放消息静默丢失
最容易被忽略的诊断盲区
很多人只看AWR里的“Segments by Global Cache Buffer Busy”，但gc buffer busy release的热点往往不在段级，而在协调层。
- 私网ping延迟必须测8KB包，不是500字节小包——
Interconnect Ping Latency Statistics里8KB平均值 >1.5ms 就得动手调网卡MTU或交换机QoS -
gv$transaction里used_ublk > 1000且start_time超30分钟的会话，是典型释放拖累源，应优先KILL - 别只盯着
LMS进程，LMD才是释放阶段的关键角色；_lmdd_pga_limit隐含参数调整需Oracle支持背书，不能自行硬改
