oracle分区表更新分区键必须先启用enable row movement，否则报ora-14402错误；启用后update转为delete+insert+update三阶段操作，导致rowid变更、全局索引失效、i/o翻倍。
Oracle 分区表更新分区键值本身不会“触发”Row Movement，而是必须先开启 ENABLE ROW MOVEMENT，否则直接报 ORA-14402 错误——它是个硬性准入开关，不是自动响应机制。
ORA-14402 报错时到底发生了什么
你执行 UPDATE 修改了分区键列（比如 order_date 或 region_code），且新值落在另一个分区范围内，Oracle 检测到该行“理应”迁移，但发现表的 row_movement 状态是 DISABLED，于是立刻中止操作并抛出错误。这不是延迟判断，也不是优化器犹豫，而是 DML 执行前的强制校验。
常见误判点：
- 即使新旧值在逻辑上属于同一分区（比如范围分区中两个日期都在
2025-11分区内），Oracle 也不做区间重叠推断，一律按键值重计算分区归属，再比对物理位置 - 该限制与分区类型无关：范围、列表、哈希、组合分区全适用
-
INSERT ... ON DUPLICATE KEY UPDATE类语句（如 Kettle 的“插入/更新”步骤）同样会撞上这个墙
ENABLE ROW MOVEMENT 不是“启动迁移引擎”，而是“允许删插模拟”
开启后，UPDATE 不再原地修改，而是被 Oracle 内部重写为三阶段原子操作：
- 在原分区执行
DELETE WHERE [original condition] - 用原行数据在目标分区执行
INSERT - 再对新插入的行执行真正的字段更新（即你写的
SET部分）
这意味着：
-
ROWID必然变更，所有依赖ROWID的逻辑（如某些触发器、物化视图日志、自定义审计）都会受影响 - 全局索引（
GLOBAL INDEX）不会自动维护，UPDATE 后可能变为UNUSABLE，必须手动ALTER INDEX ... REBUILD - 本地索引（
LOCAL INDEX）虽能自动跟上，但旧分区和新分区的索引段都会被更新，I/O 和锁开销翻倍 - 如果表上有域索引（
DOMAIN INDEX），ENABLE ROW MOVEMENT会直接失败
为什么不能跳过 Row Movement 直接原地更新分区键
因为分区键决定了数据的物理落盘位置，而 Oracle 的分区实现不支持“就地重哈希”或“就地重范围定位”。底层存储单元（data block）和分区段（segment）是强绑定的，跨分区移动本质是跨段操作，必须通过 delete+insert 实现。这也是为什么：
- 哪怕只改一个字段，只要它是分区键，整个行就得搬走
- 批量更新 N 行分区键，实际产生约 2N 次索引维护、N 次 undo/redo 记录膨胀
-
FLASHBACK TABLE和SHRINK SPACE也依赖同一开关，说明这是 Oracle 对“行物理位置可变”这一能力的统一抽象，不是专为分区设计的补丁
真正容易被忽略的是：开了 ENABLE ROW MOVEMENT 后，你写的 UPDATE 语句行为已彻底改变——它不再是传统意义上的 DML，而是一个隐式事务链。上线前不压测、不检查索引状态、不评估触发器兼容性，大概率会在高峰期暴露问题。
