ALTER TABLE MOVE TABLESPACE仅移动数据段，索引、LOB、分区等附属结构仍留在原表空间，必须显式重建或迁移；MOVE不更新统计信息，且会令索引失效，需及时REBUILD并验证所有依赖对象。
ALTER TABLE MOVE 为什么不能直接换表空间
执行 alter table move tablespace new_ts 看似能迁移表，但实际只移动了数据段（data segment），索引、lob、分区等附属结构完全不动——它们还钉在原表空间里。表本身“搬过去了”，但一查 dba_segments 就会发现索引段仍属旧表空间，查询或 dml 可能因索引失效而变慢甚至报错。
常见错误现象：ORA-01652: unable to extend temp segment（MOVE 过程需大量临时空间）；或 MOVE 后执行 SELECT 没问题，但带 WHERE 条件的查询突然变慢——其实是索引没重建，还在旧位置且可能已失效。
- MOVE 不重建索引，只重定位表数据行，索引的 rowid 全部失效
- LOB 列的 LOBSEGMENT 和 LOBINDEX 默认不随表移动，必须显式指定
- 分区表只能对单个分区 MOVE，整表 MOVE 会报错
ORA-14511 - MOVE 过程中表被加了
SS（sub-share）锁，DML 会被阻塞，不是在线操作
怎么安全地把表和所有依赖对象一起挪到新表空间
没有一键命令，得拆开处理：先移表，再逐个重建索引、LOB 段、IOT 的溢出段等。关键不是“能不能做”，而是“哪些必须跟上”。漏掉任何一个，都可能让应用出问题。
- 先用
ALTER TABLE ... MOVE TABLESPACE new_ts移动主表段 - 立刻执行
ALTER INDEX ... REBUILD TABLESPACE new_ts重建每个索引（含唯一、函数索引） - 对含 LOB 的表，补上
ALTER TABLE ... MOVE LOB(col) STORE AS (TABLESPACE new_ts) - 检查是否有 IOT 表，其
OVERFLOW段需单独 MOVE：ALTER TABLE ... MOVE OVERFLOW TABLESPACE new_ts - 最后验证：
SELECT segment_name, tablespace_name FROM dba_segments WHERE owner='SCHEMA' AND segment_name IN ('TAB', 'IDX1', 'SYS_LOB...')
MOVE 和 EXPDP/IMPDP 哪个更适合大表迁移
MOVE 是原地重组，速度快、不占额外磁盘空间，但锁表时间长；EXPDP/IMPDP 是逻辑导出导入，可跨库、支持并行、不锁源表，但需要双倍空间（dump + 新段），且 DDL 一致性靠 metadata 导入保障，容易漏掉权限、统计信息、注释等。
- 表小于 10GB、维护窗口短、能接受短时锁表 → 优先
MOVE + REBUILD - 表大于 50GB、要求零停机、目标库版本不同 → 用
expdp ... CONTENT=DATA_ONLY+impdp ... REMAP_TABLESPACE -
MOVE不更新统计信息，迁移后务必跑DBMS_STATS.GATHER_TABLE_STATS，否则执行计划可能劣化 - EXPDP 导出时若没加
FLASHBACK_TIME或FLASHBACK_SCN，无法保证导出时刻的一致性
常见参数陷阱和兼容性注意点
MOVE 语句看着简单，几个参数不设对，轻则迁移失败，重则数据损坏。特别是 PCTFREE、INITRANS、STORAGE 这些，不显式指定就继承原值——但新表空间的 block size 或 autoallocate 设置可能不兼容。
- 如果新表空间是
AUTOALLOCATE，别写STORAGE(INITIAL 64K)，否则报ORA-02168 -
PCTFREE设太高（如 40），会导致块利用率暴跌，后续插入性能下降 - 12c+ 支持
ONLINE关键字（ALTER TABLE ... MOVE ONLINE），但仅限非分区表，且要求开启COMPATIBLE >= 12.1 - MOVE 后索引状态变成
UNUSABLE，必须REBUILD，不能只ALTER INDEX ... COALESCE
最常被忽略的是约束依赖：外键引用该表时，MOVE 不报错，但后续插入可能因索引失效触发延迟约束校验失败。动手前，先查 DBA_CONSTRAINTS 和 DBA_INDEXES 对应关系，比盲目执行重要得多。
