物化视图刷新组必须显式创建，不能自动归组；需用dbms_refresh.make定义，成员须全为on demand模式、同实例、有select权限，且刷新失败不报错需主动核查状态。
物化视图刷新组必须显式创建，不能靠命名或位置自动归组
Oracle 不会根据物化视图名、所属 schema 或创建顺序自动把多个 MV 归入同一刷新组。刷新组（refresh group）是独立对象，必须用 DBMS_REFRESH.MAKE 显式定义并注册成员。漏掉这步，哪怕所有 MV 都设了 REFRESH FAST ON DEMAND，调用 DBMS_REFRESH.REFRESH 也只会报 ORA-12008: refresh group does not exist。
常见错误现象：建了 5 个 MV，都带 ON DEMAND，以为执行一次 DBMS_REFRESH.REFRESH('my_group') 就能批量刷——实际根本找不到组。
-
DBMS_REFRESH.MAKE必须在刷新组所有成员 MV 都已存在之后执行，且当前用户需对每个 MV 有SELECT权限（不是SELECT ANY TABLE） - 组名大小写敏感，且不能含特殊字符或空格；建议全大写、下划线分隔，如
'SALES_MV_GROUP' - 成员 MV 必须位于同一数据库实例内；跨 DB Link 的远程 MV 不能加入本地刷新组
- 若某 MV 刷新失败（如日志缺失、权限不足），整个组刷新会中断，不会跳过继续刷其余成员
刷新组内 MV 的刷新方式必须统一为 ON DEMAND
刷新组只支持 ON DEMAND 模式。哪怕组里某个 MV 定义为 REFRESH FAST ON COMMIT，它被加入刷新组后，ON COMMIT 行为失效——只有手动调用 DBMS_REFRESH.REFRESH 时才会触发，且按组内统一策略执行（即全部走 FAST 或全部退化为 COMPLETE）。
容易踩的坑：误以为组能“协调”不同刷新模式。实际上 Oracle 强制要求组内所有 MV 必须是 ON DEMAND，否则 DBMS_REFRESH.MAKE 直接报 ORA-12014: table 'xxx' does not contain a primary key constraint（这个错常误导人，本质是校验失败，非主键问题）。
- 建组前逐个确认：
SELECT REFRESH_MODE FROM DBA_MVIEWS WHERE MVIEW_NAME IN ('MV1','MV2')，结果必须全为DEMAND - 组内任意 MV 的
REFRESH FAST能力由其自身日志和定义决定；组不提供额外加速，只是批量调度入口 - 如果组里混了
COMPLETE和FASTMV，刷新时 Oracle 仍尝试对每个成员单独判断——FAST成员走增量，COMPLETE成员全量重算，不互相影响
DBMS_REFRESH.REFRESH 调用后不报错 ≠ 刷新成功
执行 DBMS_REFRESH.REFRESH('MY_GROUP') 返回无异常，不代表组内所有 MV 都更新到了最新状态。Oracle 把失败当作“跳过”，而非中断，且默认不抛出异常——你得主动查日志或状态。
典型静默失败场景：某个 MV 的基表日志字段缺失、远程 DB Link 密码过期、目标 MV 所在表空间满。这些都会导致该 MV 刷新失败，但组整体返回成功。
- 刷新后立刻查：
SELECT MVIEW_NAME, LAST_REFRESH_DATE, STALENESS FROM DBA_MVIEWS WHERE MVIEW_NAME IN ('MV1','MV2') AND REFRESH_MODE = 'DEMAND'，确认LAST_REFRESH_DATE是否更新 - 查失败记录：
SELECT * FROM DBA_REFSUMMARY WHERE REFRESH_GROUP = 'MY_GROUP' AND STATUS != 'SUCCESS'（需提前启用DBMS_REFRESH.ADD的日志选项） - 更可靠做法：在调用
DBMS_REFRESH.REFRESH前加EXCEPTION块捕获ORA-12008、ORA-12012等，并检查DBA_JOBS.LAST_DATE和FAILURES字段
刷新组无法替代物化视图日志的正确配置
很多人以为“建了刷新组就等于搞定增量刷新”，结果发现耗时暴涨。根本原因：刷新组只管调度顺序，不管底层是否真走增量路径。哪怕组内所有 MV 都标着 FAST，只要其中任一 MV 的日志缺失、字段不对齐、或查询含 DISTINCT，它就会静默降级为 COMPLETE 刷新，拖慢整组。
验证是否真走增量，不能看组调用是否成功，而要看日志表消费情况：
- 对每个基表，查
SELECT COUNT(*) FROM MLOG$_emp WHERE SNAPTIME$$ > (SELECT LAST_REFRESH_DATE FROM DBA_MVIEWS WHERE MVIEW_NAME = 'MV_EMP')，非零才说明有增量被消费 -
DBA_MVIEWS.CAN_USE_LOG = 'NO'是硬指标，出现即表示该 MV 当前无法 FAST 刷新，组再怎么调度也没用 - 组内 MV 数量建议控制在 5 个以内；超过后单次刷新失败概率陡增，且故障定位成本指数上升
