强制触发物化视图完全刷新需显式调用DBMS_MVIEW.REFRESH('mv_name', method => 'C')，默认不锁表，加lock_for_refresh => TRUE才阻塞DML；ON COMMIT模式下method => 'C'被忽略，仅支持FAST刷新。
物化视图 REFRESH COMPLETE 怎么强制触发
直接执行 dbms_mview.refresh 并指定 'c' 模式，就能绕过增量逻辑、强制走完全刷新。但注意：它不会自动加锁或阻塞 dml，除非你显式传入 lock_for_refresh => true。
常见错误是只写 DBMS_MVIEW.REFRESH('mv_name')，默认行为取决于物化视图的刷新属性（可能是 FAST），根本不会触发完全刷新。
- 必须显式传参
method => 'C'，例如：EXEC DBMS_MVIEW.REFRESH('sales_mv', method => 'C'); - 如果基表正在被大量修改，建议加上
lock_for_refresh => TRUE，否则可能遇到ORA-12008: error in materialized view refresh path或快照太旧问题 - 在 RAC 环境下，
method => 'C'会自动协调所有实例，无需额外处理
ON COMMIT 物化视图能强制 COMPLETE 刷新吗
不能。只要刷新模式设为 ON COMMIT，Oracle 就只允许 FAST 刷新，内部会忽略你传的 method => 'C'。这是硬限制，不是配置疏漏。
如果你需要每次提交后都重建全量数据，说明设计上就不该用 ON COMMIT —— 它本质是为低延迟增量同步服务的。
- 检查当前定义：
SELECT refresh_method, build_mode FROM user_mviews WHERE mview_name = 'SALES_MV';
- 若
refresh_method是FORCE或COMPLETE，才可能手动触发完全刷新 - 想“模拟”提交即全刷？只能改成
ON DEMAND+ 触发器调用DBMS_MVIEW.REFRESH(..., 'C')，但要注意事务边界和锁竞争
COMPLETE 刷新卡住或超时，常见堵点在哪
不是 SQL 慢，而是锁和依赖链。最常卡在基表上的 DML 锁、物化视图日志锁，或者刷新过程中对 SNAPSHOT LOG 的争用。
尤其当物化视图基于多张表且其中一张正被大事务更新时，REFRESH COMPLETE 会等那个事务结束才开始 truncate+insert，而不是并行构建。
- 查阻塞源：
SELECT blocking_session, event FROM v$session WHERE sid = (SELECT sid FROM v$access WHERE object = 'SALES_MV');
- 避免在业务高峰跑
COMPLETE刷新；如必须，提前在基表上加SELECT FOR UPDATE预占锁（慎用） - 如果基表有物化视图日志，
COMPLETE仍会去读它（只为判断是否可转 FAST），此时日志过大也会拖慢启动阶段
为什么 ATOMIC_REFRESH => FALSE 能显著提速
默认 ATOMIC_REFRESH => TRUE 会让 Oracle 把 truncate 和 insert 包在一个事务里，全程锁住物化视图。而设为 FALSE 后，先 drop 再 create 表，释放锁更快，且支持并行 insert。
代价是刷新期间查询物化视图会报 ORA-00942: table or view does not exist —— 所以只适合能接受短暂不可用的场景，比如夜间批处理。
- 安全提速写法：
EXEC DBMS_MVIEW.REFRESH('sales_mv', method => 'C', atomic_refresh => FALSE); - 注意：该参数对
ON COMMIT物化视图无效，仅适用于ON DEMAND - 如果物化视图带 query rewrite，
atomic_refresh => FALSE可能导致 rewrite 失效几秒，需配合DBMS_MVIEW.EXPLAIN_REWRITE验证
真正麻烦的不是怎么写那条 refresh 命令，而是得想清楚：这个“强制完全刷新”背后，是不是暴露了基表变更不可控、物化视图日志没维护、或者本就不该用物化视图来承接这类需求。
