v$undostat中maxconcurrency持续≥20或频繁≥50、undoblks增速远超txncount，表明回滚段头或区分配锁争用；应优先查长事务而非扩容undo，结合v$rollstat（waits/gets＞0.01需警惕）、dba_undo_extents（expired＜20%预示回收阻塞）及v$session+v$transaction交叉验证inactive长事务。
看V$UNDOSTAT里的MAXCONCURRENCY是否持续高企
AWR报告本身不标“undo争用”，但底层数据全来自V$UNDOSTAT。关键不是平均值，而是每10分钟一个快照里的MAXCONCURRENCY——它代表该时段内并发请求回滚段头的峰值次数。
常见错误现象：MAXCONCURRENCY长期≥20，或频繁跳到50+，同时UNDOBLKS增速远超TXNCOUNT（比如事务数涨2倍，Undo块涨5倍），说明事务在抢回滚段头或区分配锁。
- 执行
SELECT BEGIN_TIME, END_TIME, UNDOBLKS, TXNCOUNT, MAXCONCURRENCY FROM V$UNDOSTAT ORDER BY BEGIN_TIME DESC FETCH FIRST 20 ROWS ONLY，盯最近20个快照 -
UNDOBLKS单位是数据库块（通常8KB），不是字节，别误算成MB - 若某段时间
MAXCONCURRENCY持续高，优先查长事务，而不是加Undo文件
查V$ROLLSTAT的WAITS/GETS比值是否异常
V$ROLLSTAT是诊断回滚段级争用的直接视图，每个回滚段一条记录，WAITS和GETS的比值能暴露头块争用程度。
使用场景：当V$UNDOSTAT已提示压力，需定位具体哪个回滚段被卡住；或者AWR中出现undo header等待事件时，必须下钻到这里。
- 运行
SELECT name, waits, gets, ROUND(waits/NULLIF(gets,0),4) "Ratio" FROM v$rollstat a, v$rollname b WHERE a.usn = b.usn - 比值＞0.01（即1%）就值得警惕；＞0.05说明该回滚段头严重争用
-
XACTS为0但WAITS持续上升，大概率是空闲连接挂着未提交，而非活跃事务
结合DBA_UNDO_EXTENTS判断EXPIRED占比是否过低
Undo表空间爆满，往往不是总量不够，而是ACTIVE和UNEXPIRED区块堆积、EXPIRED太少——说明空间回收机制被阻塞，典型表现是EXPIRED占比低于20%。
性能影响：EXPIRED过低会迫使Oracle不断扩展Undo表空间，甚至触发ORA-30036；而盲目扩容只是掩盖问题，不解决根本。
- 执行
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，先查长事务，再考虑调低undo_retention -
UNEXPIRED过高还可能因undo_retention设为86400（24小时）却无自动扩展，此时调低retention比加数据文件更治本
用V$SESSION + V$TRANSACTION交叉验证INACTIVE长事务
V$TRANSACTION.START_TIME只显示事务开始时间，但很多“长事务”其实是应用连接池没设超时，挂在那里没提交——这类事务在V$TRANSACTION里能看到，但在V$SESSION中STATUS是INACTIVE、SQL_ID为空。
容易踩的坑：单靠V$TRANSACTION会漏掉一半问题；只查STATUS = 'ACTIVE'的会话，等于忽略最大隐患源。
- 执行
SELECT s.sid, s.serial#, s.status, s.sql_id, t.start_time, t.xidusn, ROUND(t.used_ublk * tbs.block_size / 1048576, 2) undo_size_mb FROM v$session s, v$transaction t, dba_tablespaces tbs WHERE s.taddr = t.addr AND tbs.tablespace_name = 'UNDOTBS1' - 重点筛
STATUS = 'INACTIVE'且START_TIME早于1小时以上的记录 - 这类会话对应的
SQL_ID为空，得结合DBA_HIST_ACTIVE_SESS_HISTORY反查历史SQL
真实压测或业务高峰期，MAXCONCURRENCY和WAITS/GETS可能同步飙升，但EXPIRED占比却没明显下降——这时候要怀疑底层存储响应延迟是否拖慢了回滚段收缩，不能只盯着数据库参数调。
