Oracle 10g起禁用手动添加回滚段，UNDO争用须通过扩容UNDO表空间、合理设置undo_retention、优化长事务等自动管理模式手段解决。
Oracle 10g 及以后版本不能手动添加回滚段（rollback segment），UNDO 空间争用严重时，必须通过调整 UNDO 表空间本身来解决，而非“添加回滚段”。
这是关键前提：自 Oracle 9i 起启用自动撤销管理（UNDO_MANAGEMENT=AUTO）后，传统回滚段（ROLLBACK SEGMENT）已被废弃；10g 开始彻底移除手工创建/管理回滚段的能力。所谓“添加回滚段”，实际是误用旧术语，真实目标应是提升 UNDO 表空间的并发承载能力。
确认当前使用的是自动撤销管理模式
执行以下查询，验证是否处于现代管理模式：
SELECT name, value FROM v$parameter WHERE name IN ('undo_management', 'undo_tablespace');必须同时满足：
-
undo_management值为AUTO（不是MANUAL） -
undo_tablespace指向一个有效的、状态为ONLINE的撤销表空间（如UNDOTBS1）
若发现 undo_management=MANUAL，说明数据库仍运行在极老旧兼容模式下——这不是常规运维场景，需先评估升级路径，而非直接操作回滚段。
UNDO 空间争用的本质是资源不足或配置失当
争用通常表现为：enq: US - contention 等待事件高发、大量事务因 ORA-01555（snapshot too old）失败、v$undostat 中 unxpstealcnt 或 ssolderrcnt 持续非零。根本原因不是“段不够”，而是：
- UNDO 表空间物理空间不足（数据文件已满或未启用
AUTOEXTEND） -
undo_retention设置过高，导致旧 undo 数据被强制保留过久，挤占可用空间 - 长事务（如未提交的 DML、大批次更新）长期占用大量 undo 段，阻塞其他事务复用空间
- UNDO 表空间数据文件 I/O 性能瓶颈（尤其在单文件、小条带、无 ASM 分布的场景）
此时“添加回滚段”毫无意义——Oracle 自动按需分配和管理 undo 段（_SYSSMU*），你无法控制其数量或绑定关系。
真正有效的应对措施
针对争用，应聚焦于表空间级扩容与参数协同优化：
- 检查并扩容 UNDO 表空间数据文件：
ALTER DATABASE DATAFILE '/path/to/undotbs01.dbf' AUTOEXTEND ON NEXT 512M MAXSIZE 32G;
或新增文件：ALTER TABLESPACE undotbs1 ADD DATAFILE '/path/to/undotbs1_02.dbf' SIZE 2G;
- 根据业务最长事务时间合理设置
undo_retention（单位秒），避免盲目设大：ALTER SYSTEM SET undo_retention = 3600 SCOPE=BOTH;
过高值会导致空间浪费和争用加剧 - 确认
retention guarantee未被意外启用（ALTER TABLESPACE undotbs1 RETENTION GUARANTEE），该特性会完全禁止 Oracle 覆盖未达 retention 时间的 undo，极易引发空间耗尽 - 紧急情况下可临时切换至更大容量的新 UNDO 表空间（如
undotbs2），再安全删除旧表空间（需确保所有原段已OFFLINE）
最后强调：UNDO 表空间的健康不取决于“回滚段数量”，而取决于空间余量、保留策略与事务行为的匹配度。任何试图绕过自动管理去“手工加段”的操作，要么失败（报 ORA-01438 或权限拒绝），要么引入不可控风险。真正的运维重点，永远是监控 v$undostat、识别长事务、按需扩空间、审慎调参数。
