应查DBA_UNDO_EXTENTS统计UNEXPIRED状态空间占比，若远超ACTIVE（如＞70%）则表明undo_retention设置过长或事务提交不及时；再联合V$SESSION与V$TRANSACTION定位长时间未提交的ACTIVE会话；同时核查V$UNDOSTAT中TUNED_UNDORETENTION是否异常偏高，并确认UNDO表空间数据文件AUTOEXTENSIBLE状态及剩余空间。
查 UNEXPIRED 状态的 undo extent 占用大小
UNDO 表空间里 UNEXPIRED 的 extent 是最常被误判为“可回收但实际占着不放”的部分，尤其当 undo_retention 设置过大（比如几小时甚至几天），而事务又没频繁提交时，这部分空间会持续累积。直接查 dba_undo_extents 最可靠：
SELECT tablespace_name, status, ROUND(SUM(bytes)/1024/1024, 2) mb FROM dba_undo_extents WHERE status = 'UNEXPIRED' GROUP BY tablespace_name, status;- 注意：
status区分ACTIVE、UNEXPIRED、EXPIRED，只有EXPIRED才真正可被覆盖重用 - 如果
UNEXPIRED占比远高于ACTIVE（比如 >70%），说明 retention 时间过长或系统负载低，undo 没被及时覆盖
关联 session 和 SQL 查谁在拖慢 expiration
光看空间不够，得知道哪些会话/SQL 让 undo 一直卡在 UNEXPIRED 状态。关键不是“正在跑的事务”，而是“长时间未提交却还活着”的会话：
SELECT s.sid, s.serial#, s.username, s.status, s.sql_id, t.start_time, t.used_ublk * (SELECT value/1024/1024 FROM v$system_parameter2 WHERE name = 'db_block_size') undo_mb FROM v$transaction t, v$session s WHERE t.ses_addr = s.saddr AND s.status = 'ACTIVE' ORDER BY t.used_ublk DESC;-
start_time如果是几小时甚至几天前，基本就是问题源头；这类会话往往来自长事务、DBLINK 查询、或应用端未 commit 的 JDBC 连接 - 别只盯
sql_id，还要看username和program—— 比如oracle@host (J001)可能是 job，tnslsnr可能是监听器残留连接
对比 v$undostat 的 tuned_undoretention
Oracle 实际执行的 retention 并不总是你设的 undo_retention 参数值，它会根据空间压力动态调整（tuned_undoretention）。这个值偏低说明系统在“拼命保命”，偏高则可能让 UNEXPIRED 堆积：
SELECT TO_CHAR(begin_time, 'HH24:MI') begin, TO_CHAR(end_time, 'HH24:MI') end, tuned_undoretention FROM v$undostat ORDER BY end_time DESC FETCH FIRST 5 ROWS ONLY;- 如果
tuned_undoretention明显高于参数值（比如参数设 900，但视图里长期显示 3600+），说明 undo 空间紧张，Oracle 在强行延长保留时间以避免 ORA-01555 - 这时即使 kill 掉长事务，
UNEXPIRED也不会立刻下降，得等 tuned 值回落 + 新事务覆盖
小心自动扩展关了但文件已满
很多人查了半天 UNEXPIRED，最后发现根本不是 retention 问题，而是 undo 表空间数据文件 AUTOEXTENSIBLE = 'NO' 且已写满：
SELECT file_name, tablespace_name, autoextensible, bytes/1024/1024 cur_mb, maxbytes/1024/1024 max_mb FROM dba_data_files WHERE tablespace_name = (SELECT value FROM v$parameter WHERE name = 'undo_tablespace');- 如果
cur_mb == max_mb且autoextensible = 'NO'，那所有 extent（包括UNEXPIRED）都会被锁死，无法释放 —— 此时扩容或开自动扩展比调 retention 更有效 - 特别注意 RAC 环境下，每个实例可能有独立的 undo 表空间，得逐个查
实际排查时，UNEXPIRED 高往往不是单一原因：可能是长事务 + retention 过高 + 文件不可扩展三者叠加。先确认空间是否真满了，再看谁在 hold，最后才动参数。否则调小 undo_retention 可能引发 ORA-01555，反而更麻烦。
