undo表空间真实使用率和自动扩展状态需同时检查：先查实际使用率（非dba_free_space单表结果），再查autoextend是否启用；二者缺一不可，否则将引发ora-01555或ora-30036。
查UNDO表空间真实使用率和自动扩展状态
ORA-01555不是参数没设对，而是UNDO空间实际撑不住。先确认两件事：表空间是不是真满了、文件有没有开AUTOEXTEND。
- 查真实使用率（别信
dba_free_space单表结果）：SELECT tablespace_name, ROUND((bytes - free_bytes)/1024/1024) AS used_mb FROM dba_data_files d, (SELECT tablespace_name, NVL(SUM(bytes), 0) free_bytes FROM dba_free_space GROUP BY tablespace_name) f WHERE d.tablespace_name = f.tablespace_name AND d.tablespace_name = (SELECT value FROM v$parameter WHERE name = 'undo_tablespace');
- 查
AUTOEXTEND是否启用：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，必须立刻执行：ALTER DATABASE DATAFILE '/path/to/undotbs01.dbf' AUTOEXTEND ON NEXT 100M MAXSIZE 10G（路径以查询结果为准） -
expstealcount > 0或v$undostat中unexpired占比长期超95%，说明UNDO块正在被强制覆盖——此时调UNDO_RETENTION毫无意义
主库必须同时生效的两个关键操作
ADG备库报ORA-01555，根子永远在主库。只改一个参数等于白改。
-
ALTER SYSTEM SET UNDO_RETENTION = 3600 SCOPE=BOTH——设为v$undostat.maxquerylen的1.5倍以上，不是拍脑袋定3600 -
ALTER TABLESPACE undotbs1 RETENTION GUARANTEE——替换undotbs1为实际UNDO表空间名；没这句，UNDO_RETENTION只是建议，不是保证 - 二者缺一不可，且必须确保UNDO表空间有足够物理空间支撑。开了
RETENTION GUARANTEE但没开AUTOEXTEND，主库会很快报ORA-30036，比ORA-01555更致命
备库侧唯一能做的就是收窄查询
你没法改主库？那就只能从SQL端卡住风险点。长查询时间越久，撞上被覆盖UNDO的概率是指数级上升的。
- 禁用无
WHERE条件的全表扫描，特别是SELECT * FROM big_table这类语句 - 避免硬编码值导致未绑定变量，比如
WHERE id = 123——硬解析+执行计划抖动会拉长一致性读链 - 对已知慢查询，可临时加提示：
/*+ OPT_PARAM('_serial_direct_read' 'never') */，强制走buffer cache读CR块（绕过direct path read跳过UNDO构造） - 查
v$undostat.maxquerylen发现某时段值突增到1800秒，说明有查询跑了30分钟——得立刻定位并优化，而不是等它报错
数据泵/ETL类场景优先分片而非调参
OMS、DWS或expdp导出大表时卡在ORA-01555，本质是单次扫描耗时远超UNDO保留窗口。调参是缓兵之计，切分才是根治。
- 先估算表行数：
SELECT num_rows FROM dba_tables WHERE owner='SCHEMA' AND table_name='T_BIG' - 按主键或
ROWID范围分批拉取，例如每次10万行：SELECT * FROM t_big WHERE id BETWEEN :start_id AND :end_id - 避免用
ROWNUM伪列做分页（会导致全表扫描），优先用索引字段+范围谓词 - LOB字段表导出失败？考虑
expdp加CONTENT=DATA_ONLY跳过元数据锁竞争，或用DBMS_LOB.SUBSTR分段读取
实际修复中最容易被忽略的，是RETENTION GUARANTEE和AUTOEXTEND必须配套落地——单独启用任一者，要么无效，要么引发更严重的空间故障。
