DBMS_MVIEW.REFRESH 默认按物化视图元数据中的方式（通常为FAST）刷新，非强制；显式指定 method => 'C' 才实现全量重建、绕过日志依赖，最可靠但耗资源。
不加 method 参数就不是强制刷新
DBMS_MVIEW.REFRESH 默认走物化视图元数据里记的刷新方式（通常是 FAST），而不是“强制”。如果你没传 method，它不会自动 fallback 到全量；一旦基表日志缺失、损坏或中断，FAST 就会静默失败或报 ORA-12008，看起来像没刷——但其实刷了，只是什么都没干。
真正接近“强制”的语义是显式指定 method => 'C'（COMPLETE），它会丢弃旧数据、重新执行定义查询，绕过日志依赖。
-
method => 'C'：全量重建，最可靠，但锁表、占空间、慢 -
method => 'F'：只增量，必须有有效日志，且所有基表日志都得存在、未截断 -
method => '?（FORCE）：先试F，失败再切C；但注意，它仍可能因权限或日志状态卡在F阶段不报错 - 别写
'FAST'或小写'f'—— Oracle 只认单字符，'f'和'F'都行，但'fast'直接报ORA-06550
list 参数写错就找不到物化视图
哪怕只刷一个，list 也必须是字符串，且推荐用 'OWNER.MVIEW_NAME' 格式。只写 'MV_NAME' 时，Oracle 会按当前 current_schema 解析，如果不在对应 schema 下，就会报 ORA-00942: table or view does not exist —— 这个错误不是物化视图真不存在，而是解析路径错了。
- 跨 schema 刷新必须带 owner，比如
'SCOTT.EMP_MV' - 名字含大小写或特殊字符，要用双引号包裹：
'"My_MV_With_Upper"' - 批量刷新用逗号拼接：
'SCOTT.EMP_MV,HR.DEPT_MV'，不能传数组、集合或换行 - DBLink 上的物化视图，不能在
list里写@dblink；刷新操作必须在目标库本地执行
atomic_refresh => FALSE 能防卡死，但要接受短暂不一致
默认 atomic_refresh => TRUE 意味着整个刷新在一个事务里完成：TRUNCATE + INSERT /*+ APPEND */ 全部成功才提交。对大物化视图，这会导致长时间锁表、undo 爆涨、甚至触发 ORA-01555。
设成 FALSE 后，Oracle 改为分步提交（例如每 5000 行 commit 一次），大幅降低锁持有时间和 undo 压力。但它带来的代价是：刷新过程中，物化视图可能处于中间态——SELECT 可能查到部分新数据 + 部分旧数据。
- 仅当物化视图不依赖
ON COMMIT刷新时才能安全启用 - 不要和
ATOMIC_REFRESH => TRUE混用（后者是旧参数名，已废弃） - 搭配
refresh_after_errors => TRUE可让批量刷新中某个失败不影响其余
常见失败原因比语法更关键
90% 的刷新失败不是因为写错 PL/SQL，而是环境或定义层面的问题没暴露出来：
-
ORA-01031: insufficient privileges→ 缺少REFRESH ANY MATERIALIZED VIEW（跨 schema）或REFRESH MATERIALIZED VIEW（本 schema）权限 -
ORA-12034: materialized view log younger than last refresh→ 日志被 purge 过或没建，或建得太晚（必须在首次 FAST 刷新前存在） -
ORA-12053: this is not a valid nested table or materialized view→ 物化视图被设成了REFRESH NEVER，需先ALTER MATERIALIZED VIEW ... REFRESH COMPLETE ON DEMAND - 外键约束干扰 → 物化视图表上建了外键，刷新时 INSERT 可能违反引用完整性；建议物化视图表不加外键
最常被忽略的一点：COMPLETE 刷新虽然“强制”，但它重建过程本身依赖临时段和 undo 表空间容量。如果基表 30GB，没预留足够空间，刷新会直接报 ORA-01652，而不是提示空间不足。
