enq: hw - contention是oracle为串行化高水位线（hwm）推进而设的排他锁等待事件；rac下因hw锁按segment粒度全局协调，多实例并发插入同一lob表时争用剧烈，本质是单一段成为热点，需通过分区拆分segment或优化写入分布来根治。
enq: HW - contention 是什么，为什么它在 RAC 插入时特别痛
它不是锁表，也不是事务冲突，而是 Oracle 为推进段（segment）高水位线（HWM）所用的串行化机制：每次要往 HWM 以上分配新数据块（比如插入导致空间不足），就必须抢到一个排他 HW 锁（mode=6）。RAC 下这个锁是全局资源，所有实例都得通过 GES 协调——一旦多个会话同时想“抬高水位”，就会排队等 enq: HW - contention。
关键点在于：HW 锁按 segment 粒度加锁。一张表（尤其含 CLOB 字段）就是一个 segment；哪怕你有 16 个 RAC 节点，所有插入都挤在这一个段上，就等于所有人抢同一扇门。
- 含 LOB 的表（如
SDE_LOB_MEDICALRECORD）极易触发——每次大 LOB 插入常需多块连续空间，频繁推 HWM - RAC 中 extent 分配仍需跨实例同步，哪怕你手动
ALLOCATE EXTENT，也只是延缓，不能消除锁粒度问题 - AWR 中若
enq: HW - contention出现在 top 5，且P3值反复落在同一RDBA，基本可锁定是单一热点段
怎么确认是 HW 争用，而不是别的锁或 IO 问题
别只看等待事件名。必须从 v$session_wait 的 P3 入手反查物理位置：
-
P3是相对数据块地址（RDBA），用DBMS_UTILITY.data_block_address_file和DBMS_UTILITY.data_block_address_block拆出file_id和block_id - 再用这两个值查
DBA_EXTENTS，条件必须是&block_id BETWEEN block_id AND block_id + blocks - 1（不是等于！） - 若查到
SEGMENT_TYPE = 'LOBSEGMENT'或'ROLLBACK'，说明争用来自 LOB 或回滚段——这两类比普通表更敏感 - 若
P2 = 1且对应表空间是UNDO，实际是 undo 段在扩展，和业务表无关
混发信号要警惕：enq: HW - contention 常伴随 buffer busy waits（P3=4 表示段头块争用）或 gc buffer busy acquire（RAC 下跨实例块争用）。不先分离，调 freelist 或扩 undo 全是白忙。
为什么预分配 extent 和调大 cache_size 都治标不治本
手动 ALTER TABLE t MODIFY LOB (col) (ALLOCATE EXTENT (SIZE 100M)) 确实能绕过一次自动扩展的 HW 锁排队，但问题没消失：
- 对 LOB 段，必须先查
DBA_LOBS找真实段名（如SYS_LOB0000098765X$$），再对其操作；直接对表名操作无效 - 预分配大小建议 ≥ 当前最大 extent，查法：
SELECT DISTINCT BYTES FROM DBA_EXTENTS WHERE SEGMENT_NAME = 'xxx' - RAC 环境中，即使你在节点1执行了预分配，下次其他节点插入仍可能触发新的 HW 推进——因为段头信息同步有延迟，锁还是得抢
-
SEQUENCE.CACHE调大（如CACHE 1000 NOORDER）解决的是enq: SQ - contention，跟 HW 完全无关；混淆这两者是常见误判
真正有效的解法只有两个方向
一是拆段，二是控写入分布。没有第三条路：
- 分区（尤其是
HASH分区）把一个 segment 拆成 N 个物理段，HW 锁自然分流。实测可降enq: HW - contention70%+，前提是分区键能均匀分布写入流量 - LOB 字段必须配合表分区才能让 LOB 段也分区；单独改
STORAGE参数或建 LOB index 无效 - 对流水表这类写入热点，range + hash 复合分区（如按日期 range、按机构 hash）比纯 date range 更有效——避免大机构数据扎堆在少数分区
- Oracle 12c+ 支持在线重定义（
DBMS_REDEFINITION）做不停机分区，但要求主键或唯一约束存在，且不能有未完成的物化视图日志
最易被忽略的是：HW 争用往往藏在 LOB 操作背后，而 DBA 第一反应总去查索引或 redo。只要看到插入语句里带 CLOB 或 BLOB，优先怀疑 HW，而不是性能参数。
