UNION（含UNION ALL）直接禁用快速刷新，是Oracle内核级硬限制；因其破坏单源行映射，导致增量变更无法准确定位，故REFRESH_FAST_POSSIBLE恒为'N'，无绕过机制，必须重构SQL或改用COMPLETE刷新。
union（含union all）直接禁用快速刷新，oracle不提供绕过机制——这不是配置问题，是内核级硬限制。
UNION导致REFRESH_FAST_POSSIBLE = 'N'的底层原因
Oracle快速刷新依赖物化视图日志（MLOG$_）记录每行DML的精确变更类型（INSERT/UPDATE/DELETE）和行定位（ROWID）。UNION操作天然破坏“单源行映射”：同一结果行可能来自多个基表，且无确定性归属；删除某行时，系统无法判断该行原始来自哪个分支、是否已被其他分支覆盖。这种不确定性让增量计算不可靠，所以Oracle在语法解析阶段就直接标记REFRESH_FAST为POSSIBLE = 'N'，不进入后续日志或约束校验。
- DBMS_MVIEW.EXPLAIN_MVIEW输出中，
CAPABILITY_NAME = 'REFRESH_FAST'对应行的POSSIBLE列必为'N'，且MSGTXT通常显示"UNION ALL"或"set operator not supported" -
RECOMMENDATION字段明确写UNION ALL，不是建议，是判决依据 - 即使所有基表都建了完整日志、每个SELECT分支都满足快速刷新条件，UNION本身仍触发硬拦截
替代方案：用JOIN模拟UNION逻辑（有限适用）
若两个分支查询结构一致（同列数、同类型、可对齐），且业务允许重写，可用FULL OUTER JOIN + CASE替代UNION ALL。但必须满足：
- 两个基表必须有唯一可连接键（如主键），且该键在物化视图SELECT中显式出现
- JOIN条件不能含OR、函数或非等值判断，否则触发
MSGNO = 2031 - 每个分支的WHERE过滤条件需拆解为JOIN ON子句的一部分，不能留在外层WHERE
- 最终SELECT必须包含两个基表的
ROWID（如t1.ROWID t1_rid, t2.ROWID t2_rid），否则MSGNO = 2012
示例片段：
SELECT COALESCE(t1.id, t2.id) id,<br> CASE WHEN t1.id IS NOT NULL THEN t1.name ELSE t2.name END name,<br> t1.ROWID t1_rid, t2.ROWID t2_rid<br>FROM table1 t1<br>FULL OUTER JOIN table2 t2 ON t1.id = t2.id<br>WHERE (t1.id IS NOT NULL AND t1.status = 'A')<br> OR (t2.id IS NOT NULL AND t2.status = 'B')→ 实际仍会因WHERE中的OR失败，需改写为：
ON (t1.id = t2.id)<br>AND ((t1.id IS NOT NULL AND t1.status = 'A') OR (t2.id IS NOT NULL AND t2.status = 'B'))但此写法极难保证语义等价，慎用。
真正可行的落地选择：COMPLETE刷新 + 定时窗口控制
当UNION逻辑不可重构时，放弃FAST是更稳的选择。关键点在于避免锁表和长事务：
- 强制使用
ATOMIC_REFRESH => FALSE：刷新时先建新表再原子替换，不锁原MV表，应用侧无感知 - 配合分区交换：若MV表按时间分区，可预建新分区、加载数据、再
EXCHANGE PARTITION，刷新窗口缩至秒级 - 调度避开业务高峰：用
DBMS_SCHEDULER而非ON COMMIT，并设置MAX_RUN_DURATION防任务卡死 - 监控
DBA_MVIEWS.STALENESS：若值为STALE，说明上次COMPLETE未完成，需人工介入而非等待自动重试
为什么EXPLAIN_MVIEW不能给出“修复建议”
UNION属于语法层不可协商限制，不是缺失日志或漏ROWID这类可补救项。Oracle的DBMS_MVIEW.EXPLAIN_MVIEW只解释“为什么不行”，不提供“怎么改才能行”——因为根本没路。你看到QSM-01106错误码和RECOMMENDATION = 'UNION ALL'，就意味着必须回到SQL源头做架构级调整：要么拆成多个独立MV，要么接受COMPLETE刷新，要么把UNION逻辑移到应用层聚合。任何试图加日志、加索引、改参数的操作，都是在已知死路上多绕一圈。
