oracle自动undo管理（aum）需设置undo_management=auto并指定有效在线undo表空间；手动undo已弃用，因不可维护且不支持闪回等功能；undo_retention为软限制，应据v$undostat调优；undo表空间不支持shrink，仅可resize。
oracle自动undo管理（aum）怎么启用
默认安装的 oracle 10g 及以后版本基本都用 aum，但如果你是从老库升级或手动建库，可能还在用手动 undo。确认当前模式：select value from v$parameter where name = 'undo_management' —— 返回 auto 才是 aum。
启用 AUM 需两步：一是设置参数 undo_management=auto（必须在 spfile 或 pfile 中，重启生效），二是确保存在一个在线的 UNDO 表空间，比如 UNDOTBS1。没有的话会报错 ORA-01552: cannot use system rollback segment for non-system tablespace。
-
undo_tablespace参数要显式指定表空间名，不能留空；如果指定的表空间不存在或离线，实例启动失败 - 新建
UNDO表空间时用CREATE UNDO TABLESPACE ... DATAFILE ...，别用EXTENT MANAGEMENT LOCAL AUTOALLOCATE—— 这是强制的，不加会报错 - AUM 下禁止对
ROLLBACK SEGMENT做任何ALTER ROLLBACK SEGMENT ... ONLINE/OFFLINE操作，否则报ORA-01550: cannot drop or alter system rollback segment
手动管理Undo为什么现在基本不用了
手动管理靠 DBA 显式创建、上线、下线回滚段（ROLLBACK SEGMENT），还要在事务里用 SET TRANSACTION USE ROLLBACK SEGMENT 指定——这在 OLTP 场景根本不可维护。
最直接的问题是：并发高时容易出现 ORA-01555: snapshot too old，因为回滚段大小和重用策略全靠人工估算；而 AUM 由 SMON 自动收缩/扩展 undo 数据块，并配合 undo_retention 参数做保留时间控制，更贴合实际负载。
- 手动模式下，
undo_retention参数完全无效，回滚段一旦被覆盖就无法回退 - 无法支持闪回查询（
AS OF TIMESTAMP）、闪回事务（FLASHBACK_TRANSACTION_QUERY）等依赖一致性读的功能 - Oracle 12c 起已标记手动 Undo 为 deprecated，19c 文档明确说“not supported for new deployments”
undo_retention 设多少才不丢数据
undo_retention 不是硬保证，只是“尽量保留 X 秒”，实际能否撑住取决于 undo 表空间大小和写入压力。设太高但空间不够，SMON 仍会覆盖旧 undo；设太低，ORA-01555 风险陡增。
查最近一小时最长查询耗时：SELECT MAX(ceil((end_time - begin_time) * 24 * 60 * 60)) FROM v$undostat，结果乘以 1.5 是较稳妥的起点。再结合 v$undostat 的 UNXPSTEALCNT（被迫提前覆盖次数）监控是否频繁触发。
- 如果
UNXPSTEALCNT > 0，说明 retention 没守住，优先扩容 undo 表空间，而不是盲目调高undo_retention -
RETENTION GUARANTEE可以强制保留（建表空间时加），但会导致 DML 失败而非覆盖 undo，只适合极少数合规场景 - 注意单位是秒，不是分钟或小时 —— 写成
undo_retention=3600是 1 小时，=60就只有 1 分钟
undo表空间能像普通表空间一样 shrink 吗
不能直接 SHRINK SPACE。Undo 表空间的数据文件只能通过 RESIZE 缩小，且目标大小不能小于当前已使用空间（dba_data_files.bytes - dba_free_space.bytes）。
真正安全缩容分三步：先确认无长事务（SELECT * FROM v$transaction WHERE start_time ），再手工切换到新小表空间（<code>ALTER SYSTEM SET undo_tablespace=...;），最后删掉旧表空间。中间若误删正在用的 undo 表空间，实例会 hang 住。
- 别信 “alter database datafile ... resize” 能直接压到 100M —— 如果 undo block 还在活跃链上，会报
ORA-03297: file contains used data beyond requested RESIZE value -
DBA_HIST_UNDOSTAT比v$undostat更适合看历史峰值，避免按瞬时值误判容量 - Oracle 12c+ 支持 online resize，但 resize 过程中 DML 不受影响，仅 DDL 类操作可能短暂等待
undo 管理真正的难点不在开关或参数，而在理解“保留时间”和“物理空间”之间没有绝对绑定关系 —— 它是个动态权衡，得靠 v$undostat 和业务特征一起看，光调参数没用。
