dba_undo_extents是唯一能实时反映undo段物理状态（active/unexpired/expired）并精准判断空间可重用性的视图，它按extent粒度揭示当前哪些空间正被占用、哪些暂未过期、哪些已可立即重用，而非仅提供事务或历史趋势摘要。
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不为 0，DML 就不会报ORA-30036 - 关键判断逻辑是：
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持续膨胀，立刻查：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 是否归零——一旦归零，哪怕表空间还有 20% “空闲”，新事务也会立即失败。
