<p>enq: HW - contention是Oracle为串行化高水位线(HWM)推进而设的排他锁等待事件;RAC下因HW锁按segment粒度全局协调,多实例并发插入同一LOB表时争用剧烈,本质是单一段成为热点,需通过分区拆分segment或优化写入分布来根治。</p>

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,而不是性能参数。


















