应查v$undostat看maxconcurrency是否持续≥20或频繁达50+以判断undo争用，结合undoblks与txncount突刺识别长事务；再用dba_undo_extents检查expired占比是否低于20%；联合v$session与v$transaction定位inactive长事务；确保undo_management=auto并合理设置undo_retention。
查 V$UNDOSTAT 看 MAXCONCURRENCY 是否持续超标
AWR 报告本身不标“undo争用”，但 V$UNDOSTAT 是底层真实反映。每10分钟一个快照，关键不是平均值，而是盯住 MAXCONCURRENCY：若长期 ≥ 20 或频繁跳到 50+，说明多个事务在抢回滚段头或区分配锁。
实操建议：
- 运行
SELECT BEGIN_TIME, END_TIME, UNDOBLKS, TXNCOUNT, MAXCONCURRENCY FROM V$UNDOSTAT ORDER BY BEGIN_TIME DESC FETCH FIRST 20 ROWS ONLY - 若某时段
MAXCONCURRENCY高企，且UNDOBLKS增速远超TXNCOUNT（比如事务数涨2倍，Undo块涨5倍），大概率存在未提交长事务或批量操作卡住空间 -
UNDOBLKS单位是数据库块（通常8KB），不是字节，别误算成MB
用 DBA_UNDO_EXTENTS 检查 EXPIRED 区块是否严重不足
Undo 表空间爆满，往往不是总量不够，而是 ACTIVE / UNEXPIRED 区块堆积、EXPIRED 区块太少——说明 undo_retention 设得过长，或空间回收被阻塞。正常应有 30%~60% 的 EXPIRED，低于 20% 就危险。
实操建议：
- 执行
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替换为你的表空间名） - 若
ACTIVE+UNEXPIRED占比 > 90%，且EXPIRED接近 0，优先排查长事务，而不是急着加数据文件 -
UNEXPIRED过高还可能因undo_retention被设为 86400（24小时）却无自动扩展，Oracle 不敢回收——此时调低 retention 比扩容更治本
联合 V$SESSION 和 V$TRANSACTION 定位真实长事务
V$TRANSACTION.START_TIME 显示事务开始时间，但很多“长事务”其实是空闲连接挂着未提交（比如应用连接池没设超时），这类事务在 V$TRANSACTION 里能看到，但在 V$SESSION 中 STATUS 是 INACTIVE、SQL_ID 为空。单靠 V$TRANSACTION 会漏掉一半问题。
实操建议：
- 运行
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的会话——它们占着 Undo 空间却不干活 - 对这类会话，先确认业务是否允许 kill：
ALTER SYSTEM KILL SESSION 'sid,serial#' IMMEDIATE
注意 enq:HW-contention 和 latch:in memory undo 的隐性干扰
大量并发 insert/update 可能触发 HW 锁争用（enq:HW-contention），尤其在回滚段急速扩张时；而 Oracle 10g+ 启用的 in-memory undo（IMU）虽缓解了部分磁盘压力，但又引入新的竞争点：latch:in memory undo。这两类等待常被误判为纯 Undo 表空间不足。
实操建议：
- 查 HW 争用：
SELECT event, wait_time_milli, seconds_in_wait FROM V$SESSION_WAIT WHERE event LIKE 'enq:HW%' - 查 IMU 争用：
SELECT name, gets, misses, sleeps FROM V$LATCH WHERE name LIKE '%in memory%' - 若
sleeps > 0且持续增长，说明 IMU 区域成为瓶颈，需结合共享池使用率综合判断是否要调大shared_pool_size
