unexpired状态的undo段不能被覆盖，是因为oracle优先保障读一致性而非空间释放，其实际保留时长由动态计算的tuned_undoretention决定（非手动设置的undo_retention），且在autoextensible=no时更趋保守，导致大量unexpired长期滞留。
UNEXPIRED状态的undo段为什么不能被覆盖
UNEXPIRED不是“锁死”，而是Oracle在保留策略和空间分配逻辑双重约束下的主动规避行为。它表示事务已提交，但尚未满足当前生效的保留时长要求，因此不能被新事务直接覆盖——哪怕表空间快满了，Oracle也优先保一致性读，而不是立刻腾空间。
关键点在于：真正起作用的不是你设的undo_retention，而是动态计算出的TUNED_UNDORETENTION（查v$undostat）。11g默认开启隐含参数_undo_autotune=true，它会根据历史最长查询、空间使用率等自动拉高保留时间，常达几小时甚至更久。你执行alter system set undo_retention = 900基本无效。
- 查当前实际生效值：
SELECT MAX(TUNED_UNDORETENTION) FROM v$undostat;，若返回值远大于900，就是_undo_autotune在主导 -
DBA_UNDO_EXTENTS.STATUS里大量UNEXPIRED，说明这些块“理论上可覆盖”，但Oracle算法判定“现在还不能动” - 即使
v$rollstat.XACTS = 0（无活跃事务），只要UNEXPIRED堆积多，物理空间就无法回收重用
数据文件不自动扩展会让UNEXPIRED更顽固
当undo表空间的数据文件AUTOEXTENSIBLE = 'NO'时，Oracle会进入保守模式：宁可延长保留时间、撑满空间，也不愿冒险提前覆盖undo块引发ORA-01555。这不是bug，是设计取舍——它把“避免快照过旧”放在“节省空间”之前。
典型表现是：dba_data_files.BYTES几乎不变，但dba_undo_extents里几百个UNEXPIRED长期不转EXPIRED；同时v$undostat.NOSPACEERRCNT可能缓慢上升，说明系统已在边缘试探。
- 确认是否禁用自动扩展：
SELECT file_name, autoextensible, maxbytes/1024/1024 AS max_mb FROM dba_data_files WHERE tablespace_name = (SELECT value FROM v$parameter WHERE name = 'undo_tablespace'); - 如果
autoextensible为NO，且used_percent > 95%（查DBA_TABLESPACE_USAGE_METRICS），那UNEXPIRED堆积就是结果，不是原因 - 此时调大
undo_retention只会雪上加霜：进一步延缓UNEXPIRED → EXPIRED转化，加速空间耗尽
覆盖UNEXPIRED的唯一可行路径是让它们“自然过期”
Oracle不会主动压缩或强制清理UNEXPIRED块。它的回收依赖两个条件同时满足：一是时间上超过生效的保留阈值（即TUNED_UNDORETENTION），二是对应undo segment处于OFFLINE状态（无事务使用）。SMON进程只对OFFLINE段里的EXPIRED块做批量回收，对UNEXPIRED块完全不碰。
所以你看到select status, count(*) from dba_undo_extents group by status返回大量UNEXPIRED，不是SMON失职，是它根本没到干活的时候。
- 关闭自动调优最直接：
alter system set "_undo_autotune" = false scope=spfile;，重启后undo_retention才真正生效，UNEXPIRED会随设定时间自然转为EXPIRED - 切换到新undo表空间见效更快，但需停业务或协调PDB（12c+ LOCAL UNDO场景）
- 别指望
ALTER TABLESPACE ... SHRINK SPACE——undo表空间不支持shrink，物理文件大小不会自动缩小
ORA-01555和ORA-30036其实暴露的是同一个底层问题
这两个错误看似不同，根源都是UNEXPIRED块无法被及时释放导致的空间僵局：ORA-01555是长查询需要的undo块已被覆盖（因空间不足被迫覆盖UNEXPIRED），ORA-30036是新事务连分配新extent都失败（因UNEXPIRED占满且无法扩展）。它们共同指向一个事实：undo空间管理已脱离预期轨道。
最危险的信号不是报错本身，而是V$UNDOSTAT.MAXQUERYLEN持续大于你设的undo_retention，且NOSPACEERRCNT非零——这说明Oracle正在高频触发“强制覆盖UNEXPIRED”的兜底逻辑，一致性读风险已实质性升高。
- 紧急处理优先级：先开
AUTOEXTEND（比RESIZE更稳），再关_undo_autotune，最后观察DBA_UNDO_EXTENTS中UNEXPIRED数量是否逐日下降 - 不要依赖
DBA_FREE_SPACE判断可用空间——undo段分配需要连续extent，碎片化空闲块对undo无意义 - 长期来看，
UNEXPIRED是否能快速流转，取决于你是否切断_undo_autotune与AUTOEXTENSIBLE = NO的负向组合
