<p>RMAN本身不直接引发enq: HW - contention，但其备份操作可能间接触发HW锁争用：如BACKUP ARCHIVELOG DELETE INPUT、CONTROLFILE AUTOBACKUP或AUDIT_TRAIL=EXTENDED下写入sys.aud$等含LOB的系统表，导致高并发HWM推进；需通过v$active_session_history和v$lock定位真实争用对象而非RMAN进程本身。</p>
rman 本身不会直接引发 enq: hw - contention，但备份过程中若触发了底层段空间分配（尤其是 lob、大表或自动扩展的 undo/临时段），就可能间接导致该等待。
为什么 RMAN 备份会牵扯到 HW 锁
RMAN 是一个客户端工具，它不直接操作数据块分配；但它的某些操作会迫使数据库执行 DML 或内部写入，进而推进高水位线（HWM）：
- 执行
BACKUP ARCHIVELOG ALL DELETE INPUT时，RMAN 调用内部清理逻辑，可能触发归档日志元数据更新或控制文件变更，这些操作在某些版本（如 11.2.0.3 前）会写入sys.aud$或审计相关表 —— 若这些表含 LOB 字段且无分区，高并发写入就会争用 HW 锁 - 使用
CONFIGURE CONTROLFILE AUTOBACKUP ON且控制文件频繁增长（如大量归档切换+RMAN catalog 操作），控制文件自身虽不走 HW 锁，但其关联的controlfile record section扩展可能映射到底层系统表空间中带 LOB 的段 - 在备份期间同时运行大量
INSERT /*+ APPEND */或批量UPDATE（比如 ETL 脚本未错峰），RMAN 进程虽不参与，但共享同一实例资源；此时v$active_session_history中看到的enq: HW - contention往往归属那些业务 SQL，而非 RMAN 进程本身
重点排查：哪些备份行为真会触发 HW 分配
真正由 RMAN 直接或强耦合引发 HW 等待的场景极少，但以下配置或操作值得验证：
- 启用了
AUDIT_TRAIL = DB, EXTENDED且 RMAN 执行了大量 catalog 操作（如REGISTER DATABASE、RESYNC CATALOG），审计记录写入sys.aud$表 —— 该表在 11g 中默认含sql_textCLOB 字段，无分区时极易成为 HW 争用源 - 备份脚本中混用了
CONNECT TARGET通过网络连接（非 OS 认证），且SQLNET.EXPIRE_TIME设置过小（如 10），导致连接中断后 RMAN 重连并重试操作，引发重复元数据写入和段扩展 - 使用了
BACKUP AS COPY+SWITCH流程，在复制过程中目标表空间为 ASSM 且未预分配足够空间，COPY 操作内部模拟大量 INSERT，触发 LOB 段 HWM 推进
如何快速确认是否真是 RMAN 引发的 HW 等待
别猜，用视图定位真实源头：
- 查
v$active_session_history中等待enq: HW - contention的会话：SELECT session_id, sql_id, event, p1, p2, p3, sample_time FROM v$active_session_history WHERE event = 'enq: HW - contention' AND sample_time > SYSDATE - 1/24 ORDER BY sample_time DESC;
注意看session_id是否属于PROGRAM = 'rman@...'—— 绝大多数情况下不是 - 若
p2（表空间号）对应的是SYSAUX或SYSTEM，立刻查该表空间内最近增长的段：SELECT owner, segment_name, segment_type, bytes/1024/1024 mb FROM dba_segments WHERE tablespace_name IN ('SYSAUX','SYSTEM') AND bytes > 100*1024*1024 ORDER BY bytes DESC;
重点关注aud$、logmnr_*、lob$相关段 - 检查
v$lock中 HW 锁持有者：SELECT sid, type, id1, id2, lmode, request FROM v$lock WHERE type = 'HW';
结合v$session查出对应 SQL，往往指向应用日志表或审计表，而非 RMAN 控制语句
真正要盯紧的，从来不是 RMAN 命令本身，而是它运行时数据库里正在被谁写、往哪写、写了多大 —— HW 锁只管“谁来分配新空间”，不管“谁发起备份”。
