UNDO_MANAGEMENT=MANUAL时CREATE UNDO TABLESPACE报错，因手动模式仅支持回滚段，不识别该语法，会触发ORA-02198；须先设undo_management=AUTO并重启实例。
UNDO_MANAGEMENT=MANUAL 时为什么 CREATE UNDO TABLESPACE 会报错
因为手动管理模式下，oracle 不允许创建或使用 undo 表空间——它只认回滚段（rollback segment），而 create undo tablespace 是自动管理模式下的语法。此时执行会直接报 ora-02198: no such option 或类似错误。
实操建议：
- 确认当前模式：
SHOW PARAMETER undo_management，若返回MANUAL，必须先切到自动模式 - 切换前需确保已有回滚段未被使用：
SELECT segment_name, status FROM dba_rollback_segs;，状态不能是ONLINE - 修改参数需重启实例：
ALTER SYSTEM SET undo_management=AUTO SCOPE=SPFILE;，然后SHUTDOWN IMMEDIATE+STARTUP
创建 undo 表空间时 DATAFILE 路径和大小怎么设才稳妥
undo 表空间不是“越大越好”，也不是“随便指定路径就行”。它直接影响事务回滚、闪回查询、一致性读的稳定性。
实操建议：
-
DATAFILE路径必须是数据库能写入的位置，且用户（如 oracle）有权限；避免用/tmp或 NFS 挂载点（IO 不稳定易触发ORA-01555） - 初始大小建议 ≥ 200MB，小业务可设
AUTOEXTEND ON NEXT 100M MAXSIZE 2G；高并发 OLTP 环境建议预分配 1–2GB，关掉自动扩展便于监控增长趋势 - 不要复用已有数据文件：
CREATE UNDO TABLESPACE undotbs2 DATAFILE '/u01/oradata/db/undotbs02.dbf' SIZE 500M;—— 文件名必须唯一，否则报ORA-01119
为什么设置了 UNDO_TABLESPACE 但新事务仍用旧表空间
常见现象是修改了 undo_tablespace 参数后，SELECT tablespace_name FROM dba_rollback_segs; 显示的仍是老表空间里的回滚段，新事务也继续往里写。
原因和对策：
- 参数生效需实例重启（
SCOPE=SPFILE）或在线重置（ALTER SYSTEM SET undo_tablespace='UNDOTBS2' SCOPE=BOTH;），但仅此不够 - 旧 undo 表空间里的回滚段必须全部
OFFLINE，否则 Oracle 会优先复用它们；执行：ALTER ROLLBACK SEGMENT <name> OFFLINE;（对系统自建的SYSTEM回滚段无效，需等其空闲） - 检查是否还有活动事务占用旧空间：
SELECT usn, state, undoblockstotal, undoblocksdone FROM v$rollstat;，state 为PENDING OFFLINE表示正在等待清理
UNDO_RETENTION 设太高反而导致空间不足和频繁报错
UNDO_RETENTION 不是“保证保留时间”，而是“尽量保留多久”。当 undo 表空间满时，Oracle 会覆盖未过期的 undo 数据，除非启用了 RETENTION GUARANTEE（不推荐生产环境启用）。
典型问题：
- 设成 36000 秒（10 小时）但表空间只有 500MB，很快触发
ORA-30036: unable to extend segment - 长查询报
ORA-01555: snapshot too old，未必是 retention 不够，更可能是 undo 写入太猛或空间碎片化 - 建议值参考：
SELECT MAX(maxquerylen) FROM v$undostat;，取最近 1 小时最大值 × 1.5；OLAP 类场景可设 7200–14400，OLTP 通常 900–1800 足够
真正关键的是监控：v$undostat 中的 unxpstealcnt（被迫覆盖未过期块次数）> 0 就说明 retention 和空间不匹配。
