在Oracle RAC集群中如何利用ASH分析全局缓存传输延迟-Oracle-PHP中文网

应优先使用v$active_session_history（每秒采样）而非awr定位gc瞬时卡顿；重点分析gc cr block busy（cr块构建慢）和gc current block busy（当前块被锁未释放）两类事件，结合v$all_active_session_history跨实例关联请求方与持有方，并注意p1/p2参数语义差异及对象反查细节。

在oracle rac集群中如何利用ash分析全局缓存传输延迟

直接看 `V$ACTIVE_SESSION_HISTORY` 里的 `gc cr block busy` 和 `gc current block busy`

ASH 每秒采样一次活跃会话，比 AWR 的小时级粒度更适合抓取 GC 传输卡顿的瞬时尖峰。别等 AWR 报告出来再查——GC 延迟往往只持续几秒，但足以拖垮批量作业。

重点过滤这两类事件：gc cr block busy 表示一致性读（CR）块构建慢，gc current block busy 表示当前块被其他节点锁定未释放。它们不是“传输失败”，而是“传输卡在中间”。

gc cr block busy 高频出现 + TIME_WAITED > 10ms，大概率是 _gc_read_mostly_locking 关闭或热点块频繁被读；
gc current block busy 高频 + CURRENT_OBJ# 聚集在同一个对象，说明该表/索引存在单点修改争用；
注意：RAC 中 p1/p2 含义随事件变化——gc current block busy 的 p1 是 file#，但 gc buffer busy acquire 的 p1 是 class#，必须查 v$event_name 确认，否则反查对象会错。

用 `V$ALL_ACTIVE_SESSION_HISTORY` 跨实例对齐时间线

单节点 V$ACTIVE_SESSION_HISTORY 只能看到本实例的等待，而 GC 传输涉及至少两个节点。真正的问题常藏在“请求方等得久、持有方没感知”的错位里。

V$ALL_ACTIVE_SESSION_HISTORY 自动聚合所有实例的 ASH 数据，并带 INST_ID 字段，可直接关联请求和响应：

Crypto Sniper Oracle

机构级量化市场预言机，提供订单簿失衡（OBI）、VWAP分析、自动化报告及Telegram预警。

下载

先查请求方：筛选 EVENT = 'gc cr block busy'，记录 SAMPLE_TIME、SESSION_ID、CURRENT_FILE#、CURRENT_BLOCK#；
再查同一时间点的持有方：用相同 CURRENT_FILE# 和 CURRENT_BLOCK#，找 EVENT LIKE '%current%grant%' 或 EVENT = 'db file sequential read'（说明块刚从磁盘读入）；
若持有方无对应活动，或 SAMPLE_TIME 明显滞后 > 50ms，基本可断定私网延迟或 GRD 同步异常。

定位到块后，用 `dba_extents` 反查对象要加分区名

拿到 file_id 和 block_id 后，不能只跑基础查询。分区表、索引组织表、LOB 段的块归属容易漏判，尤其当 gc buffer busy acquire 上升但 gc current block busy 不高时，问题可能出在本地 LRU 链竞争而非 GC 本身。

安全写法是连分区一起查：

SELECT owner, segment_name, segment_type, partition_name
FROM dba_extents
WHERE file_id = &file_id
AND &block_id BETWEEN block_id AND block_id + blocks - 1;

如果查不到结果，先确认是否为 undo 段：查 v$rollstat 或 v$transaction，此时需关注 undo_retention 和 UNDO 表空间自动扩展；
若查到是索引，检查是否为单调主键（如 SEQ.NEXTVAL）导致右边界热点，这类问题在 RAC 下会放大 GC 请求；
分区表务必看 partition_name，否则可能误判为基表争用，实际是某个高频访问分区引发的局部热块。

`log file sync` 时间异常高时，GC 延迟只是表象

当 gc cr block busy 和 gc current block busy 平均等待超过 100ms，且 log file sync 平均值也同步飙升（比如 > 300ms），不要急着调 GC 参数——这往往是 redo 写入卡住，导致持有方无法完成块刷新，进而让请求方无限等待。

验证方法：查 v$log 看 redo size 是否过小（bytes/1024/1024 ），尤其在 NOARCHIVELOG 模式下；
检查存储层：iostat -x 1 看 %util 和 await，若 await > 20ms 且 %util > 90%，说明 redo 日志所在磁盘组已成瓶颈；
RAC 下必须统一调整所有实例的 redo 组大小，否则节点间日志切换不同步，会触发额外的 gc cr grant 2-way 等待。