不能直接修改分区键字段值,UPDATE会报ORA-14402;分区键列本身无法通过ALTER TABLE修改,必须用DBMS_REDEFINITION重建表结构。
不能直接修改分区键字段的值——UPDATE 会报 ORA-14402,除非先启用 ROW MOVEMENT;但更关键的是:分区键本身(即用于 PARTITION BY 的列)无法通过 ALTER TABLE 修改。想换分区依据,必须重建表结构。
Oracle 默认禁止更新分区键字段,因为这可能触发行从一个物理分区移动到另一个分区。它不判断“新旧值是否落在同一分区”,一律拦截。错误信息明确说:updating partition key column would cause a partition change。
sale_date 从 2025-03-15 改成 2025-03-20(仍在同一范围分区),照样报错必须先开启表级行迁移能力,再执行 UPDATE。但这只是“解禁”,不是“优化”——底层仍是删旧插新。
SELECT row_movement FROM user_tables WHERE table_name = 'YOUR_TABLE'
ALTER TABLE your_table ENABLE ROW MOVEMENT
UPDATE your_table SET part_key_col = new_val WHERE ...
UNUSABLE,需加 UPDATE GLOBAL INDEXES 或事后 REBUILD
:OLD/:NEW 按迁移前后分别取值如果业务需要把按 region_code 分区的表,改成按 create_time 分区,ALTER TABLE ... PARTITION BY ... 语法不存在。唯一合规路径是 DBMS_REDEFINITION。
SYS/SYSTEM 用户下START_REDEF_TABLE → COPY_TABLE_DEPENDENTS(含索引约束)→ SYNC_INTERIM_TABLE(同步增量)→ FINISH_REDEF_TABLE
COPY_TABLE_DEPENDENTS 会冲突真正难的不是命令怎么敲,而是评估行迁移对触发器、约束延迟、HWM 和归档日志的影响;在线重定义则卡在锁窗口、空间预估和依赖对象同步的细节里——这些地方一疏忽,就不是报错,而是业务阻塞。