不能直接迁移用户，只能迁移其在SYSTEM表空间中的对象；因SYSTEM仅存数据字典等系统对象，普通用户对象驻留其中会导致膨胀、备份失败、权限风险等，必须将其移至合法表空间并验证段状态与索引有效性。
不能迁移 SYSTEM 表空间本身，也不能“把数据从 SYSTEM 迁出来”——因为 SYSTEM 里只该有数据字典对象；你看到的“SYSTEM 里的用户数据”，其实是普通用户对象被错误创建在 SYSTEM 表空间中。真正的目标是：把那些本不该在 SYSTEM 里的表、索引、LOB 等段对象，安全挪到合法表空间（如 USERS 或自定义业务表空间）。
怎么确认哪些对象还在 SYSTEM 表空间？
先查清范围，避免盲目操作。普通用户只能查自己拥有的对象；DBA 用户可全库扫描：
SELECT table_name, tablespace_name FROM user_tables WHERE tablespace_name = 'SYSTEM';SELECT index_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 segment_name, segment_type, tablespace_name FROM user_segments WHERE tablespace_name = 'SYSTEM';
⚠️ 注意：user_* 视图看不到其他用户对象。如果你是普通用户却查到自己的表在 SYSTEM，说明建表时没指定 TABLESPACE，且你的 DEFAULT TABLESPACE 被设成了 SYSTEM（可用 SELECT default_tablespace FROM user_users; 验证）。
ALTER TABLE ... MOVE 之后为什么索引全失效？
因为 MOVE 是物理重组，原表段地址变了，索引仍指向旧位置，状态自动变为 UNUSABLE。不重建就查不了、改不了，还会在 DML 时报 ORA-01502。
- 必须在
MOVE后立即重建索引：ALTER INDEX idx_name REBUILD TABLESPACE users; - 如果索引含
UNIQUE且表有重复数据，REBUILD会失败，得先清理数据 - 全局索引在分区表
MOVE PARTITION后也会失效，需额外UPDATE GLOBAL INDEXES或单独REBUILD - LOB 段要单独处理：
ALTER TABLE t1 MOVE LOB(col1) STORE AS (TABLESPACE users);
迁移 SYS.AUD$ 审计表的正确方式
Oracle 11g 及以后，别再用手工 MOVE + REBUILD，容易漏掉 LOB 或索引，还可能锁死审计功能。
- 优先用官方包：
EXEC DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATION(AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD, AUDIT_TRAIL_LOCATION_VALUE => 'USERS'); - 执行前确保目标表空间
USERS已存在、有足够空间、且SYS对其有WRITE权限 - 执行后立刻验证：
SELECT owner, segment_name, tablespace_name FROM dba_segments WHERE segment_name = 'AUD$' AND owner = 'SYS';—— 应返回USERS - 若仍卡在 SYSTEM，可能是未重启审计或未刷新内存缓存，可尝试
AUDIT_TRAIL_TYPE改为AUDIT_TRAIL_OS再切回
最易被忽略的是：迁移完所有对象后，必须检查 dba_segments 中是否还有 OWNER 非 SYS 的记录落在 SYSTEM；另外，任何依赖这些对象的视图、物化视图、DB Link 都要重新验证有效性，否则上线后第一个查询就报错。
