enq: US - contention 等待事件源于 _undo_autotune 动态调整回滚段引发的latch争抢，非undo表空间满；AWR中需重点关注UNXPSTEALCNT、OOS、SSOLDERRCNT突变趋势，并勾选「Undo Statistics」和「Rollback Segment Summary」；V$UNDOSTAT用于分钟级定位问题时段。
enq: US - contention 等待事件不是 undo 表空间满了，而是 _undo_autotune 动态调整回滚段引发的 latch 争抢；AWR 里真正要盯的是 UNXPSTEALCNT、OOS、SSOLDERRCNT 的突变趋势，不是“Undo space used”那一行数字。
查 AWR 报告时必须勾选的两个关键部分
默认 AWR 报告不显示 undo 细节，光扫 Summary 没用。进入生成界面后，务必手动勾选：
- 「Undo Statistics」——用于查看 UNXPSTEALCNT、OOS、SSOLDERRCNT 这三列的每小时快照值
- 「Rollback Segment Summary」——看各 rollback segment 的 ACTIVE/UNEXPIRED/EXPIRED 分布比例
漏掉任一项，等于只看了半张诊断单。特别注意：这些数值要看“快照间变化量”，不是平均值。比如 UNXPSTEALCNT 从 0 跳到 127，哪怕只发生一次，也说明有 active undo 被强制覆盖，ORA-01555 风险已实质存在。
V$UNDOSTAT 才是定位“哪一分钟崩了”的核心视图
AWR 是小时级汇总，而 undo 压力常在几分钟内爆发。直接查 V$UNDOSTAT 才能下钻到分钟级：
SELECT begin_time, end_time, undoblks, txncount, maxconcurrency,
ssolderrcnt, nospaceerrcnt, unxpstealcnt
FROM v$undostat
WHERE begin_time > SYSDATE - 1/24
ORDER BY begin_time DESC;
重点关注：
-
maxconcurrency≥ 50 且连续多分钟：高并发 DML 正在抢回滚段头，_undo_autotune 很可能在疯狂上线/下线 segment -
nospaceerrcnt> 0：对应时段确有物理空间不足，需立刻查dba_undo_extents的状态分布 -
undoblks剧增但txncount平稳：说明个别事务（如大表 UPDATE）写 undo 极多，不是全局配置问题
别被 EXPIRED 占比低误导，先确认是不是长事务占着不动
看到 DBA_UNDO_EXTENTS 里 EXPIRED 占比低于 20%，第一反应不该是加数据文件，而是查有没有“挂起的 INACTIVE 事务”：
SELECT s.sid, s.serial#, s.username, s.status, s.sql_id,
t.start_time, t.used_ublk
FROM v$session s, v$transaction t
WHERE s.saddr = t.ses_addr
ORDER BY t.start_time;
重点筛：status = 'INACTIVE' 且 used_ublk > 1000 的会话——它们没在执行 SQL，却占着大量 undo 块。这类事务常见于应用连接池未设超时、或 PL/SQL 块里带 DBLINK 查询+循环 commit（每次都会分配新 XID 和 rollback segment）。
_undo_autotune 开关与实际影响
Oracle 19c 默认开启 _undo_autotune，它是 enq: US - contention 的主要推手。确认方法很简单：
SHOW PARAMETER _undo_autotune
如果返回 TRUE，基本就是它。关闭前先评估：若业务存在明显波峰波谷（如日终批处理），关掉反而可能导致 peak 时段因回滚段不足而卡死。更稳妥的做法是结合 undo_retention 调整 + 手动预热固定数量的 rollback segment（通过 ALTER SYSTEM SET "_rollback_segment_count"=32），把动态伸缩变成可控的静态分配。
最易被忽略的一点：UNXPSTEALCNT 和 SSOLDERRCNT 同时非零，往往意味着长查询 + 低 undo_retention，此时调高 retention 比扩容 undo 表空间更有效——因为问题不在空间大小，而在回收节奏和读一致性窗口不匹配。
