物化视图存在时EXCHANGE PARTITION会报ORA-12083错误，因Oracle强制保护基表结构一致性；需先禁用MV重写并确保刷新状态，再严格校验源表与分区的结构一致性，交换后须全量刷新并恢复MV服务。
物化视图存在时，EXCHANGE PARTITION 会报错 ORA-12083
直接执行 ALTER TABLE ... EXCHANGE PARTITION 会失败，Oracle 报错：ORA-12083: must drop materialized view "xxx" before dropping table "yyy" —— 即使你只是想交换分区，Oracle 也会检查整个表是否被任何物化视图（MV）依赖。这不是权限或语法问题，而是 Oracle 的强制一致性保护机制：物化视图依赖基表结构，分区交换可能让 MV 的刷新逻辑失效。
关键点在于：Oracle 不区分「交换的是哪个分区」，只要基表上有 MV，就默认整个表结构不可变。所以必须先解除 MV 对该表的依赖关系。
安全解除依赖的两种方式：DROP 还是 DISABLE QUERY REWRITE？
不能简单删掉物化视图（DROP MATERIALIZED VIEW），尤其当它被其他应用或报表依赖时。更稳妥的做法是临时禁用其重写能力，并确保不触发自动刷新：
-
ALTER MATERIALIZED VIEW mv_name DISABLE QUERY REWRITE;—— 阻止优化器用该 MV 重写查询，但保留 MV 定义和数据 -
EXEC DBMS_MVIEW.REFRESH('mv_name', 'C'); -- 确保已刷新到最新，再暂停后续刷新（如停掉关联的 job） - 若 MV 是
ON COMMIT刷新，必须先改用ON DEMAND：CREATE MATERIALIZED VIEW ... REFRESH ON DEMAND ...（重建或用DBMS_MVIEW.EXCHANGE_TABLE替代）
注意：DISABLE QUERY REWRITE 不影响 MV 本身的数据或刷新逻辑，只关掉“透明重写”这一层；而 DROP 会清空 MV 数据、丢失构建日志，恢复成本高。
执行分区交换前，必须满足的三个结构约束
即使 MV 已禁用重写，交换仍可能失败。Oracle 要求源表（待交换进来的表）与目标分区在以下方面完全一致：
- 列名、顺序、数据类型、长度、精度、空值性（
NOT NULL属性必须一致） - 所有索引（含唯一/主键）、约束（含
CHECK、FOREIGN KEY）需兼容；特别注意：源表不能有比目标分区更多的约束 - 物化视图日志（如果存在）—— 若基表建了 MV Log，源表也必须有同结构的 MV Log，否则
EXCHANGE会拒绝（报ORA-12082）
建议用 DBMS_METADATA.GET_DDL 分别导出源表和目标分区所在表的 DDL，逐行比对；别信“看起来一样”，VARCHAR2(10 CHAR) 和 VARCHAR2(10 BYTE) 就算不兼容。
交换后如何恢复物化视图服务
交换成功不代表结束。MV 的基表段已变更，其内部快照（SNAPTIME$$）和刷新状态可能错乱：
- 立即执行
DBMS_MVIEW.REFRESH('mv_name', 'C');全量刷新一次，避免下次刷新拉取错误增量 - 若原 MV 启用了
QUERY REWRITE，记得重新启用：ALTER MATERIALIZED VIEW mv_name ENABLE QUERY REWRITE; - 检查
USER_MVIEWS视图中的STALENESS字段，确认是否为UP-TO-DATE；若为UNUSABLE，说明 MV 结构已损坏，只能重建
最容易被忽略的是：交换后源表（被换出去的那个）可能还挂着旧的 MV Log，或者残留统计信息，建议在交换后清理其 MV Log（DROP MATERIALIZED VIEW LOG ON source_table;），避免干扰后续维护。
