加 ONLINE 才算真正“在线”，因为不带 ONLINE 会获取 EXCLUSIVE 锁阻塞 DML，而 ONLINE 采用行级锁+物化日志实现并发写入；12c 引入该特性，11g 不支持；UPDATE GLOBAL INDEXES 兼容本地索引且语义明确，但会全程锁定全局索引。
ALTER TABLE ... MOVE PARTITION 在 Oracle 12c 及以上版本支持在线执行，但必须显式加 ONLINE 关键字，否则默认是离线操作 —— 会阻塞 DML，且索引自动失效。
为什么加 ONLINE 才算真正“在线”？
不带 ONLINE 的 MOVE PARTITION 本质仍是锁表操作：它会获取 EXCLUSIVE 表级锁（或分区级锁），期间所有 INSERT/UPDATE/DELETE 都被挂起，直到语句完成。而加了 ONLINE 后，Oracle 改用行级锁+物化日志（如 LOGGING 模式下的大量 redo）实现并发写入，DML 可持续进行。
常见错误现象：ORA-00054: resource busy and acquire with NOWAIT specified 或应用长时间卡在 DML 上，基本就是漏写了 ONLINE。
-
ONLINE是 12c 引入的特性，11g 及更早版本不支持，强行使用会报ORA-00922: missing or invalid option - 即使加了
ONLINE，DDL 本身仍需短暂持有SHARE锁（秒级），不影响业务，但高并发下可能引发短时排队 - 全局索引（非 local）在
MOVE PARTITION后一定失效，必须重建；本地索引加UPDATE INDEXES可自动维护
UPDATE INDEXES 和 UPDATE GLOBAL INDEXES 到底怎么选？
本地索引（LOCAL）和全局索引（GLOBAL）行为完全不同：
- 对本地索引，只写
UPDATE INDEXES就够了 —— Oracle 自动重定位索引分区，状态保持USABLE - 对全局索引，必须显式写
UPDATE GLOBAL INDEXES，否则索引直接变UNUSABLE，后续查询走不到索引 - 如果表上同时有本地和全局索引，建议统一用
UPDATE GLOBAL INDEXES，它兼容本地索引，且语义更明确 - 注意：
UPDATE GLOBAL INDEXES会全程锁定全局索引，期间该索引不可用于查询（哪怕只是 SELECT），这点常被忽略
实际执行时最易踩的三个坑
看似一条 SQL，实操中失败率很高，关键点都在细节里：
- 目标表空间必须已存在，且用户对该表空间有
QUOTA（不能只靠UNLIMITED TABLESPACE角色，得查DBA_TS_QUOTAS确认） - 移动前确认分区无未提交事务 ——
SELECT * FROM V$TRANSACTION查活跃事务，否则MOVE会等锁超时 - 若分区含 LOB 字段，
MOVE PARTITION默认不处理 LOB 段，需额外加LOB (col_name) STORE AS (TABLESPACE ts_name)子句，否则 LOB 仍留在原表空间 - 执行后务必检查索引状态：
SELECT INDEX_NAME, PARTITION_NAME, STATUS FROM DBA_IND_PARTITIONS WHERE TABLE_NAME = 'YOUR_TABLE'，别只看 DDL 是否返回 “Table altered”
一个安全可用的完整示例
假设要将分区 P1 移到表空间 TBS_ARCHIVE，表有本地和全局索引，且含 LOB 字段 DOC_CONTENT：
ALTER TABLE sales_data MOVE PARTITION p1 TABLESPACE tbs_archive LOB (doc_content) STORE AS (TABLESPACE tbs_archive_lob) UPDATE GLOBAL INDEXES ONLINE;
这条语句做完后，sales_data 分区 P1 的数据、LOB 段、本地索引分区、全局索引条目全部就位，且全程允许业务 DML 持续写入。但要注意：ONLINE 过程会产生比离线多 3–5 倍的 redo，归档压力和恢复时间窗口需提前评估。
真正麻烦的不是语法，而是 move 前没确认表空间配额、没清理长事务、没检查 LOB 存储子句 —— 这些问题往往在凌晨执行时才暴露，而且没法回滚。
