Oracle 12c并未改进UNDO自动管理机制，仅新增TEMP_UNDO_ENABLED参数实现临时表撤销数据存入临时表空间、不生成REDO、支持ADG备库DML；需COMPATIBLE≥12.0、启用AUM、会话级设置须在创建临时表前执行，且启用后不可动态关闭。
UNDO 管理在 Oracle 12c 中并没有“更自动化”——它和 9i、10g、11g 用的是同一套自动撤销管理（AUM）机制，**核心逻辑没变，只是新增了对临时表的专项优化**。
真正变化的是：Oracle 12c 引入了 TEMP_UNDO_ENABLED 参数，让临时表的撤销数据可以脱离传统 UNDO 表空间，改存到临时表空间。这不是对“撤销段本身”的自动化升级，而是对特定场景（GLOBAL TEMPORARY TABLE）的路径分流。
为什么有人觉得“更自动化”？
因为启用 temp_undo_enabled 后，以下几件事不再需要 dba 干预：
- 临时表 DML 不再争抢主
UNDO表空间空间 - 临时表操作不生成 REDO（原先会写入
UNDO表空间，进而触发 REDO 记录） - 物理备库（ADG）或只读数据库也能执行临时表 DML —— 原先会报
ORA-01664或直接失败
TEMP_UNDO_ENABLED 怎么开才生效？
这个参数必须满足三个前提，缺一不可：
-
COMPATIBLE参数 ≥'12.0.0'（查v$parameter确认） - 数据库启用了自动撤销管理（
undo_management = 'AUTO'） - 会话级设置需在创建临时表 之前 执行；系统级设置需重启会话才对新会话生效
错误示例：ALTER SESSION SET TEMP_UNDO_ENABLED = TRUE; 在插入临时表之后执行，无效 —— 临时 undo 已按旧路径分配，无法中途切换。
临时 undo 和常规 undo 的监控完全分离
常规 undo 活动看 v$undostat，而临时 undo 只能查 v$tempundostat。如果没授过权限，普通用户查不到后者：
GRANT SELECT ON v_$tempundostat TO your_user;
注意：v_$tempundostat 是视图别名，实际授权对象是 v_$tempundostat（带下划线和美元符），不是 v$tempundostat。
容易被忽略的硬限制
TEMP_UNDO_ENABLED 对普通表、分区表、物化视图等一切非临时对象完全无影响；它只作用于 GLOBAL TEMPORARY TABLE。而且一旦会话中产生了临时 undo，该会话后续所有临时表操作都会继续走临时表空间路径，哪怕你再设成 FALSE 也切不回去 —— 必须断开重连。
