基表主键变更后物化视图fast刷新必然失败且静默退化为complete，因mlog$日志与mv定义中主键必须与当前基表primary key完全一致；重建需停刷、查依赖、重建日志、修正mv定义、启用row movement并设约束为deferrable。
基表主键变更后，物化视图fast刷新必然失败，且通常静默退化为complete——这不是配置问题，而是oracle元数据校验硬限制：物化视图日志和mv定义中引用的主键列必须与当前基表primary key完全一致，差一个字节都不行。
为什么ALTER TABLE ... DROP PRIMARY KEY后刷新就卡住
物化视图日志（MLOG$_表）在创建时已将主键列名、顺序、类型固化进内部结构；一旦基表主键被删或重建，DBA_MVIEW_LOGS.PRIMARY_KEY字段仍为'Y'，但实际约束已不存在。此时执行REFRESH FAST会直接报ORA-12052或静默 fallback 到 COMPLETE，而你查DBA_MVIEWS.STALENESS可能只看到STALE，毫无提示。
- 执行
SELECT * FROM DBA_MVIEW_LOGS WHERE MASTER = 'YOUR_TABLE'，确认PRIMARY_KEY = 'Y'但基表已无主键 → 日志失效 -
DBMS_MVIEW.EXPLAIN_MVIEW返回MSGNO = 2005（“no materialized view log with primary key”），说明Oracle已拒绝识别该日志 - 即使手动
ALTER TABLE ... ADD PRIMARY KEY补回，旧日志也不会自动适配新主键定义
重建日志前必须验证的三个依赖点
盲目DROP MATERIALIZED VIEW LOG可能让其他依赖同一日志的物化视图中断增量，务必先确认影响范围：
- 查复用关系：
SELECT LOG_TABLE, MASTER, LOG_OWNER FROM USER_MVIEW_LOGS WHERE MASTER = 'YOUR_TABLE'，看是否被多个MVIEW_NAME共享 - 检查是否有ON COMMIT MV正在运行：
SELECT MVIEW_NAME FROM DBA_MVIEWS WHERE REFRESH_MODE = 'COMMIT' AND MASTER_TABLE = 'YOUR_TABLE' - 确认基表当前主键是否被物化视图SQL完整引用：若MV定义是
SELECT col_a, SUM(col_b) FROM t GROUP BY col_a，而新主键是(col_a, col_c)，但col_c不在SELECT里 → 即使日志重建也白搭
重建日志与MV的正确顺序
顺序错一步，就会陷入“日志重建了但MV仍刷不动”的死循环：
- 先停掉所有依赖该日志的调度任务或ON COMMIT刷新，避免中间态写入
- 用
CREATE MATERIALIZED VIEW LOG ON your_table WITH PRIMARY KEY, SEQUENCE(col_a, col_b, col_c) INCLUDING NEW VALUES重建日志——SEQUENCE必须显式列出新主键所有列+MV中所有被引用列（含WHERE条件列、JOIN列） - 如果MV定义未包含新主键全列，必须先
ALTER MATERIALIZED VIEW your_mv_name COMPILE并修正SQL，否则REFRESH FAST仍会失败 - 最后执行
EXEC DBMS_MVIEW.REFRESH('your_mv_name', 'F')，观察DBA_MVIEWS.LAST_REFRESH_DATE和耗时是否回归正常量级
主键变更后还容易漏掉的两个关键点
即使日志和MV都重建成功，以下两点不处理，下次分区操作或大批量DML仍会触发隐性失败：
-
ROW MOVEMENT必须开启：ALTER TABLE your_table ENABLE ROW MOVEMENT，否则后续SPLIT PARTITION或EXCHANGE PARTITION会导致日志记录的ROWID失效，FAST刷新悄悄跳过变更行 - 物化视图上的唯一约束要设为
DEFERRABLE：ALTER TABLE your_mv_name MODIFY CONSTRAINT uk_mv_name DEFERRABLE INITIALLY DEFERRED，否则UPDATE多行交换主键值时（如互换两行name字段），FAST刷新过程中的中间状态会违反约束并报ORA-00001
主键变更不是简单DDL操作，它会撕裂物化视图整个增量链路的元数据一致性。最稳妥的做法永远是：先停刷、再查依赖、重建日志、修正MV定义、开ROW MOVEMENT、加延迟约束——少一个环节，都可能让下一次刷新在凌晨三点默默变成全量。
