<p>应通过ASH的current_file#和current_block#字段聚合定位热点块，执行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；再用DBA_EXTENTS按block_id至block_id+blocks-1区间匹配段名，而非等值查询，且需注意RAC环境下LCK0协调及current_obj#=0仍可能为真实热点。</p>
怎么从ASH里捞出真实的file#/block#？
ash不直接暴露热点块的物理位置，必须靠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<br>FROM v$active_session_history<br>WHERE event IN ('buffer busy waits', 'read by other session')<br>AND sample_time > SYSDATE - 1/24<br>GROUP BY current_file#, current_block#<br>ORDER BY cnt DESC<br>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值为什么不能跳过？
P3在Oracle 12c中是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带来的等待延迟特征。这两点一旦错判，后续所有优化动作都会偏离真实根因。
