首先需要明确：在所有系统视图中，DBA_UNDO_EXTENTS 是唯一能够实时掌握 Undo 段物理状态的视图，没有替代品。它以 extent 粒度详细记录每个回滚段区域的当前状态——ACTIVE、UNEXPIRED、EXPIRED——而非事务级或会话级的抽象汇总。不要被名称误导，它的作用远不止查看 extent 数量，核心在于实时映射空间的可用性。
查看状态分布：必须用 DBA_UNDO_EXTENTS，而非 V$ROLLSTAT 或 V$UNDOSTAT
为什么一定要使用这个视图？因为另外两个常用视图各自存在盲区：
V$ROLLSTAT仅提供当前活动回滚段的统计摘要（如RSSIZE、WRITES等），无法区分状态，更不会揭示UNEXPIRED与EXPIRED的比例。V$UNDOSTAT是一个历史滚动窗口，默认保留最近 4 天、每 10 分钟一条的记录。适合观察趋势，但无法定位当前某块空间是否能够回收。DBA_UNDO_EXTENTS则直接回答了“此刻哪些空间正被占用、哪些仅暂未过期、哪些已可立即重用”这一核心问题。
下面是一个典型的查询示例：
SELECT status, COUNT(*) cnt, ROUND(SUM(bytes)/1024/1024, 2) "MB" FROM dba_undo_extents WHERE tablespace_name = 'UNDOTBS1' GROUP BY status ORDER BY status;
结果中三组状态的含义非常清晰：ACTIVE 表示有活跃的未提交事务正在写入；UNEXPIRED 表示事务已提交但尚未超过 undo_retention 的设置值；EXPIRED 才是真正空闲、可立即被新事务重用的空间。
为何 UNEXPIRED 占比高不代表真正缺空间？
这是一个常见的误区。Oracle 默认将 UNEXPIRED 计入“已使用”，导致很多监控脚本在发现使用率超过 95% 时便触发警报。但在实际业务中，只要 EXPIRED 不为零，DML 操作就不会报 ORA-30036 错误。不少 DBA 看到这个数字就急于扩容，其实完全不必。
真正的判断逻辑是：EXPIRED 为 0 且 ACTIVE 持续增长 → 这才是真正的危险信号；如果 UNEXPIRED 占比虽高但 EXPIRED > 0，那很可能只是长查询或大型事务拖慢了过期节奏，并非空间不足。
那么，常见诱因是什么？往往是设置了过大的 undo_retention（例如 24 小时），但 UNDO 表空间没有开启自动扩展，导致系统被迫将大量空间锁定在 UNEXPIRED 状态。这种情况下，空间本身足够，只是被“锁住”了。
结合 V$UNDOSTAT 查看自动调优是否失控
当自动调优功能开启时（_undo_autotune=TRUE，Oracle 10g+ 默认行为），TUNED_UNDORETENTION 可能会被系统自动拉高，远超你设定的 undo_retention 参数值。如果你发现 DBA_UNDO_EXTENTS 中的 UNEXPIRED 持续膨胀，应该查询什么？直接运行以下 SQL：
SELECT MAX(tuned_undoretention) FROM v$undostat WHERE begin_time > SYSDATE - 1/24;
如果返回值大于 3600（1 小时），再对比当前的 undo_retention 设置值。差值越大，说明系统判定“需要更长时间保留”的意愿越强，这通常意味着存在运行时间很长的查询（如报表、ETL 等任务）在拖慢过时进程。
此时强制调小 undo_retention 是无效的，因为自动调优会覆盖它。解决方法有两种：要么关闭自动调优（ALTER SYSTEM SET "_undo_autotune"=FALSE），要么优化长查询，否则 UNDO 表空间只会不断膨胀。
最后请牢记：真正的瓶颈往往不在于表空间大小，而在于 EXPIRED 是否归零。一旦 EXPIRED 为零，哪怕表空间显示还有 20%“空闲”，新事务也会立即失败。这才是真正的红线。
