分区迁移前必须确认三件事：目标表空间状态为ONLINE、源分区与目标表空间的COMPRESS属性兼容、该分区未被任何DML或查询锁定。
分区迁移前必须确认的三件事
直接执行 alter table ... move partition 很容易卡住或失败，不是语法错，而是底层依赖没对齐。迁移冷分区前，先检查：
- 目标表空间是否已存在且
STATUS = 'ONLINE'（查DBA_TABLESPACES） - 源分区和目标表空间的
COMPRESS属性是否兼容（比如源未压缩，目标启用了COMPRESS FOR ARCHIVE LOW，需显式指定COMPRESS选项） - 该分区是否被任何正在运行的 DML 或查询锁定（
V$SESSION+V$LOCK关联查OBJECT_ID）
MOVE PARTITION 语句的关键参数组合
MOVE PARTITION 看似简单，但不同组合直接影响冷数据落地效果。常见误用是只改表空间，忽略压缩与只读设置：
- 仅迁移位置：
ALTER TABLE cngr_SEMResult MOVE PARTITION p2024_q3 TABLESPACE cold_tbs;→ 数据物理移走，但仍是可读写、未压缩状态 - 带压缩迁移：
ALTER TABLE cngr_SEMResult MOVE PARTITION p2024_q3 TABLESPACE cold_tbs COMPRESS FOR ARCHIVE LOW;→ 压缩生效，但仍是读写模式 - 冷数据完整闭环：
ALTER TABLE cngr_SEMResult MOVE PARTITION p2024_q3 TABLESPACE cold_tbs COMPRESS FOR ARCHIVE LOW UPDATE INDEXES;，再执行ALTER TABLE cngr_SEMResult MODIFY PARTITION p2024_q3 READ ONLY;
注意 UPDATE INDEXES 必须带上，否则本地索引会变 UNUSABLE；READ ONLY 要单独发，MOVE 本身不改变读写属性。
为什么不能直接 ALTER TABLESPACE … OFFLINE 冷表空间
有人想“干脆把冷表空间 offline，彻底隔离”，这在 VPS 环境下极易引发连锁故障：
- 如果该表空间里还有未设为
READ ONLY的分区，offline 会报ORA-01157: cannot identify/lock data file - 即使全只读，某些后台进程（如 ADO、Heat Map 日志写入）仍可能尝试访问，触发隐式 I/O，导致实例 hang 住
- VPS 的 ASM 实例对 offline 表空间的恢复响应比物理机慢得多，一次误操作可能拖累整机 IO 调度
正确做法是保持表空间 online，靠 READ ONLY + COMPRESS 控制行为，而不是靠状态切换来“假装冷”。
自动化迁移冷分区时最容易漏掉的钩子
用 ILM 或调度 JOB 自动迁移时，90% 的人会忽略分区元数据同步问题：
-
DBA_TAB_PARTITIONS中的COMPRESSION和READ_ONLY字段更新是即时的，但DBA_SEGMENTS里的BYTES和BLOCKS可能延迟几分钟才刷新 —— 别拿它立刻判断压缩是否生效 - 如果原分区有本地索引，MOVE 后索引状态是
VALID，但统计信息不会自动更新，需手动DBMS_STATS.GATHER_INDEX_STATS，否则后续查询可能走错执行计划 - 间隔分区（
INTERVAL）自动创建的新分区默认继承父表空间，但不会自动继承压缩策略 —— 必须用ALTER TABLE ... MODIFY DEFAULT ATTRIBUTES显式设置
冷热分级不是“迁完就完”，真正的分层效果取决于压缩率、只读标识、索引可用性、统计信息这四者的同步到位。少一个，查询性能或存储节省都会打折扣。
