Oracle支持ALTER TABLESPACE old_name RENAME TO new_name安全重命名，但仅限ONLINE非系统表空间；重命名后必须手动更新用户默认表空间、物化视图日志等依赖项，否则后续DDL将报ORA-01950或ORA-00959错误。
可以安全重命名 Oracle 表空间而不中断业务，前提是表空间处于 ONLINE 状态且不是 SYSTEM、SYSAUX 或临时表空间；但重命名后必须立刻修正用户默认表空间、物化视图日志等依赖项，否则后续 DDL 会报 ORA-01950 或 ORA-00959。
ALTER TABLESPACE ... RENAME TO 的合法写法和致命陷阱
唯一可用语法是 ALTER TABLESPACE old_name RENAME TO new_name。它不接受任何额外关键词或修饰符：
-
ALTER TABLESPACE old_name SET RENAME TO new_name→ 直接报ORA-00922（缺少或无效选项） - 用单引号或双引号包裹名称，如
ALTER TABLESPACE 'OLD' RENAME TO 'NEW'→ 报ORA-00959（表空间不存在），因为引号会让 Oracle 当作带大小写的标识符去查，而原名实际是大写无引号建的 - 若原表空间名建时用了双引号强制大小写（比如
"MyTs"），则重命名时也必须严格写成ALTER TABLESPACE "MyTs" RENAME TO "NewTs"，否则仍报ORA-00959
重命名前必须验证的三个状态
不能只看表空间存在就执行，必须确认它当前可被修改：
- 查状态：
SELECT tablespace_name, status FROM dba_tablespaces WHERE tablespace_name = 'OLD_NAME';—— 结果中status必须是ONLINE；如果是OFFLINE，先运行ALTER TABLESPACE OLD_NAME ONLINE; - 排除系统表空间：
SYSTEM和SYSAUX表空间无论状态如何，执行重命名都静默失败或报ORA-01109（数据库未打开），错误信息不提示真实原因 - 确认无活跃会话占用：虽然重命名本身不要求锁表，但若有大量 DML 正在往该表空间的段里写，可能触发短暂 latch 竞争；建议避开业务高峰，并检查
v$session中tablespace列是否含该名（部分版本不显示，以dba_segments+v$transaction关联更准）
重命名后哪些自动更新，哪些必须手动改
重命名只改数据字典里的 DBA_TABLESPACES.TABLESPACE_NAME 和控制文件中的逻辑名，物理文件路径、内容、文件头信息全都不动：
-
DBA_SEGMENTS.TABLESPACE_NAME、DBA_EXTENTS.TABLESPACE_NAME等视图会立即反映新名 - 用户默认表空间字段
DBA_USERS.DEFAULT_TABLESPACE不变 —— 若用户默认指向旧名，下次建表就会报ORA-01950: no privileges on tablespace 'OLD_NAME'，必须立刻执行ALTER USER username DEFAULT TABLESPACE new_name; - 物化视图日志、分区表的
TABLESPACE子句定义、LOB 默认表空间等元数据也不更新；后续对这些对象做ALTER或ADD PARTITION时会因找不到旧名而失败 - 监听器、tnsnames.ora、应用连接字符串里写的都是服务名，不受影响；但 JDBC URL 中若硬编码了表空间名（极少见），需同步改
重命名后最易漏掉的三处验证
语句返回“表空间已更改”不等于完成，必须立刻查：
- 查新名是否存在且状态正常：
SELECT tablespace_name, status FROM dba_tablespaces WHERE tablespace_name = 'NEW_NAME';—— 确保有结果且status = 'ONLINE' - 查旧名是否彻底消失：
SELECT count(*) FROM dba_tablespaces WHERE tablespace_name = 'OLD_NAME';—— 结果应为 0 - 查是否有段还挂在旧名上：
SELECT owner, segment_name, segment_type FROM dba_segments WHERE tablespace_name = 'OLD_NAME';—— 如果有返回，说明某些对象元数据没刷新，可能是 bug 或缓存未同步，需ALTER SYSTEM FLUSH SHARED_POOL;并重查
真正麻烦的不是重命名动作本身，而是那些散落在各处、不随表空间名自动更新的引用点——它们不会立刻报错，但会在下一次相关 DDL 时突然崩出 ORA-00959，而且很难定位源头。
