不能直接迁移用户，只能迁移其在SYSTEM表空间中的对象；因SYSTEM仅存数据字典等系统对象，普通用户对象驻留其中会导致膨胀、备份失败、权限风险等，必须将其移至合法表空间并验证段状态与索引有效性。不能直接“迁移用户”，只能迁移该用户下存在于 SYSTEM 表空间的对象（表、索引、LOB、分区等）。SYSTEM 表空间是 Oracle 的核心系统表空间，任何用户对象都不应存放在其中 —— 这属于严重配置错误，必须修复，但操作本身不涉及“用户迁移”，只涉及对象搬迁。
为什么不能动 SYSTEM 表空间里的用户对象？
system 表空间仅用于存储数据字典、系统回滚段、默认的系统对象。如果普通用户对象（比如 user1 的表）建在 system 里，会导致：
- SYSTEM 表空间持续膨胀，无法 shrink（
ALTER DATABASE DATAFILE ... RESIZE对 SYSTEM 失效） - 备份/恢复变慢，导出导入可能失败（如 XTTS 报
ORA-39921） - DBA 权限误操作风险升高（比如误删 SYSTEM 中的用户段）
所以目标不是“把用户迁走”，而是“把用户在 SYSTEM 里的所有段对象挪到合法表空间”。
如何确认哪些对象还在 SYSTEM 表空间？
用当前用户身份（非 SYS）执行以下查询 —— 注意：你只能看到自己拥有的对象；若需全库扫描，必须有 DBA 权限：
SELECT table_name, tablespace_name FROM user_tables WHERE tablespace_name = 'SYSTEM';
SELECT index_name, table_name, tablespace_name FROM user_indexes WHERE tablespace_name = 'SYSTEM';
SELECT table_name, column_name, tablespace_name FROM user_lobs WHERE tablespace_name = 'SYSTEM';
SELECT table_name, partition_name, tablespace_name FROM user_tab_partitions WHERE tablespace_name = 'SYSTEM';
⚠️ 注意：user_* 视图看不到其他用户的对象。如果你是普通用户且发现自己的表在 SYSTEM，说明建表时没指定 TABLESPACE，而你的 DEFAULT TABLESPACE 被错误设为 SYSTEM（可通过 SELECT default_tablespace FROM user_users; 验证）。
迁移表、索引、LOB 和分区的实操要点
所有操作都需在业务低峰期执行，并提前备份（EXPDP 或 RMAN）。每类对象迁移后状态不同，必须按顺序处理：
-
表迁移：
ALTER TABLE t1 MOVE TABLESPACE users;→ 立即失效所有基于该表的索引（状态变为UNUSABLE），但表数据在线可用 -
索引重建：
ALTER INDEX i1 REBUILD TABLESPACE users;→ 必须在表迁移后执行，否则报ORA-01418（索引不存在）或ORA-01502（索引不可用） -
LOB 字段：不能随表一起 move，必须单独处理：
ALTER TABLE t1 MOVE LOB(clob_col) STORE AS (TABLESPACE users);→ 否则迁移后SELECT该字段会报ORA-22997 -
分区表：需逐个迁移分区：
ALTER TABLE pt1 MOVE PARTITION p1 TABLESPACE users;→ 不支持整张分区表一次性 move；迁移后同样要重建局部索引
批量生成语句推荐用 SELECT 'ALTER TABLE ...' FROM user_tables...，但注意：生成的语句中表名不含 schema，若你在非当前用户模式下操作（如用 SYS 查 dba_tables），必须拼上 owner，否则执行时报 ORA-00942。
容易被忽略的三个硬伤
很多 DBA 在迁移完就以为结束了，结果第二天应用报错：
-
约束依赖的索引没重建：主键/唯一约束背后是索引，
MOVE后约束状态仍是ENABLED，但实际不可用 ——INSERT可能违反唯一性却无报错，直到某次ANALYZE或 DML 触发才暴露 -
物化视图日志残留：如果表上有物化视图日志（
user_mview_logs），它本身也占段，且建在 SYSTEM 里，迁移表后日志仍无效，需DROP MATERIALIZED VIEW LOG ON t1再重建 -
未重置统计信息：
MOVE后旧统计信息失效，优化器可能选错执行计划 —— 必须立刻执行：EXEC DBMS_STATS.GATHER_TABLE_STATS(ownname => USER, tabname => 'T1', cascade => TRUE);
真正安全的收尾不是“跑完 SQL”，而是验证：查 dba_segments 确认 SYSTEM 下再无该用户的任何 SEGMENT_TYPE IN ('TABLE','INDEX','LOBSEGMENT','LOBINDEX','TABLE PARTITION')，且所有索引 STATUS = 'VALID'。
