ORA-01555 错误主因是 undo 表空间不足而非 _UNDO_RETENTION 设置过小；该参数仅为建议值，实际保留时长由空闲空间决定，空间紧张时旧 undo 会被强制覆盖。
ORA-01555 错误到底是不是因为 _UNDO_RETENTION 没设够？
不是。设再大也压不住——_undo_retention 只是“建议值”，oracle 不保证保留这么久。真正决定 undo 是否被覆盖的，是 undo 表空间是否有空闲空间。当空间吃紧，哪怕还没到 _undo_retention 秒数，旧 undo 也会被主动覆盖，导致查询报 ora-01555: snapshot too old。
常见错误现象：
– 长查询（比如报表、导出）稳定复现 ORA-01555
– 查 V$UNDOSTAT 发现 MAXQUERYLEN 远小于当前 _UNDO_RETENTION
– 调大 _UNDO_RETENTION 后问题照旧
- 先确认 undo 表空间是否自动扩展：
SELECT file_name, autoextensible, maxbytes FROM dba_data_files WHERE tablespace_name = 'UNDOTBS1'; - 检查实际可用空间：
SELECT tablespace_name, round((free_space/total_space)*100, 2) pct_free FROM (SELECT tablespace_name, SUM(bytes) total_space FROM dba_data_files GROUP BY tablespace_name), (SELECT tablespace_name, SUM(bytes) free_space FROM dba_free_space GROUP BY tablespace_name) WHERE total_space.tablespace_name = free_space.tablespace_name AND tablespace_name = 'UNDOTBS1'; - 如果
autoextensible是NO，且pct_free接近 0，问题根源就在这儿，不是参数没调够
怎么查清楚哪个查询在“拖慢” undo 生命周期？
关键不是看 _UNDO_RETENTION 设多少，而是看系统里最长的活跃查询到底卡了多久——它决定了 undo 至少得活多久不被覆盖。
使用场景：上线新报表后突然频发 ORA-01555；或 DBA 收到告警说 UNDOBLKS 突增
- 查当前最长运行查询：
SELECT sid, serial#, username, sql_id, start_time, ROUND(elapsed_seconds/60, 1) mins FROM v$session WHERE status = 'ACTIVE' AND sql_id IS NOT NULL ORDER BY elapsed_seconds DESC FETCH FIRST 5 ROWS ONLY; - 反查该 SQL 的完整文本：
SELECT sql_text FROM v$sql WHERE sql_id = 'xxx'; - 重点盯
V$UNDOSTAT.MAXQUERYLEN：它反映过去 10 分钟内最长查询时长（秒），若持续 >_UNDO_RETENTION，说明参数已失效
_UNDO_RETENTION 参数值该设多少才合理？
设太高浪费空间，设太低白设。合理值 ≈ 系统中最长业务查询的典型执行时间 × 1.5，并确保 undo 表空间能撑住这个量级的活跃 undo 数据。
参数差异：
– 动态修改（无需重启）：ALTER SYSTEM SET UNDO_RETENTION = 3600;
– 若启用了 RETENTION GUARANTEE（不推荐默认开），Oracle 才真会强制保留，但可能直接导致 DML 报 ORA-30036
- 先跑一周，每天查一次
V$UNDOSTAT中的MAXQUERYLEN和UNDOBLKS峰值 - 取
MAXQUERYLEN的 P95 值（比如 1800 秒），再乘以 1.5 → 得到 2700，即设为 2700 秒较稳妥 - 别盲目设成 86400（24 小时）：undo 表空间会迅速膨胀，尤其 OLTP 系统事务密集
- 设完立刻观察
V$UNDOSTAT.TUNED_UNDORETENTION：这是 Oracle 实际“听进去”的值，它可能比你设的小
为什么加了 RETENTION GUARANTEE 反而出问题？
它让 Oracle 在空间压力下宁可拒绝 DML，也不覆盖未过期 undo。结果就是：原本只是偶尔 ORA-01555，现在变成批量 ORA-30036: unable to extend segment，业务写入直接卡死。
性能影响显著：
– 开启后 undo 空间利用率飙升，自动扩展更频繁
– 高并发更新场景下，争用加剧，undo header 等待上升
- 只应在极少数场景临时启用：比如必须保证某条关键历史查询绝对不报 ORA-01555，且你已确认 undo 表空间有足够余量
- 启用命令：
ALTER TABLESPACE undotbs1 RETENTION GUARANTEE;（注意是表空间级，不是参数） - 务必配监控：一旦
dba_tablespaces.status出现OFFLINE或dba_data_files.maxbytes触顶，立即关掉
最常被忽略的一点：很多人以为调大 _UNDO_RETENTION 就万事大吉，却从不查 V$UNDOSTAT.TUNED_UNDORETENTION —— 它才是 Oracle 真正执行的值，而它由空间压力实时调控，根本不受你手动设置完全控制。
