分区表MOVE后出现行迁移,因MOVE不继承PCTFREE且未显式指定,导致新块无空闲空间;LOB列未同步MOVE时,OUT OF ROW存储引发伪链行,需显式MOVE LOB段或禁用IN ROW。
MOVE 后反而出现行迁移?直接对分区执行 alter table ... move partition 本身不会“修复”行迁移,反而可能加剧问题——因为 move 是物理重写,它按当前行实际长度分配块空间,但默认不保留空闲空间。如果原分区中已有因 pctfree 不足导致的迁移行,move 后这些行被紧凑写入新块,而后续更新仍会立刻触发新迁移。
关键点在于:MOVE 操作不继承原分区的 PCTFREE 设置(除非显式指定),且 ASSM 表空间下 PCTFREE 的作用机制与手工管理不同,容易被忽略。
PCTFREE: SELECT partition_name, pct_free FROM user_tab_partitions WHERE table_name = 'TBL_NAME' AND partition_name = 'P1';
MOVE 时必须显式带 PCTFREE 参数,例如:ALTER TABLE tbl_name MOVE PARTITION p1 PCTFREE 20;
COMPRESS FOR OLTP),MOVE 后需重新启用,否则行宽膨胀更易触发迁移ANALYZE TABLE ... LIST CHAINED ROWS 为何对分区表失效?该命令在分区表上默认只分析 分区键所在段的头部信息,不扫描每个子分区的数据块,因此常漏报——尤其当迁移/链行集中在某个子分区时,CHAINED_ROWS 表里可能为空或严重低估。
正确做法是逐个分析具体分区:
@?/rdbms/admin/utlchain.sql 创建 CHAINED_ROWS 表ANALYZE TABLE tbl_name PARTITION(p1) LIST CHAINED ROWS INTO chained_rows;
SELECT * FROM chained_rows WHERE table_name = 'TBL_NAME' AND partition_name = 'P1';
注意:DBMS_STATS.GATHER_TABLE_STATS 不报告链行,它只收集统计信息,不能替代 ANALYZE。
执行 MOVE PARTITION 后,本地索引(LOCAL)自动维护,但全局索引(GLOBAL)会变为 UNUSABLE;更隐蔽的问题是:即使索引重建完成,若未清理旧链行残留的块指针,某些查询仍会触发 table fetch continued row 等待事件。
SELECT index_name, status FROM user_indexes WHERE table_name = 'TBL_NAME';
ALTER INDEX idx_name REBUILD;(不可用时必须加 REBUILD,不能只用 UPDATE INDEXES)SELECT name, value FROM v$sysstat WHERE name = 'table fetch continued row'; 对比 MOVE 前后增量MOVE 触及的“伪链行”(如 LOB 段未同步移动),需单独检查 USER_LOBS 并对 LOB 列执行 MOVE
MOVE PARTITION 解决只要表含 CLOB/BLOB 字段,且启用了 ENABLE STORAGE IN ROW(默认开启),Oracle 就可能将大值存于行外(OUT OF ROW),此时 MOVE PARTITION 只搬主表块,LOB 段仍留在原位置——造成逻辑上的“跨块链接”,表现为持续的 table fetch continued row,但 CHAINED_ROWS 查不到记录。
真正有效的做法是:
SELECT column_name, in_row FROM user_lobs WHERE table_name = 'TBL_NAME';
IN_ROW = 'NO',需同步移动 LOB 段:ALTER TABLE tbl_name MOVE PARTITION p1 LOB(lob_col) STORE AS (TABLESPACE ts_name);
ALTER TABLE tbl_name MODIFY LOB(lob_col) (DISABLE STORAGE IN ROW);,但会增加一次额外 I/O这个细节最容易被跳过:分区 MOVE 命令不自动包含 LOB 子句,必须显式声明,否则看似成功,实则埋下性能隐患。