Buffer Busy Waits 严重需先查P3值定位块类型：P3=1为数据块热、P3=4为段头争用（应迁ASSM）、P3=17/18为UNDO资源紧张（需扩容UNDO表空间而非调UNDO_RETENTION）、P3=130表示块正被其他会话读入缓存。
buffer busy waits 在 oracle 12c 中严重，说明有会话正在高频争用同一内存块（热块），不是配置参数调大就能缓解的——必须定位到具体块类型和对象，再针对性隔离或分散访问路径。
查 P3 值确认块类型是关键第一步
Oracle 12c 的 buffer busy waits 等待事件中，P3 不再是原因码，而是 class#（块类型编号）。不看这个值就动手调参，大概率白忙。
-
P3 = 1：普通数据块（data block），常见于高并发 INSERT 到小表、索引叶块争用 -
P3 = 4：段头块（segment header），典型场景是 MSSM 表空间下 FREELIST 争用 -
P3 = 17或18：UNDO 段头或 UNDO 块，说明回滚段资源紧张或事务一致性读压力大 -
P3 = 130：表示该块正被另一个会话从磁盘读入 Buffer Cache（即READ BY OTHER SESSION的前兆）
执行以下语句快速抓取当前 Top 热点：
SELECT p1 AS file#, p2 AS block#, p3 AS class#, COUNT(*) cnt FROM v$session_wait WHERE event = 'buffer busy waits' GROUP BY p1, p2, p3 ORDER BY cnt DESC FETCH FIRST 5 ROWS ONLY;
段头争用（P3=4）优先切到 ASSM 表空间
手动段管理（MSSM）下 FREELIST 段头是单点瓶颈，尤其在批量 INSERT 场景。Oracle 12c 默认支持 ASSM，但老系统迁移后可能仍保留 MSSM 表空间。
- 检查段所在表空间是否为 ASSM：
SELECT tablespace_name, segment_space_management FROM dba_tablespaces WHERE tablespace_name = 'YOUR_TS'; - 若为
MANUAL，不要直接 ALTER TABLESPACE —— 需重建：导出数据 → 创建新 ASSM 表空间 → 导入，并指定SEGMENT SPACE MANAGEMENT AUTO - 对无法迁移的 MSSM 表，可临时加 FREELISTS（如
ALTER TABLE t STORAGE(FREELISTS 8)），但仅治标；FREELIST GROUPS 更有效，但需配合多实例或高并发 INSERT 模式
数据块热（P3=1）要拆散访问路径，不是加 buffer cache
盲目增大 db_cache_size 对 buffer busy waits 几乎无改善，反而可能加剧 CBC latch 争用。重点是让访问“散开”：
- 索引叶块热（升序主键 INSERT）：改用
REVERSE KEY索引，或拆成HASH分区索引（如CREATE INDEX i ON t(id) GLOBAL PARTITION BY HASH(id) PARTITIONS 8） - 小表全扫热（如配置表）：加
/*+ FULL(t) */提示强制走全表扫描 + 结合RESULT_CACHE缓存结果，避免反复逻辑读同一组块 - 高并发 UPDATE 同一块内多行：检查是否能通过业务拆分（如按租户 ID 分区）、或加
ROWID范围条件限制单次 UPDATE 行数，降低单块修改密度
UNDO 相关热块（P3=17/18）别只盯 UNDO_RETENTION
UNDO_RETENTION 调大不能解决段头（17）或块（18）争用，反而可能让 UNDO 表空间更快撑满。真实瓶颈常在 UNDO 表空间配置本身：
- 确认 UNDO 表空间是否为自动扩展：
SELECT file_name, autoextensible, maxbytes FROM dba_data_files WHERE tablespace_name = (SELECT value FROM v$parameter WHERE name = 'undo_tablespace'); - UNDO 表空间太小或数据文件未开启
AUTOEXTEND，会导致频繁区分配，触发段头争用（P3=17） - UNDO 表空间只有一个数据文件？建议至少 2–4 个均等大小的数据文件，分散区分配压力
- 如果
v$undostat显示unxpstealcnt> 0，说明已发生 UNDO 块覆盖，此时应优先扩容 UNDO 表空间，而非调UNDO_RETENTION
真正容易被忽略的是：热块问题一旦涉及 UNDO，往往意味着上层 SQL 存在长事务或未提交会话，务必同步检查 v$transaction 和 v$session 中长时间未提交的 SID。
