enq: hw - contention不是锁表或死锁，而是多会话争抢同一段高水位线（hwm）推进权限；根本解法是减少hwm移动频次、分散空间分配压力，关键通过v$session_wait的p3解析rdba定位争用段，再结合dba_extents和dba_lobs确认对象类型（如lobsegment或回滚段），预分配extent可临时缓解但不根治，分区（尤其hash分区）能显著分流hw锁请求，而autoextend过小或assm配置不当会加剧争用。
直接结论：enq: hw - contention 不是锁表或死锁，而是多个会话争抢同一段（segment）的高水位线（hwm）推进权限。根本解法不是调参数，而是减少 hwm 移动频次、分散空间分配压力。
怎么定位争用的具体段对象
关键靠 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 字段或回滚段——这比普通表更易触发 HW 竞争 - 若
P2 = 1且对应表空间是UNDO，那实际是回滚段在频繁扩展，不是业务表本身的问题
为什么 allocate extent 能快速缓解但不能根治
手动预分配空间绕过了自动扩展时的 HW 锁排队，但只对当前段生效，且不解决并发写入模式问题：
-
ALTER TABLE t ALLOCATE EXTENT (SIZE 100M)对普通表有效，但对 LOB 段需操作SYS_LOBxxxx$$名称，得先从DBA_LOBS查真实段名 - 预分配大小建议 ≥ 当前最大 extent，避免刚分完又触发下一次自动扩展；
SELECT DISTINCT BYTES FROM DBA_EXTENTS WHERE SEGMENT_NAME = 'xxx'可查 - 该操作不释放已有碎片，也不影响后续 DML 分布；若表已严重碎片化，
ALLOCATE EXTENT只是“打补丁”，不是整理 - 在 RAC 环境中，extent 分配仍需跨实例协调，单节点预分配无法消除全局 HW 锁争用
分区（尤其是 hash 分区）为什么比调 SGA 更有效
HW 锁是按 segment 粒度串行化的，分区把一个段拆成多个物理段，天然分流 HWM 推进请求：
- 对高并发 insert 场景，
CREATE TABLE t (...) PARTITION BY HASH(id) PARTITIONS 8可将 HW 锁争用降低 70%+，前提是分区键能均匀分布写入 - LOB 字段必须配合表分区才能让 LOB 段也分区；单独对 LOB 列建索引或修改存储参数无效
- Oracle 12c 支持在线重定义（
DBMS_REDEFINITION）做不停机分区，但要求主键或唯一约束存在，且不能有未完成的物化视图日志 - 别迷信
ASSM（自动段空间管理）：它只优化空闲块查找，不改变 HW 锁机制；在高并发插入下，ASSM 反而可能加剧 bitmap 块争用
容易被忽略的底层诱因：autoextend + 小 extent_size
表空间配置不当会让 HW 竞争雪上加霜，尤其在 OLTP 批量写入场景：
- 检查争用对象所在表空间是否启用了
AUTOEXTEND ON且NEXT值过小（如 64K）——每次扩展都触发一次 HW 锁获取 -
SELECT tablespace_name, autoextensible, increment_by * (SELECT value FROM v$parameter WHERE name = 'db_block_size') FROM dba_data_files可算出实际扩展字节数 - 临时方案：对业务表所在表空间设大
NEXT（如 100M），长期方案是改用本地管理 + uniform size，避免动态计算 - 注意：
DB_FILES参数过低会导致数据文件无法新增，间接迫使 autoextend 更频繁，这也是隐性诱因
真正难处理的永远不是单次 HW 等待，而是当它和 enq: TX - row lock contention 或 log file sync 叠加时——这时候光分表没用，得看事务粒度和提交频率。不要只盯着 P3 查对象，先确认是不是批量 insert 里混了单行 commit。
