exchange partition是归档首选，因它毫秒级完成、不锁表、不重写数据、索引可用；而move partition需物理重写、io大、锁长、索引失效、空间要求高，仅适合冷分区迁移而非归档。
分区交换（EXCHANGE PARTITION）是归档最稳、恢复最快的手段，比MOVE或RECOVER TABLE更轻量、可控，且不依赖备份。
为什么不用MOVE PARTITION做归档
MOVE PARTITION本质是物理重写整个分区，IO大、锁时间长、索引自动失效、容易触发ORA-01652（临时段不足）。它适合把冷分区迁到廉价表空间，但不是“归档”的首选——归档的核心诉求是快速剥离+逻辑隔离，而非物理搬迁。
- 归档场景下，你通常想把某天/某月的数据“挪走”，而不是“重写一遍”
- MOVE后必须立刻重建本地索引分区，否则查询性能断崖下跌，而EXCHANGE天然保持索引可用
- MOVE要求目标表空间有1.5倍空闲空间；EXCHANGE只需一个结构一致的普通表，建表成本极低
- MOVE期间该分区不可DML；EXCHANGE在毫秒级完成，业务几乎无感
EXCHANGE PARTITION归档实操四步
以按日分区的CUST_INFO_ARC归档主表CUST_INFO为例，核心是用普通表暂存数据，再原子交换进分区表：
- 先建一个和分区表结构完全一致的普通表（含压缩、NOL0GGING等属性），比如
CUST_INFO_TMP - 把当天要归档的数据从主表
INSERT /*+ APPEND */ INTO CUST_INFO_TMP，然后COMMIT - 给分区表加新分区：
ALTER TABLE CUST_INFO_ARC ADD PARTITION p_20260727 VALUES LESS THAN (TO_DATE('20260728','YYYYMMDD')) - 执行交换：
ALTER TABLE CUST_INFO_ARC EXCHANGE PARTITION p_20260727 WITH TABLE CUST_INFO_TMP—— 数据瞬间进入分区，索引状态不变
注意：EXCHANGE默认校验数据一致性（会扫描全表），加WITHOUT VALIDATION可跳过，但前提是确认源表数据符合分区键范围，否则后续查询可能漏数据。
误删后怎么快速恢复单个分区
如果归档后发现某分区数据被误删或逻辑错误，优先用RECOVER TABLE而非Flashback Table——因为Flashback无法跨DDL（比如分区已交换出去），而RECOVER TABLE直接从RMAN备份中拉取原始分区数据：
- 确保数据库开启归档、COMPATIBLE ≥ 11.1.0、有对应时间点的RMAN全备或增量备
- 命令示例：
RECOVER TABLE cust_info_arc FROM BACKUPSET '/backup/full_20260725.bkp' UNTIL TIME '2026-07-27 02:00:00' AUXILIARY DESTINATION '/u01/aux' - 恢复过程会自动创建辅助实例、导出分区数据为dump、再导入成新表（如
CUST_INFO_ARC_RCV），全程无需停库 - 别忽略
AUXILIARY DESTINATION空间——它至少要容纳整个分区+undo+system表空间镜像，通常需预留分区大小的3倍
统计信息和索引状态最容易被忽略
归档后常出现“查得慢”“走不到索引”，问题往往不在SQL，而在元数据没跟上：
-
EXCHANGE后，目标分区的统计信息仍是空的，必须立刻执行：DBMS_STATS.GATHER_TABLE_STATS('SCHEMA_NAME', 'CUST_INFO_ARC', PARTITION => 'p_20260727') - 本地索引分区状态不会变，但全局索引（如有）可能失效，检查：
SELECT index_name, status FROM dba_indexes WHERE table_name = 'CUST_INFO_ARC' - 如果用了
UPDATE GLOBAL INDEXES子句做EXCHANGE，全局索引保持VALID，但操作耗时明显增加；若没加，就必须手动ALTER INDEX ... REBUILD
归档不是“搬完就结束”，而是“交换→验证→统计→上线”闭环。漏掉任一环，都可能让归档后的分区变成性能黑洞。
