根本原因是物化视图日志（mlog$_xxx）未同步新增列，导致fast刷新失效而静默降级为complete，引发锁表、超时或ora-12054；需alter materialized view log add列、启用including new values并compile物化视图。
alter table 增加列后物化视图刷新异常，根本原因不是“新增列”本身触发了错误，而是物化视图日志（mlog$_xxx）未同步更新，导致快速刷新（fast）所需的关键字段缺失，从而静默降级为 complete 刷新，进而引发锁表、超时或 ora-12054 等现象。
MLOG$_xxx 表没自动包含新列，FAST 刷新直接失效
物化视图日志是独立对象，不会随基表 DDL 自动演进。当你执行：
ALTER TABLE sales ADD (region_code VARCHAR2(10));
MLOG$_SALES 仍只含建日志时定义的列（如 ROWID、SNAPTIME$$、SEQUENCE$$ 等），但不包含 REGION_CODE。而如果物化视图定义中引用了该列（例如 SELECT prod_id, region_code, SUM(amount) FROM sales GROUP BY prod_id, region_code），Oracle 在 FAST 刷新时会检查日志是否记录该列变更——查不到就判定“无法增量”，强制 fallback 到 COMPLETE。
-
常见表现：
- 刷新耗时陡增（从秒级变分钟/小时级）
-
v$locked_object显示基表被长时间持有TM锁（因COMPLETE需DELETE+INSERT） -
DBA_MVIEWS.STALENESS仍为STALE，但手动REFRESH('MV_NAME', 'F')报ORA-12054（"cannot assign to a column in a materialized view log"）
-
实操建议：
- 不要重建日志（会清空未消费变更）；应 显式添加列到现有日志：
ALTER MATERIALIZED VIEW LOG ON sales ADD (region_code);
- 若提示“not supported”，说明日志类型受限（如只建了
WITH PRIMARY KEY），需先DROP再重建，但必须先确认无其他 MV 复用该日志 - 执行后验证：
SELECT column_name FROM dba_mview_log_filters WHERE log_owner = 'YOUR_SCHEMA' AND log_table = 'MLOG$_SALES';
- 不要重建日志（会清空未消费变更）；应 显式添加列到现有日志：
新增列含 NOT NULL 或默认值时，INCLUDING NEW VALUES 必须启用
如果新增列带 NOT NULL 约束或 DEFAULT，且基表已有历史数据，那么后续的 INSERT 或 UPDATE 可能产生“隐式值写入”。此时若日志未启用 INCLUDING NEW VALUES，这些变更将完全不被捕获，FAST 刷新永远缺失这部分数据。
-
查当前日志是否启用：
SELECT including_new_values FROM user_mview_logs WHERE master = 'SALES';
返回
'NO'就是隐患。 -
修复方式（仅当确认无其他依赖该日志的 MV）：
DROP MATERIALIZED VIEW LOG ON sales; CREATE MATERIALIZED VIEW LOG ON sales WITH PRIMARY KEY, ROWID, SEQUENCE, INCLUDING NEW VALUES (prod_id, region_code, amount); -- 显式列出所有需捕获的列
物化视图定义未重新编译，元数据与日志不匹配
即使日志已更新，若物化视图本身在新增列后未 COMPILE，其内部元数据仍认为“REGION_CODE 不在基表中”，导致 EXPLAIN_MVIEW 报 DISABLED，且刷新时可能跳过校验直接失败。
-
检查状态：
SELECT mview_name, staleness, compile_state FROM dba_mviews WHERE mview_name = 'MV_SALES_BY_REGION';
若
COMPILE_STATE是NEEDS_COMPILE，必须立刻处理。 -
强制重编译：
ALTER MATERIALIZED VIEW mv_sales_by_region COMPILE;
注意：这不会刷新数据，只修正元数据；之后再手动触发一次
REFRESH('MV_NAME', 'F')。
真正卡住人的地方，往往不是“加列”这个动作，而是日志没跟上、INCLUDING NEW VALUES 没开、或者忘了 COMPILE —— 三者任一缺失，都会让 Oracle 在后台悄悄放弃 FAST，转而扛着锁跑全量，直到你看到应用报 ORA-00054 或监控里 I/O 突然拉满。
