交换分区前需强制刷新物化视图以清空对应分区的日志记录，否则快速刷新时因rowid失效导致ora-12032或ora-02291；交换后须立即purge_log并收集mlog$统计信息，确保刷新链路可靠。
交换分区前物化视图日志还在记录旧数据
分区交换（EXCHANGE PARTITION）本身不触发物化视图日志（MLOG$）写入，但若交换前基表已有未刷新的变更、且这些变更恰好落在被交换的分区里，日志中就会残留指向已“物理移走”的ROWID或主键值。后续快速刷新时，DBMS_MVIEW.REFRESH 会尝试用这些失效ROWID去查原表——而该分区已不在原表中，直接报 ORA-12032: cannot use rowid from restricted row source 或静默跳过部分更新。
实操建议：
- 交换前强制刷新对应分区涉及的所有物化视图：
DBMS_MVIEW.REFRESH(list => 'MV_NAME', method => 'F')，确保MLOG$中该分区范围的记录已被消费（SNAPTIME$$更新为非 01-JAN-4000 值） - 若无法全刷，可临时禁用日志捕获：先
ALTER TABLE base_table NOLOGGING（仅限维护窗口），再执行交换；结束后立即ALTER TABLE base_table LOGGING并重建日志（DROP MATERIALIZED VIEW LOG ON base_table+ 重CREATE） - 检查日志是否包含已交换分区的数据：
SELECT COUNT(*) FROM MLOG$_BASE_TABLE WHERE ROWID IN (SELECT ROWID FROM base_table PARTITION (P_202409))，结果非零即存在残留
交换后物化视图仍扫描被移走的分区ROWID
Oracle 快速刷新默认按日志中的 ROWID 回查基表，但交换后的分区已脱离原表段，其原始 ROWID 在新位置无效。即使你用 WITH PRIMARY KEY 建日志，只要日志里存的是旧分区的主键值，而该主键在交换后的新表（如归档表）中未同步存在，刷新时仍会因找不到父键报 ORA-02291。
实操建议：
- 交换必须配合日志清理：交换完成后立刻执行
EXEC DBMS_MVIEW.PURGE_LOG('BASE_TABLE', 0)（0 表示清除所有已消费记录），避免残留日志干扰 - 若交换目标是归档表，且该归档表也需参与物化视图，则必须显式将其加入 MV 定义，不能只依赖基表日志；否则刷新引擎无处校验外键一致性
- 禁止在交换后立即跑
ATOMIC_REFRESH => FALSE：它会直接TRUNCATEMV 再INSERT /*+ APPEND */，但若日志残留未清理，新插入数据可能缺行，且无事务回滚保障
如何让交换操作对物化视图完全透明？
真正透明的交换，要求物化视图在交换前后看到的“逻辑数据”不变，且日志机制不感知物理移动。这只有在满足三个条件时才成立：日志启用 INCLUDING NEW VALUES、MV 定义不含 WHERE 分区过滤、且交换分区在 MV 查询中本就不可见（例如 MV 只查最近 3 个月，而你交换的是 2023 年分区）。
实操建议：
- 建日志时必须带
INCLUDING NEW VALUES：CREATE MATERIALIZED VIEW LOG ON base_table WITH ROWID, SEQUENCE (col1, col2) INCLUDING NEW VALUES，否则交换后更新旧分区数据会导致日志丢失新值 - MV 查询中避免硬编码分区谓词，改用函数表达式（如
sale_date >= ADD_MONTHS(SYSDATE, -3)），让优化器能动态裁剪，而非固化分区列表 - 交换前确认 MV 刷新状态：
SELECT last_refresh_date, refresh_method FROM dba_mviews WHERE mview_name = 'MV_NAME'，若last_refresh_date滞后超过 1 小时，别急着交换
为什么 purge_log 后还要 gather_stats？
DBMS_MVIEW.PURGE_LOG 只删数据，不更新统计信息。日志表 MLOG$_BASE_TABLE 被清空后若没及时收集统计，优化器仍按旧的百万级行数估算执行计划，导致后续快速刷新又卡在全表扫描 MLOG$ 阶段——哪怕它现在只剩几十行。
实操建议：
- 每次
PURGE_LOG后紧跟：EXEC DBMS_STATS.GATHER_TABLE_STATS(user, 'MLOG$_BASE_TABLE', estimate_percent => 100) - 不要依赖自动统计任务：它的默认采样率太低，对日志表这种“小而关键”的对象极易误判
- 如果日志表长期为空，可考虑定期重建索引：
DROP INDEX idx_mlog_seq; CREATE INDEX idx_mlog_seq ON MLOG$_BASE_TABLE (snaptime$$, sequence$$)，避免索引块碎片影响扫描效率
