enq: us - contention是undo段头争用等待事件，本质为多会话竞争同一undo段头的排他访问权；oracle 11g默认启用自动undo管理且事务量突增、undo_retention过短或表空间配置不合理时易高频出现。
enq: US - contention 是什么，为什么它在 Oracle 11g 中特别容易冒头
这个等待事件本质是多个会话争抢同一个 UNDO 段头（undo segment header）的排他访问权。Oracle 11g 默认启用自动 UNDO 管理（AUM），所有事务都依赖 UNDO 表空间里的在线段。当事务量突增、UNDO_RETENTION 设置过短、或 UNDO 表空间本身配置不合理时，系统会频繁尝试分配/复用/扩展 UNDO 段——而段头就是串行点，一卡全卡。
常见诱因包括：大批量短事务集中提交、使用 DBLINK 的分布式事务（每个远程调用都独占一个 UNDO BLOCK）、或 UNDO 表空间数据文件 autoextend 开启但初始尺寸太小，导致频繁扩展段头元数据。
检查当前 UNDO 段使用是否健康
别急着调参数，先确认是不是真有问题：
- 查
enq: US - contention在 AWR 报告中是否进入 Top 5 等待事件 - 运行：
SELECT usn, state, undoblocks, txncount FROM v$rollstat ORDER BY txncount DESC;—— 若多个state = 'PENDING OFFLINE'或txncount长期 > 20，说明段头被反复争抢 - 查
v$undostat的unxpstealcnt和ssolderrcnt：非零值表示发生过 UNDO 块过早回收（ORA-01555风险）或回滚段空间不足被迫复用
调整 UNDO 表空间和参数的关键动作
Oracle 11g 的 UNDO 管理不支持手动段管理（MSM），所以重点在空间规划与参数协同：
- 确保 UNDO 表空间是
AUTOEXTEND OFF或至少设了合理MAXSIZE，避免失控增长掩盖真实压力 —— 执行：ALTER DATABASE DATAFILE '<undo_file_path>' AUTOEXTEND OFF;</undo_file_path> -
UNDO_RETENTION不宜盲目调大。11g 有RETENTION GUARANTEE，但开启后可能直接触发ORA-30036；更稳妥的是根据v$undostat.maxquerylen值 + 20% 安全余量设置，例如最大查询运行 120 秒，则设UNDO_RETENTION = 150 - UNDO 表空间总大小建议 ≥ 峰值每小时事务生成的 UNDO 数据量 × 2。估算公式：
(SELECT SUM(undoblks) * TO_NUMBER(value) / 3600 FROM v$undostat s, v$parameter p WHERE p.name = 'db_block_size') AS avg_undo_per_sec
应用层配合：减少 UNDO 段头争用的硬招
参数调优只是兜底，真正压降 enq: US - contention 得从源头控制事务行为：
- 避免在循环里执行单条
INSERT/UPDATE后立即COMMIT—— 改成批量提交（如每 1000 行一次），显著降低段头更新频次 - DBLINK 查询务必加
COMMIT或显式ROLLBACK，否则每个远程调用都会长期占用一个 UNDO 段（你看到的enq: US - contention很可能就来自这些“僵尸”段） - 对只读报表类查询，若允许轻微陈旧数据，可在会话级加
SET TRANSACTION READ ONLY，完全绕过 UNDO 分配
UNDO 段争用不是孤立现象，它常和 latch: row cache objects（因高频访问 dc_rollback_segments）一起出现。如果调完参数仍高，优先排查是否有未关闭的 DBLINK 连接或长事务卡住 UNDO 段释放。
