move partition online必须搭配update indexes online，否则全局索引立即变为unusable；本地索引虽自动重建但状态可能延迟刷新，且该组合不更新统计信息、不处理lob，需单独执行dbms_stats.gather_table_stats和分步迁移lob。
MOVE PARTITION ONLINE 必须搭配 UPDATE INDEXES ONLINE
不加 UPDATE INDEXES ONLINE，全局索引立刻变 UNUSABLE，本地索引虽自动重建但状态可能延迟刷新。只写 UPDATE INDEXES（离线模式）会导致全局索引在重建瞬间不可用——哪怕只有几毫秒，也可能触发应用报错或执行计划突变。
-
UPDATE INDEXES ONLINE保证索引全程VALID，DML 不中断，是唯一能真正“在线维护索引”的组合 - 本地索引（LOCAL）受分区绑定，MOVE 后自动重建，无需额外干预，但状态字段更新可能有短暂延迟，建议查
user_ind_partitions确认 - 函数索引、域索引也支持
UPDATE INDEXES ONLINE，但需确认底层实现是否允许在线重建；否则会直接报错
ORA-00054 不是 MOVE 自身锁表，而是长事务阻塞
MOVE PARTITION ONLINE 把排他锁降级为行级 DML 并发锁，INSERT/UPDATE/DELETE 不会被阻塞。但若其他会话正持有该分区上的未提交事务，仍会报 ORA-00054: resource busy。
- 执行前务必检查：
SELECT sid, serial#, sql_id FROM v$session WHERE blocking_session IS NOT NULL - 重点排查长时间未 COMMIT/ROLLBACK 的会话，尤其是批处理或交互式 SQL 工具遗留的事务
- 别依赖“没人在跑 DML”就开干——后台 JOB、ETL 脚本、甚至空闲连接都可能隐式 hold 事务
移动后查询变慢？大概率是统计信息没更新
即使 UPDATE INDEXES ONLINE 成功执行，它只重建索引结构，不收集统计信息。DBA_TAB_PARTITIONS.NUM_ROWS 会变 NULL，优化器继续用旧直方图估算，容易误判分区裁剪失效或选错索引。
- 必须手动收集：
DBMS_STATS.GATHER_TABLE_STATS(ownname => 'SCHEMA_NAME', tabname => 'TABLE_NAME', granularity => 'PARTITION', partname => 'PARTITION_NAME') - 动态采样不可靠，尤其对数据倾斜严重的分区；别指望它自动补救
- 如果新表空间启用了压缩（如
ROW STORE COMPRESS BASIC），首次访问可能触发透明解压，延迟明显，但仅限首查
LOB 字段必须拆步处理，不能和 ONLINE 一起走
MOVE PARTITION ONLINE 与 LOB 存储不兼容，混用会直接报 ORA-14647。这不是版本问题，是 Oracle 内核限制。
- LOB 分区必须单独迁移：先
ALTER TABLE ... MOVE LOB (col_name) STORE AS (TABLESPACE ts_name)，再做主分区MOVE PARTITION ONLINE - 不能用一条语句覆盖全部，否则整个操作失败回滚，已做的 LOB 移动也不会自动回退
- 如果表含多个 LOB 列，每个都要单独指定列名和目标表空间，顺序无关，但必须显式写出
UPDATE INDEXES ONLINE 成功不代表万事大吉——它不碰统计信息、不清理孤儿条目、也不处理 LOB。每一步都得单独验证，缺一不可。
