ORA-01555本质是查询所需的一致性读镜像被覆盖，主因是UNDO_RETENTION与实际空间不足的矛盾；需优先扩容UNDO表空间并启用AUTOEXTEND，再合理调参，对长查询应分片处理而非盲目延长保留时间。
ora-01555 错误本质是 undo 数据被覆盖，不是“配置错了”，而是当前 undo 表空间容量和保留时间无法支撑长事务或长查询。直接调高 undo_retention 不一定有效，必须同步检查 undo 表空间实际使用情况。
查当前 undo 配置和实际负载
先确认系统真实压力，而不是只看参数值：
-
show parameter undo查undo_management（必须为AUTO）、undo_retention和undo_tablespace - 执行
SELECT tablespace_name, SUM(bytes)/1024/1024 AS size_mb FROM dba_data_files WHERE tablespace_name LIKE 'UNDOTBS%' GROUP BY tablespace_name看 undo 表空间总大小 - 查历史最长查询耗时：
SELECT MAX(maxquerylen) AS max_sec FROM v$undostat—— 这个值才是undo_retention的硬下限 - 查近期 undo 使用率：
SELECT TO_CHAR(BEGIN_TIME, 'HH24:MI'), (UNDOTSN / MAXCONCURRENCY) * 100 AS pct FROM v$undostat ORDER BY BEGIN_TIME DESC FETCH FIRST 10 ROWS ONLY
调整 undo_retention 参数的注意事项
这个参数只是“建议保留时长”，数据库是否真能遵守，取决于空间是否充足：
- 如果 undo 表空间
AUTOEXTEND ON且磁盘有余量，设高点（比如ALTER SYSTEM SET undo_retention = 7200 SCOPE=BOTH）数据库会优先扩展文件，而非覆盖未过期 undo - 如果 undo 表空间
AUTOEXTEND OFF或已到MAXSIZE，再高的undo_retention也无效，此时覆盖行为照常发生 - Oracle 10gR2+ 会动态调整实际保留时间，但前提是表空间够大；它不会突破你设的
undo_retention上限，但可能远低于它
扩大 undo 表空间的实际操作
加空间比调参数更直接有效，尤其当 v$undostat 显示使用率长期 >70%：
- 确认当前 undo 表空间名：
show parameter undo_tablespace - 添加新数据文件（推荐）：
ALTER TABLESPACE undotbs1 ADD DATAFILE '/u01/oradata/DB/undotbs02.dbf' SIZE 2G AUTOEXTEND ON NEXT 512M MAXSIZE 24G - 不建议仅 resize 原文件，因 Oracle 对单个 undo 文件的并发写入有内部限制
- 若原表空间已满且无法扩盘，可建新 undo 表空间并切换：
CREATE UNDO TABLESPACE undotbs2 DATAFILE '/path/undo02.dbf' SIZE 4G，再ALTER SYSTEM SET undo_tablespace = undotbs2
容易被忽略的关键点
很多 DBA 卡在“明明调了参数却没用”，问题往往出在这些地方：
- 应用端批量更新中夹杂
COMMIT—— 每次 commit 后该事务的 undo 就可能被复用，导致后续长查询看到“快照过旧”，这不是 undo 配置问题，是代码逻辑问题 -
v$undostat.maxquerylen是过去 24 小时内的最大值，但业务高峰可能更集中；需结合监控工具看实时长查询，不能只依赖历史统计 - 闪回查询（
AS OF TIMESTAMP）需要的 undo 保留时间，远超普通查询；若业务依赖闪回，undo_retention至少设为 24 小时，且表空间必须预留足够余量 - OLTP 系统通常设
undo_retention=900（15 分钟）够用，但一旦跑报表或 ETL，就得临时调高，否则必然报错
