oracle物化视图含lob列时完全不支持fast刷新，因日志机制无法捕获lob增量变更，仅允许complete刷新；必须剔除lob列或改用应用层缓存。
因为物化视图日志（MLOG$）根本无法捕获LOB列的增量变更，不是配置问题，而是Oracle底层机制硬性限制。
物化视图日志不记录LOB变更是设计行为
Oracle的物化视图日志只记录普通标量列（如NUMBER、VARCHAR2）的DML变更，而CLOB/BLOB通过独立的LOB locator机制更新，不触发常规行级日志写入。即使你在CREATE MATERIALIZED VIEW LOG里显式列出LOB列，日志表也不会存它的值或变化标记——除非加INCLUDING NEW VALUES，但那也只对FOR UPDATE日志生效，且仍无法支撑FAST刷新所需的精确行变更定位。
-
INCLUDING NEW VALUES会让日志表多存一份LOB内容（或locator），体积暴增，但FAST刷新逻辑本身不消费它 - 基表有LOB列 →
DBMS_MVIEW.EXPLAIN_MVIEW中CAPABILITY_NAME = 'REFRESH_FAST'的POSSIBLE字段直接为'N'，MSGTXT通常为空或仅提示“complex query” - 错误往往在创建时就暴露：
ORA-12015: cannot create a fast refresh materialized view from a complex query
为什么不能靠“不SELECT LOB列”绕过限制？
只要基表定义含LOB字段，哪怕物化视图SELECT里只取ID和NAME，FAST刷新仍被禁用。Oracle检查的是基表元数据，不是MV查询投影列表。
- 查
USER_MVIEWS里的CONTAINERS字段：若为'YES'（表示含LOB列），REFRESH_METHOD只能是'COMPLETE' - 试图执行
DBMS_MVIEW.REFRESH(..., METHOD => 'F')会报ORA-12004: REFRESH FAST cannot be used for this materialized view - 连
ON COMMIT刷新都不可用——LOB存在时，该策略直接被忽略
替代方案必须放弃FAST刷新路径
没有“修复LOB支持”的配置项，只有两种务实选择：
- 从物化视图定义中彻底剔除LOB列：
SELECT id, name FROM t（而非SELECT id, name, content FROM t），再通过主键关联原表查LOB - 改用应用层缓存：当LOB更新低频（如文档每月一改），用普通视图+Redis/Memcached比维护一个COMPLETE刷新的MV更轻量
- 若必须保留LOB且要降低刷新开销，只能用
ATOMIC_REFRESH => FALSE加速COMPLETE刷新，但需接受刷新期间MV短暂不可用（ORA-00942）
最容易被忽略的一点：错误日志里不会明说“因为有LOB”，EXPLAIN_MVIEW输出里也看不到LOB字样。你得先确认基表是否存在LOB列，再看REFRESH_FAST.POSSIBLE = 'N'，否则可能花几小时排查子查询或外连接，却漏掉这个最硬的约束。
