Undo段争用主因是回滚段头争抢或自动调优震荡，非空间不足；应通过V$UNDOSTAT查分钟级峰值（如MAXCONCURRENCY≥50、UNDOBLKS剧增、NOSPACEERRCNT/SSOLDERRCNT>0）和DBA_UNDO_EXTENTS分析状态失衡，而非依赖AWR平均值。
Undo段争用不是空间不够，而是回滚段头争抢或自动调优震荡导致的 latch 等待；直接查 V$UNDOSTAT 和 DBA_UNDO_EXTENTS 比看 AWR 报告更准。
查 V$UNDOSTAT 定位分钟级压力峰值
AWR 报告里的“Undo space used”是平均值，掩盖真实瓶颈。真正要盯的是每 10 分钟一个快照中的突刺：
-
MAXCONCURRENCY ≥ 50持续多分钟：说明大量事务在抢同一个回滚段头，_undo_autotune可能在频繁上下线 segment -
UNDOBLKS剧增但TXNCOUNT平稳：单个长事务（比如大表 UPDATE）写 undo 过多，不是全局配置问题 -
NOSPACEERRCNT > 0：对应时段确有物理空间不足，需立刻查DBA_UNDO_EXTENTS状态分布 -
SSOLDERRCNT > 0：一致性读失败，大概率是长查询 +undo_retention设置过低，和空间无关
执行：
SELECT BEGIN_TIME, END_TIME, UNDOBLKS, TXNCOUNT, MAXCONCURRENCY, SSOLDERRCNT, NOSPACEERRCNT FROM V$UNDOSTAT WHERE BEGIN_TIME > SYSDATE - 1/24 ORDER BY BEGIN_TIME DESC;
用 DBA_UNDO_EXTENTS 判断状态是否失衡
Undo 表空间爆满，90% 的情况不是总量不够，而是 ACTIVE + UNEXPIRED 堆积、EXPIRED 太少——意味着空间无法回收：
-
EXPIRED占比 -
UNEXPIRED过高 +TUNED_UNDORETENTION超 10 小时：说明_undo_autotune自动拉高了保留时间，导致空间不敢释放 -
ACTIVE持续高企：确认是否有未提交事务卡住，尤其注意V$SESSION.STATUS = 'INACTIVE'但V$TRANSACTION仍存在的空闲连接
执行：
SELECT STATUS, SUM(BLOCKS) BLOCKS_CNT, TRUNC(SUM(BLOCKS)*8/1024) SIZE_MB FROM DBA_UNDO_EXTENTS WHERE TABLESPACE_NAME = 'UNDOTBS1' GROUP BY STATUS;（把
UNDOTBS1 替换为你的表空间名）
确认是不是 _undo_autotune 在捣鬼
Oracle 19c 默认开启该隐含参数，它是 enq: US - contention 的主因，不是配置错，是机制本身在震荡：
- 运行
SHOW PARAMETER _undo_autotune：返回TRUE就基本坐实 - 查回滚段数量波动：
SELECT TO_CHAR(SAMPLE_TIME, 'HH24:MI'), COUNT(*) FROM V$UNDOSTAT GROUP BY TO_CHAR(SAMPLE_TIME, 'HH24:MI') ORDER BY 1;
如果分钟级 count 在 20～80 之间跳变，就是 autotune 在反复上线/下线 segment - 对比
V$ROLLNAME和V$TRANSACTION：online segment 数远超 transaction 行数，且大量 status 是PENDING或刚从OFFLINE恢复，也是典型表现
定位真实长事务：别只信 V$TRANSACTION.START_TIME
很多“长事务”其实是应用层连接池没设超时，连接挂着不动、事务没提交，V$TRANSACTION 能看到，但 V$SESSION.STATUS 是 INACTIVE、SQL_ID 为空——单靠前者会漏掉一半问题：
- 必须联合查：
SELECT s.SID, s.SERIAL#, s.USERNAME, s.STATUS, s.SQL_ID, t.START_TIME, t.USED_UBLK, t.USED_UREC FROM V$SESSION s JOIN V$TRANSACTION t ON s.SADDR = t.SES_ADDR;
- 重点关注
STATUS = 'INACTIVE'且USED_UBLK > 10000的会话，它们占着 undo 不放却无实际操作 - 这类事务通常没有对应 SQL，
SQL_ID为空，靠V$SESSION.LAST_CALL_ET或应用日志才能确认来源
最易被忽略的是：自动调优机制让 TUNED_UNDORETENTION 拉到几十万秒，而 DBA 只盯着 undo_retention 参数没变就以为配置没问题——其实它早已被绕过。
