v$undostat 的 maxconcurrency 持续 ≥20 或频繁达 50+ 表明回滚段争用严重，需结合 undoblks/txncount 增速比、dba_undo_extents 中 EXPIRED 区块占比（应≥30%）、v$session/v$transaction 定位 INACTIVE 长事务，并检查 _undo_autotune 是否加剧争用。
查 v$undostat 看 maxconcurrency 是否持续超标
AWR 报告本身不直接标出“回滚段扩展等待”，但 v$undostat 是底层真实反映 Undo 段争用的核心视图。每 10 分钟一个快照，关键不是平均值，而是盯住 maxconcurrency：若长期 ≥ 20 或频繁跳到 50+，说明多个事务在抢回滚段头或区分配锁，_undo_autotune 很可能正在疯狂上下线 segment。
实操建议：
- 运行
SELECT begin_time, end_time, undoblks, txncount, maxconcurrency FROM v$undostat WHERE begin_time > SYSDATE - 1/24 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 联合定位 INACTIVE 长事务
很多“长事务”其实是空闲连接挂着未提交（比如应用连接池没设超时），这类事务在 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#'
确认 _undo_autotune 是否在捣鬼
Oracle 19c 默认开启这个隐含参数，它是 enq: US - contention 的主要推手。当它检测到 Undo 压力，会动态增删 undo segment；但频繁上下线反而加剧争用，尤其在高并发 DML 场景下。
实操建议：
- 检查是否启用：
SHOW PARAMETER _undo_autotune，返回TRUE即开启 - 临时禁用（需重启生效）：
ALTER SYSTEM SET "_undo_autotune"=FALSE SCOPE=SPFILE - 禁用后观察
v$undostat.maxconcurrency是否回落；若仍高，则问题根源在事务行为本身，而非 autotune 干扰
真正棘手的是那种 maxconcurrency 飙升但 nospaceerrcnt 为 0 的情况——说明争用发生在分配阶段，不是空间真不够，而是锁排队太狠。这时候调优重点不在扩容，而在缩短事务生命周期和分散热点回滚段头。
