RAC中UNDO表空间扩容须逐实例操作：先查各节点绑定的UNDO表空间名及状态，确认裸设备/ASM路径全节点可见且权限一致，LOCAL模式下须分别对UNDOTBS1、UNDOTBS2等独立添加数据文件，扩容后需验证回滚段全OFFLINE再删除旧表空间。
不能直接在rac所有节点上并行执行 alter database 扩容语句，必须确认当前实例归属、裸设备/asm路径可见性、以及undo表空间是否为local模式——否则扩容会失败或只生效于单节点。
查清每个节点实际使用的UNDO表空间名和状态
RAC中各实例可能使用不同UNDO表空间（如UNDOTBS1对应节点1，UNDOTBS2对应节点2），不能默认所有节点共用一个。先连到每个实例分别查：
-
show parameter undo_tablespace—— 看当前实例绑定的是哪个表空间 -
select tablespace_name, status from dba_tablespaces where contents = 'UNDO'—— 确认表空间是否ONLINE -
select file_name, bytes/1024/1024/1024 GB from dba_data_files where tablespace_name like 'UNDOTBS%'—— 查各节点下该表空间实际挂载的数据文件路径和大小
特别注意：如果返回为空，说明该实例没加载这个表空间，别对着空名字硬扩。
裸设备或ASM路径必须对所有节点可见且权限一致
在AIX/Linux RAC裸设备场景（如/dev/rrac_undo1_raw_1），扩容前必须确保：
- 该设备在两个节点上都存在，且属主是
oracle:dba（ls -l /dev/rrac_undo*验证） - HA集群已同步该设备（如HACMP需
clmgr add dev或等效操作） - 若用ASM，
select name, total_mb, free_mb from v$asm_diskgroup要确认对应磁盘组有足够空闲空间
常见错误：只在节点1上创建了裸设备，节点2看不到，导致ALTER TABLESPACE ... ADD DATAFILE 报 ORA-01119 或 ORA-17502。
LOCAL UNDO模式下，必须逐个实例单独扩容
Oracle 12.2+ 默认启用LOCAL UNDO（undo_management=auto + undo_tablespace per PDB/instance），这意味着：
- 不能用
ALTER SYSTEM SET undo_tablespace=...全局切换来“绕开”扩容 - 每个实例的UNDO表空间要独立加数据文件：
ALTER TABLESPACE UNDOTBS1 ADD DATAFILE '/path/to/file' SIZE 4096M - 如果误对
UNDOTBS2执行了针对UNDOTBS1的扩容语句，会报ORA-00959（表空间不存在）
切记：RAC不是单机，UNDOTBS1 和 UNDOTBS2 是逻辑隔离的，哪怕物理文件路径相同，也不能混用。
扩容后务必检查UNDO段状态再删旧文件
加完数据文件只是第一步。真正卡住生产环境的是后续清理——尤其删除原UNDO表空间时：
- 用
select usn, xacts, status from v$rollstat确认所有回滚段STATUS为OFFLINE，不能有ACTIVE或PENDING OFFLINE - 用
select username, sql_id from gv$transaction t, gv$session s where s.taddr = t.addr查是否有长事务未提交 - 删除表空间前必须执行
drop tablespace undotbs1 including contents and datafiles，and datafiles不能漏，否则OS层文件残留
最容易被忽略的是：即使v$rollstat 显示全OFFLINE，也可能有隐式事务（比如物化视图刷新、AQ队列消费）仍在引用旧段——这类情况需要结合gv$undostat 的maxquerylen 和unxpstealcnt 综合判断。
