用partition exchange实现历史数据归档和在线表无缝切换，核心是不锁主表、不搬数据、秒级完成，关键在于分区策略设计、归档边界控制与一致性验证。
用 partition exchange 实现历史数据归档和在线表无缝切换，核心在于不锁主表、不搬数据、秒级完成。关键不是“怎么交换”，而是“怎么设计分区策略+怎么控制归档边界+怎么验证一致性”。
分区表必须按时间列做 RANGE 分区
只有时间范围明确的分区，才能精准定位哪些数据该归档。比如按月分区，date_col 是分区键，每月一个分区（p202401, p202402…），归档 2024 年 3 月前的数据，就只涉及 p202403 及之前分区。
- 避免 LIST 或 HASH 分区——无法按时间批量归档
- 确保分区键是 NOT NULL 的 DATE / TIMESTAMP 类型，且业务写入严格遵守时序
- 提前建好未来 6–12 个月的空分区（避免 exchange 时触发自动分裂）
归档表结构必须与原分区完全一致
exchange 要求源表（待归档分区）和目标表（历史归档表）满足：列名、顺序、类型、长度、NULL 属性、约束（除主键/外键）、索引结构（不强制但建议一致）全部相同。哪怕一个字段多加了个 DEFAULT，exchange 就会失败。
- 用 DBMS_METADATA.GET_DDL 导出原表 DDL，删掉分区定义，再手动去掉主键、外键、分区关键字，生成归档表建表语句
- 归档表不需要分区，但建议建相同本地索引（如 CREATE INDEX idx_his_order_dt ON his_orders(order_date) LOCAL），便于后续查询
- 归档表名建议带时间标识，如 orders_his_2024q1，方便生命周期管理
交换过程要分三步走：准备 → 交换 → 清理
单条 ALTER TABLE ... EXCHANGE PARTITION 看似一步到位，但生产环境必须拆解控制风险。
- 准备阶段：先查 USER_TAB_PARTITIONS 确认目标分区状态为 USABLE；在归档表上执行 ANALYZE TABLE ... COMPUTE STATISTICS（或收集统计信息），避免执行计划突变
- 交换阶段：执行 ALTER TABLE orders EXCHANGE PARTITION p202403 WITH TABLE orders_his_202403 INCLUDING INDEXES WITHOUT VALIDATION。加 WITHOUT VALIDATION 跳过行数据校验（否则大表会极慢），前提是业务已保证该分区数据完整、无非法值
- 清理阶段：交换后立即对原分区执行 ALTER TABLE orders TRUNCATE PARTITION p202403 REUSE STORAGE（如果后续还要复用该分区）；同时更新归档表统计信息
切换后必须验证，不能只信“没报错”
exchange 不校验数据内容，只校验元数据和段结构。一次静默错误可能导致归档丢失或主表少数据。
- 对比行数：SELECT COUNT(*) FROM orders PARTITION(p202403) 应为 0；SELECT COUNT(*) FROM orders_his_202403 应等于归档前该分区的行数
- 抽样校验：从归档表随机取 5–10 行，检查关键字段（如 order_id, order_date）是否在原始业务逻辑范围内
- 检查索引有效性：SELECT index_name, status FROM USER_INDEXES WHERE table_name IN ('ORDERS', 'ORDERS_HIS_202403')，确认状态都是 VALID
