exchange partition 是唯一零锁表归档方式，毫秒级交换分区至普通表，需结构一致、手动重建全局索引、导出时禁用分区参数、压缩冷数据、显式导出统计信息、归档后必须drop交换表并校验全局索引状态。
EXCHANGE PARTITION 是唯一能真正零锁表的归档路径
直接对在线分区执行 expdp 或 DELETE 必然引发长事务、ITL 锁争用和业务阻塞。只有 EXCHANGE PARTITION 是毫秒级元数据操作，把目标分区“换出”到普通表，原表立刻无该分区数据，业务查询自动跳过。
- 交换表必须与原分区结构完全一致：列名、类型、
NOT NULL属性、约束（但可无索引、无统计信息） - 交换后，原分区物理数据已不在主表中，
SELECT不再扫描它，也无需加锁 - 别指望交换能自动转移索引——本地索引不会迁移，全局索引默认失效，必须手动重建
- 如果原表有本地索引，交换表上要单独建对应索引，否则后续
expdp可能因统计信息不准失败
expdp 导出交换表时参数不能带分区关键字
交换出来的表是普通堆表，不是分区表。若导出命令里还写 partitions=(p_2024) 或类似分区限定，会立即报错 ORA-39160: Cannot specify partition or subpartition for table mode。
- 正确写法：
expdp arch_user/arch_pwd directory=arch_dir dumpfile=arch_p2024.dmp tables=archive_p2024 logfile=arch_p2024.log - 加
compression=all能显著压缩冷数据体积，尤其适合历史归档 - 不要加
query参数——交换表已是纯净数据，再过滤纯属冗余且增加解析开销 - 如需保留统计信息用于后续分析，显式加上
include=statistics
归档完成后必须主动清理交换表，不能只靠“导出成功”
导出完成 ≠ 归档完成。EXCHANGE PARTITION 后的交换表仍是有效对象，占空间、进备份窗口、可能被误查，必须明确处置。
- 确认导出无报错、dump 文件校验通过（可用
impdp ... sqlfile=check.sql验证结构） - 执行
DROP TABLE archive_p2024—— 别留着“以防万一”，它没业务价值，只增风险 - 如果归档表需长期保留，应建在独立 schema（如
ARCHIVE_SCHEMA）并收回应用权限，而非留在生产 schema - 删除前检查是否有依赖：
SELECT * FROM dba_dependencies WHERE referenced_name = 'ARCHIVE_P2024'
全局索引失效是高频翻车点，别等应用报错才想起
只要执行了 EXCHANGE PARTITION、DROP PARTITION 或 TRUNCATE PARTITION，全局索引就默认失效，而本地索引只影响对应分区。优化器会跳过失效索引，导致查询性能断崖下跌，但 SQL 本身不报错。
- 检查状态：
SELECT index_name, status FROM user_indexes WHERE status = 'UNUSABLE' - 重建命令必须带
ONLINE（避免锁表）：ALTER INDEX idx_global REBUILD ONLINE - 如果加了
UPDATE GLOBAL INDEXES子句，DDL 会变慢，但可避免重建步骤——权衡点在于业务能否容忍短时性能抖动 - 别忽略索引统计信息：重建后立即执行
DBMS_STATS.GATHER_INDEX_STATS，否则执行计划可能仍走全表扫描
实际归档动作里最易被跳过的，是交换表上的索引重建和全局索引状态确认——它们不阻断 DDL，却在数小时后让关键报表突然变慢。
