应查v$undostat而非仅awr报告，重点监控maxconcurrency是否持续≥20或频繁超50，结合undoblks与txncount增速比、dba_undo_extents中expired占比（应30%~60%）、inactive伪长事务及_max_undo_retention实际有效性，综合判断undo争用与ora-01555根因。
查 V$UNDOSTAT 而不是只看 AWR 报告里的“Summary”
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，盯最近 20 个快照 - 若某时段
MAXCONCURRENCY高企，且UNDOBLKS增速远超TXNCOUNT（比如事务数涨 2 倍，Undo 块涨 5 倍），大概率存在未提交或空闲挂起的长事务 -
UNDOBLKS单位是数据库块（通常 8KB），不是字节，别误算成 MB
看 DBA_UNDO_EXTENTS 的 STATUS 分布，别急着加数据文件
Undo 表空间爆满，90% 的情况不是总量不够，而是 ACTIVE + UNEXPIRED 区块堆积、EXPIRED 接近 0。正常应有 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 比加数据文件更治本
定位 INACTIVE 状态的“伪长事务”，V$TRANSACTION.START_TIME 会骗人
V$TRANSACTION.START_TIME 显示的是事务开始时间，但很多“长事务”其实是应用连接池没设超时，连接挂着、事务已空闲（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.taddr = t.addr(+) AND s.status = 'INACTIVE' AND t.start_time - 重点关注
used_ublk > 1000且status = 'INACTIVE'的会话——它们占着 Undo 空间却不干活 - 确认后可 kill：
ALTER SYSTEM KILL SESSION 'sid,serial#' IMMEDIATE
ORA-01555 不是参数没设够，是空间没撑住最长查询
_UNDO_RETENTION 只是建议值，Oracle 不保证保留这么久。真正决定 undo 是否被覆盖的，是 undo 表空间是否有空闲空间。空间吃紧时，哪怕刚过 1 秒，旧 undo 也会被覆盖，导致 ORA-01555。
实操建议：
- 先确认自动扩展：
SELECT file_name, autoextensible, maxbytes FROM dba_data_files WHERE tablespace_name = 'UNDOTBS1'；如果autoextensible = 'NO'且空闲率接近 0，根源就在这儿 - 查当前最长运行查询：
SELECT sid, serial#, username, sql_id, start_time, ROUND(elapsed_seconds/60, 1) mins FROM v$session WHERE status = 'ACTIVE' AND sql_id IS NOT NULL ORDER BY elapsed_seconds DESC FETCH FIRST 5 ROWS ONLY - 紧盯
V$UNDOSTAT.MAXQUERYLEN：它反映过去 10 分钟内最长查询秒数；若持续 >undo_retention，说明参数已失效
最易被忽略的一点：500GB 的 Undo 表空间照样报 ORA-01555——因为那条跑 20 分钟的报表 SQL，要求 undo 至少活 20 分钟，而表空间里大量 UNEXPIRED 块被卡死无法释放，EXPIRED 几乎为零。这时候扩空间没用，得先松开“卡住”的事务或调低 retention。
