能，Oracle 12c及以上版本支持MOVE PARTITION ONLINE，将排他锁降级为行级并发锁，DML操作不受阻塞；但需注意LOB不兼容、索引统计信息需手动更新等限制。
MOVE PARTITION ONLINE 能否避免锁表？
能，但不是“完全不加锁”，而是把排他锁（exclusive lock）降级为行级 dml 并发锁。只要加了 online，dml 就不会被阻塞——insert/update/delete 可照常执行，应用无感知中断。
常见错误现象：ORA-00054 依然可能出现，但通常源于其他会话正持有该分区上的 DML 锁（比如长事务未提交），而非 MOVE PARTITION 自身阻塞了 DML。
- 必须是 Oracle 12c R1（12.1.0.1）及以上版本，11g 不支持该语法
-
ONLINE仅对当前操作的分区生效，其他分区不受影响 - 会产生大量 redo 日志，尤其在大分区上，需预留足够归档空间
- 不能与
LOB ... STORE AS同时使用（会报 ORA-14647），LOB 分区需单独处理
UPDATE INDEXES ONLINE 和 UPDATE INDEXES 有什么区别？
区别在索引可用性保障级别：UPDATE INDEXES ONLINE 确保全局索引和本地索引全程保持 VALID 状态；而仅写 UPDATE INDEXES（离线模式）会导致全局索引瞬间变为 UNUSABLE，哪怕只持续几毫秒，也可能触发应用报错或执行计划突变。
使用场景：有全局索引的订单表按月分区，迁移 P_202401 时若漏掉 ONLINE，查询可能突然走全表扫描。
-
UPDATE INDEXES ONLINE是推荐写法，尤其对高可用要求严的业务 - 本地索引（
LOCAL）受分区绑定，MOVE PARTITION后自动重建，无需额外干预 - 如果表有函数索引或域索引，
UPDATE INDEXES ONLINE仍适用，但需确认其底层实现是否支持在线重建
为什么 MOVE PARTITION ONLINE 后查询反而变慢？
不是数据搬错了，而是统计信息没更新 + 执行计划缓存未刷新。即使加了 UPDATE INDEXES ONLINE，它只重建索引结构，不触发统计信息收集——优化器仍用旧的行数、分布直方图估算，容易误判分区裁剪失效或选错索引。
性能影响最常出现在两个环节：
- 分区级统计信息清空：迁移后
DBA_TAB_PARTITIONS.NUM_ROWS变为NULL，必须手动收集 - 动态采样临时补救不可靠：尤其对倾斜数据，建议立刻执行
DBMS_STATS.GATHER_TABLE_STATS并指定GRANULARITY => 'PARTITION' - 如果新表空间启用了压缩（如
ROW STORE COMPRESS BASIC），首次访问可能触发透明解压，延迟明显，但仅限首查
LOB 字段怎么一起迁到新表空间？
不能和 ONLINE 一起用，必须拆成两步：先用 MOVE PARTITION ... ONLINE 迁移主数据，再单独执行 ALTER TABLE ... MOVE LOB(...) STORE AS (TABLESPACE ...) 迁移 LOB 段。
否则会直接报错：ORA-14647: Tablespace is not online 或更常见的 ORA-14647: Cannot specify LOB storage clause with ONLINE。
- LOB 迁移本身不支持
ONLINE，会短暂锁住该 LOB 列对应的所有行 - 若 LOB 列值很大（如 > 4KB），建议在低峰期执行，并监控
V$SESSION_LONGOPS - 迁移前检查
USER_LOBS中的CHUNK和PCTVERSION设置，避免新表空间块大小不匹配导致隐式扩展
真正容易被忽略的是：即使所有语法都写对了，ONLINE 操作仍依赖底层存储 I/O 能力。如果新表空间位于慢速存储（如 NFS 或归档盘），移动过程本身可能拖慢数倍，且期间产生的大量 redo 会放大日志切换压力——这不是锁的问题，而是资源饱和问题。
