Oracle不自动按依赖排序物化视图刷新顺序，DBMS_MVIEW.REFRESH(list=>...)严格按列表从左到右执行，错序导致ORA-12008；nested=>TRUE仅在单MV刷新且所有依赖均为BUILD IMMEDIATE、ON DEMAND时才递归刷新依赖。
oracle 不会自动按依赖关系排序多个物化视图的刷新顺序，dbms_mview.refresh 传入列表时严格按你写的顺序执行——错序直接报 ora-12008；所谓“嵌套刷新”仅对单个 mv 生效，且有硬性前提。
为什么 DBMS_MVIEW.REFRESH(list => ...) 不按依赖刷
Oracle 在批量刷新时不做拓扑排序，只机械执行 list 中从左到右的顺序。哪怕 mv_top 明确依赖 mv_mid，而 mv_mid 又依赖 mv_base，如果你写成 list => 'mv_top,mv_mid,mv_base'，它就先刷顶层，必然失败。
- 错误现象：
ORA-12008: error in materialized view refresh path，伴随日志里提示某依赖 MV 状态为STALE或UNUSABLE - 根本原因：底层 MV 还没刷，上层 MV 查询时读不到新鲜数据或结构已失效
- 验证方式：对每个 MV 单独运行
DBMS_MVIEW.EXPLAIN_MVIEW('mv_name')，查输出中REFRESH_DEP字段或mv_capabilities_table表里的依赖行 - 安全做法：手动整理依赖链，生成「被依赖者优先」的刷新列表，例如
'mv_base,mv_mid,mv_top'
nested => TRUE 只在单 MV 刷新时有效
nested => TRUE 的作用范围非常有限：它只在你调用 DBMS_MVIEW.REFRESH('mv_top', nested => TRUE) 这种单个 MV 刷新时，才可能顺带把 mv_top 所依赖但尚未刷新的 mv_mid 和 mv_base 一并刷掉。
- 前提条件苛刻：所有依赖 MV 必须是
BUILD IMMEDIATE（不能DEFERRED），且全部为ON DEMAND模式（混ON COMMIT会失效） - 触发条件隐蔽：只有当依赖 MV 当前是
STALE状态、又没被显式列在本次 list 中，nested => TRUE才会补刷；如果它压根没 stale，就不会动 - 多 MV 场景下完全不生效：传
list => 'mv_a,mv_b'时，刷mv_b不会因为依赖mv_a就去刷mv_a，哪怕nested => TRUE开了也没用
刷新失败后状态怎么分辨和修复
中断后的 MV 状态不是统一的“坏”，不同错误导致不同标记，处理方式完全不同：
-
STALE：数据过期但定义完好，可直接重刷，最常见也最安全 -
UNUSABLE：结构损坏（如基表删了字段、约束冲突），必须先执行ALTER MATERIALIZED VIEW mv_name COMPILE，否则任何刷新都报ORA-12008 -
NEEDS_COMPILE：仅编译单元失效（比如依赖的函数被改了），不影响数据，但不COMPILE就无法刷新 - 统一查状态：
SELECT mview_name, staleness, compile_state FROM user_mviews
依赖链越长，手动排序越容易漏；nested => TRUE 看似省事，实则埋坑——它只在单点调用、全链满足前提时才起作用，一旦环境稍有偏差（比如某个 MV 是 BUILD DEFERRED），就会静默失效，导致你以为刷成功了，其实底层卡在 STALE。真要可靠，老老实实按 EXPLAIN_MVIEW 输出排顺序，别信“自动”二字。
