根本原因是fast刷新条件不满足，oracle自动降级为complete；需检查日志是否含rowid/sequence/including new values、查询是否含禁用结构，并用explain_mview查msgtxt定位具体规则缺失。
FAST刷新失败退化为COMPLETE，查日志和查询定义
物化视图本该快速刷新，却每次都在重跑全量查询，根本原因是FAST条件不满足，Oracle自动降级为COMPLETE。这不是配置问题，而是硬性限制触发的退化行为。
- 检查物化视图日志是否存在且完整：
SELECT * FROM USER_MVIEW_LOGS WHERE MASTER = 'YOUR_TABLE'；日志必须含ROWID、SEQUENCE、INCLUDING NEW VALUES，且所有SELECT列（含表达式列，如TRUNC(CREATED_DATE, 'MM')）都得显式ADD COLUMN - 确认查询中没用禁用FAST的结构：比如
ANALYTIC FUNCTION（ROW_NUMBER()等）、UPPER(id)这类非确定性函数、或未直接引用主键列（而用id+0之类计算） - 执行
DBMS_MVIEW.EXPLAIN_MVIEW('MV_NAME')，查MSGTXT字段——它会明确告诉你哪条规则不满足，比如"fast refresh not possible on table"
REFRESH_ALL_MVIEWS批量刷反而更慢，改用REFRESH_DEPENDENT
DBMS_MVIEW.REFRESH_ALL_MVIEWS在21c里虽可用，但默认按字典顺序刷，不保证依赖拓扑，一个下游MV刷失败可能卡住整批，且默认refresh_method => 'C'，对大MV就是灾难。
- 优先用
DBMS_MVIEW.REFRESH_DEPENDENT：传入基表名，它自动逆向遍历依赖链，按正确顺序刷新所有下游MV，避免错序失败 - 若真要全刷，显式指定
refresh_method => 'F'，并设rollback_seg => NULL（传非NULL值会报ORA-00904） - 加异常捕获：每个MV单独调用
DBMS_MVIEW.REFRESH，失败时记录SQLERRM和MV名，别让一个失败中断全部
分区物化视图不走分区裁剪，建时必须显式PARTITION BY
基表是按SALES_DATE范围分区的，但物化视图查询还是全表扫，说明物化视图本身没分区——Oracle不会自动继承基表分区结构，优化器无法做裁剪。
- 创建时必须带
PARTITION BY RANGE(sales_month)子句（12c+支持），且分区键类型、边界值（如VALUES LESS THAN (DATE '2025-01-01')）要和基表严格一致 - 如果基表分区键是表达式（如
TRUNC(SALES_DATE, 'MM')），物化视图也得用同样表达式作分区键，不能只用原始列 - 建完立刻收集统计信息：
DBMS_STATS.GATHER_TABLE_STATS，否则优化器看不到分区分布，仍选错执行计划
RAC环境下刷新锁竞争导致查询抖动
刷新本身不阻塞查询（Oracle MVCC机制保障旧快照可读），但REFRESH_ALL_MVIEWS内部会对每个MV加TM锁，若同时有ETL写基表，极易触发锁等待，拖慢所有并发查询。
- 避开业务高峰执行刷新；设
refresh_after_errors => FALSE（默认值），防止一个MV失败后继续锁后续MV - 监控锁状态：
SELECT * FROM gv$lock WHERE type = 'TM' AND id1 IN (SELECT object_id FROM dba_objects WHERE object_type = 'TABLE' AND object_name IN (SELECT mview_name FROM dba_mviews)) - 高频写场景下，考虑把物化视图建在Active Data Guard只读备库上，主库只负责DML，刷新完全隔离
真正卡顿往往不在“刷不出来”，而在“刷得太猛”——资源争抢、依赖错序、分区失效、锁堆积，这些细节比选哪个刷新方式更决定实际性能。
