rac跨实例块争用不能只查dba_hist_active_sess_history，因其仅采集本实例数据，无法捕获远程阻塞会话；必须用gv$active_session_history或各节点v$ash联合分析，并结合blocking_instance、p1/p2、p3等字段精准定位真实热点。
为什么RAC跨实例块争用不能只查DBA_HIST_ACTIVE_SESS_HISTORY
DBA_HIST_ACTIVE_SESS_HISTORY默认只采集本实例数据，跨节点的blocking_session根本不会出现在结果里——你看到的“无阻塞源”，大概率是漏掉了真正持锁的远程会话。真实场景中，90%以上的GC类块争用（比如gc cr block busy、gc buffer busy acquire）都发生在跨实例路径上。
必须用GV$ACTIVE_SESSION_HISTORY，它聚合所有实例的实时采样；如果权限受限，至少要在每个节点上分别执行v$active_session_history查询，再人工比对inst_id和blocking_instance字段。
- 别用
dba_hist_active_sess_history查实时问题：它依赖AWR快照，延迟通常在5–15分钟，等你捞到数据时争用早结束了 -
blocking_instance为空不等于没跨节点：某些瞬时GC等待可能未完整记录blocking_instance，需结合p1(file#)、p2(block#)在各节点反查 - RAC环境下
current_file#和current_block#仍有效，但必须配合inst_id分组，否则聚合结果会把不同实例的同一块误判为“更热”
怎么从GV$ASH里抓出真实的跨实例块争用样本
核心是过滤GC类等待事件 + 明确指向远程实例的阻塞关系。只盯event LIKE 'gc%'还不够，得锁定那些正在等、且明确知道谁在另一台机器上卡着它的会话。
执行这条语句快速定位：
SELECT inst_id, sample_time, sql_id, event, p1, p2, blocking_instance, blocking_session
FROM gv$active_session_history
WHERE event IN ('gc cr block busy', 'gc buffer busy acquire', 'gc current block busy')
AND wait_time = 0
AND blocking_instance IS NOT NULL
AND sample_time > SYSDATE - 3/1440;
-
wait_time = 0表示该会话正卡在等待中，不是刚完成或已超时；跳过这条件，80%的样本是历史噪音 -
blocking_instance IS NOT NULL是硬门槛，排除本地锁或自旋等待；如果查不到，说明要么没跨实例，要么争用发生在更底层（如LCK0协调失败） - 时间窗口压到3分钟内（
3/1440），避免GC重试机制导致样本重复放大 -
p1和p2就是file#和block#，和单实例一样可用来反查dba_extents，但注意：RAC中同一块可能被多个实例缓存，争用点未必是业务表，也可能是回滚段头块或UNDO block
拿到file#/block#后，如何确认是不是真实热点块而非GC假象
GC等待本身不等于物理块真忙，可能是远程实例缓存同步慢、网络延迟高，或本地实例请求路径异常。必须交叉验证当前块是否在多个实例上同时高频出现。
执行聚合对比：
SELECT inst_id, current_file#, current_block#, COUNT(*) cnt
FROM gv$active_session_history
WHERE event IN ('gc cr block busy', 'gc buffer busy acquire')
AND sample_time > SYSDATE - 1/1440
GROUP BY inst_id, current_file#, current_block#
HAVING COUNT(*) > 5
ORDER BY cnt DESC;
- 按
inst_id分组计数，才能看出是单实例局部抖动，还是多实例共同争抢同一块 -
HAVING COUNT(*) > 5过滤掉偶发采样噪声；ASH每秒采样，连续5秒以上出现才算可信热点 - 如果某块只在
inst_id=2高频出现，而inst_id=1几乎为0，优先查该实例的网络、CPU或redo传输链路，而不是立刻调优对象存储参数 - 查
dba_extents时仍要用&BLOCK_ID BETWEEN block_id AND block_id + blocks - 1区间匹配，别用等值；RAC中LOB段、分区索引头块特别容易成为GC热点，但它们的current_obj#常为0
为什么P3值在RAC块争用里不能跳过
P3在GC等待事件里是class#（块类型编号），直接决定争用性质。忽略它，就分不清是数据块、段头、回滚段头还是UNDO块在抢——调参方向完全相反。
-
P3 = 1：普通数据块，检查是否升序主键+高并发INSERT导致HWM推进争用 -
P3 = 4：段头块，说明还在用MSSM表空间，FREELIST是单点瓶颈，必须迁移到ASSM -
P3 = 130：UNDO块，对应US-开头的resource_name，意味着事务未提交或回滚慢，要查v$transaction和v$rollstat -
P3 = 220：数据块DML冲突，常见于同一行被多实例UPDATE，得看SQL是否缺少绑定变量或存在热点键设计缺陷
真正麻烦的是P3=130或220却查不到对应事务——这时往往已回滚，但UNDO块释放延迟，得结合v$fast_start_transactions和v$session_longops看是否有长时间回滚残留。
