Oracle 12c使用ASH分析热点块竞争数据块信息

在Oracle 12c中，通过ASH（Active Session History）定位热点块竞争时，需重点依赖current_file#和current_block#这两个字段。它们是唯一能精准定位具体数据块的线索，不应使用sql_text或event的模糊匹配，否则效率低下且难以准确命中问题。

过滤条件应设置为event IN ('buffer busy waits', 'read by other session')，同时限制sample_time > SYSDATE - 1/24，即仅分析最近1小时的数据，以排除历史噪声干扰。需注意，current_obj# = 0并不代表没有对象，可能仅是刚刚进入逻辑读、尚未绑定段名的情况，此时更应关注current_file#和current_block#。执行聚合查询时，建议使用FETCH FIRST 5 ROWS ONLY快速获取Top热点，避免全表扫描导致的性能问题。

SELECT current_file#, current_block#, COUNT(*) cnt
FROM v$active_session_history
WHERE event IN ('buffer busy waits', 'read by other session')
AND sample_time > SYSDATE - 1/24
GROUP BY current_file#, current_block#
ORDER BY cnt DESC
FETCH FIRST 5 ROWS ONLY;

如何将file#/block#映射到真实段和对象？

直接使用DBA_OBJECTS.object_id关联会导致错误——current_block#对应的是逻辑块号，而DBA_OBJECTS.object_id不等于X$BH.obj，必须通过DBA_EXTENTS进行区间匹配。查询DBA_EXTENTS时，条件应为&BLOCK_ID BETWEEN block_id AND block_id + blocks - 1，而非简单的= block_id。一个块只属于一个extent，但可能跨多个segment（如分区表）。若查不到结果，则该块属于系统段（如回滚段、临时段或UNDO块），此时应转向v$rollstat或v$tempseg_usage。对于LOB段，需先查询DBA_LOBS找到真实段名（如SYS_LOB0000098765X$$），再对其进行操作，单独修改LOB列存储参数无效。

为何不能跳过P3值？

在Oracle 12c中，P3表示class#（块类型编号），并非原因码。如果跳过此步骤直接调整参数，效果甚微。不同类型的块，调优方向完全不同：

• P3 = 1：普通数据块热点，常见于升序主键INSERT或小表全扫描
• P3 = 4：段头争用，说明仍在使用MSSM表空间，FREELIST成为单点瓶颈
• P3 = 17或18：UNDO段头或UNDO块紧张，应扩展UNDO表空间，而非调整UNDO_RETENTION
• P3 = 130：块正在被其他会话从磁盘读入Buffer Cache，本质上是read by other session的前兆

RAC环境下查询热点块容易遇到哪些问题？

在RAC环境中，前台进程不直接申请锁，而是由LCK0进程代为协调，等待超时默认60秒（单实例为3秒）。若观察到大量row cache lock且p1指向dc_sequences，90%的概率是序列未设置CACHE——每次NEXTVAL都触发全局协调。应避免使用v$session_wait查询RAC热点，因为它反映的是本地等待视图。优先采用v$active_session_history，并注意inst_id字段。此外，预分配extent在RAC下仍需跨实例协调，单节点操作无法彻底消除全局HW锁争用。若buffer busy waits与gc buffer busy acquire并发出现，必须首先分离等待类型——否则添加freelist、扩展undo等操作均无法解决问题。

在实际操作中，最容易被忽略的是current_file#/current_block#与DBA_EXTENTS的区间匹配逻辑，以及RAC环境下LCK0带来的等待延迟特征。这两个环节一旦判断错误，后续所有优化动作都会偏离真实根因。