oracle不自动处理聚合物化视图嵌套依赖，dbms_mview.refresh(list=>...)严格按列表顺序执行，错序即报ora-12008；nested=>true在多mv批量刷新中完全失效，仅单mv刷新且满足build immediate+on demand时才可能递归刷新。
不能靠 nested => true 自动实现多级聚合嵌套刷新，必须手动拆解依赖链并分组调度。
为什么 DBMS_MVIEW.REFRESH(list => ...) 不会自动处理聚合 MV 的嵌套依赖
Oracle 对含 SUM/COUNT 的物化视图不做拓扑排序，DBMS_MVIEW.REFRESH 传入 list 后严格按字符串顺序执行。比如你写 list => 'mv_qtr_sum,mv_yr_sum'，而 mv_yr_sum 实际依赖 mv_qtr_sum 的结果，但 Oracle 不检查这个关系——它先刷 mv_yr_sum，查不到新鲜的季度数据，直接报 ORA-12008。
更关键的是：nested => TRUE 在这种场景下完全不生效。它只在单 MV 刷新（如 DBMS_MVIEW.REFRESH('mv_yr_sum', nested => TRUE)）且所有依赖都是 BUILD IMMEDIATE + ON DEMAND 时，才可能顺带刷掉未 stale 的底层 MV；一旦你传 list，它就彻底失效。
- 验证依赖：运行
SELECT * FROM DBA_DEPENDENCIES WHERE NAME IN ('MV_QTR_SUM','MV_YR_SUM') AND TYPE = 'MATERIALIZED VIEW' - 确认每个 MV 的构建方式：
SELECT mview_name, build_mode, refresh_mode FROM user_mviews，混用ON COMMIT会直接让nested => TRUE失效 - 聚合 MV 必须全部是
ON DEMAND，否则无法纳入同一刷新组
支持多级聚合的物化视图必须满足的日志与定义硬约束
哪怕依赖顺序对了，日志或定义错一个字，REFRESH FAST 就会静默降级为完全刷新，或者直接报 ORA-12052、ORA-32320。
核心三点必须同时满足：
-
COUNT(*)必须显式出现在 SELECT 列表中，COUNT(1)或COUNT(sales_amt)都不行 - 基表上的物化视图日志必须含
WITH ROWID, SEQUENCE (sale_date, product_id, sales_amt) INCLUDING NEW VALUES——漏掉INCLUDING NEW VALUES是最常见错误，UPDATE 场景下增量修正直接失效 - 物化视图定义里所有 GROUP BY 列、所有被 SUM/AVG 等函数读取的列，都必须出现在日志的
SEQUENCE括号内；例如SUM(sales_amt)→sales_amt必须进SEQUENCE
查日志是否达标：SELECT COLUMN_NAME FROM USER_MVIEW_LOG_FILTER_COLS WHERE LOG_TABLE = 'MLOG$_SALES'，结果里必须包含你 MV 中用到的所有非主键字段。
如何安全配置链式刷新组（REFRESH GROUP）来驱动多级聚合
把多个聚合 MV 塞进一个刷新组不是为了“省事”，而是为了强制串行执行。但 Oracle 不校验依赖，所以顺序必须人工排好，且组名、调度参数稍有不慎就会失败。
- 建组前先查重：
SELECT * FROM DBA_REFRESH_GROUPS WHERE REFRESH_GROUP = 'AGG_MV_GRP'；若存在，必须先DBMS_REFRESH.DESTROY('AGG_MV_GRP')，MAKE不支持覆盖 - list 参数顺序 = 执行顺序：
list => 'SCOTT.MV_MONTH_SUM, SCOTT.MV_QTR_SUM, SCOTT.MV_YR_SUM'，确保被依赖者永远在前 -
next_date和interval要一致：比如next_date => TRUNC(SYSDATE)+1+6/24（明早6点），interval => 'TRUNC(SYSDATE)+1+6/24'；绝不能用'SYSDATE+1/24'，否则刷新间隔会漂移 - RAC 环境下禁用本地路径操作：如果某个 MV 刷新逻辑里调了
UTL_FILE.FOPEN('/tmp/log.txt')，而该路径只在 node1 挂载，任务跑 node2 就直接失败
刷新失败后状态判断与修复路径
MV 刷挂了，状态不是统一的“坏”，不同标记对应完全不同操作：
-
STALE：数据过期但结构完好，直接重刷即可，最安全 -
UNUSABLE：结构损坏（比如基表删了sales_amt字段），必须先ALTER MATERIALIZED VIEW mv_yr_sum COMPILE，否则任何刷新都报ORA-12008 -
NEEDS_COMPILE：仅编译单元失效（如依赖的函数被改名），不影响数据，但不COMPILE就无法刷新
统一查状态：SELECT mview_name, staleness, compile_state FROM user_mviews WHERE mview_name IN ('MV_MONTH_SUM','MV_QTR_SUM','MV_YR_SUM')。最容易被忽略的是 UNUSABLE 状态——它不会阻止你建刷新组，但第一次执行时必然中断，且错误日志里往往只提示“refresh path error”，不直接说哪张 MV 不可用。
