SPLIT PARTITION不被捕获，因属DDL而非DML，导致物化视图日志失效、STALENESS变为UNUSABLE；必须先ALTER MATERIALIZED VIEW COMPILE，再重建日志并刷新。
物化视图日志不捕获SPLIT PARTITION，必须重建
SPLIT操作默认绕过物化视图日志（MLOG$_xxx），哪怕日志已建且含INCLUDING NEW VALUES，也不会记录新分区的行变更。这是Oracle设计使然：SPLIT是DDL，不是DML，日志机制只监听INSERT/UPDATE/DELETE。结果就是REFRESH FAST找不到差异行，要么卡住，要么退化为COMPLETE并报ORA-12008或ORA-12054。
验证是否失效：
- 查日志表数据量：
SELECT COUNT(*) FROM MLOG$_base_table，若基表刚执行过SPLIT且后续有DML，但该值长期为0，说明捕获已断 - 查日志对象状态：
SELECT status FROM dba_objects WHERE object_name = 'MLOG$_base_table'，若为INVALID，必须重建
重建命令（覆盖原日志）：
CREATE MATERIALIZED VIEW LOG ON base_table WITH PRIMARY KEY, ROWID, SEQUENCE INCLUDING NEW VALUES;
STALENESS变成UNUSABLE后不能直接刷新
SPLIT后DBA_MVIEWS.STALENESS常变为UNUSABLE，这不是刷新失败，而是元数据失效——Oracle无法再安全推导增量路径，拒绝所有FAST请求。此时跳过COMPILE直接调用DBMS_MVIEW.REFRESH会静默失败。
必须按顺序执行：
- 先查状态：
SELECT MVIEW_NAME, STALENESS, STALENESS_REASON FROM DBA_MVIEWS WHERE MVIEW_NAME = 'YOUR_MV_NAME' - 若
STALENESS = 'UNUSABLE'，立即执行：ALTER MATERIALIZED VIEW your_mv_name COMPILE - 再刷新：
EXEC DBMS_MVIEW.REFRESH('your_mv_name', 'F')
分区键表达式变更会隐式破坏日志兼容性
如果SPLIT时修改了分区键表达式（例如从sale_date改为TRUNC(sale_date, 'MM')），即使表结构没变，物化视图日志仍会失效。因为日志依赖建表时的分区键快照，而物化视图定义中引用的列或表达式一旦与日志不匹配，FAST刷新就会触发ORA-12032或ORA-12054。
排查要点：
- 确认
DBA_MVIEW_LOGS中MASTER列对应表的分区键是否被ALTER TABLE重定义过 - 检查物化视图SQL里是否用了函数包装分区键（如
TO_CHAR(sale_date, 'YYYYMM')），这类写法会让日志无法对齐物理行 - 若已变更，重建日志是唯一可靠方式，且需同步更新物化视图定义中涉及该列的所有表达式
外键关联的父表未刷新会导致ON COMMIT失败
若物化视图含分区子表与非分区父表的外键JOIN（如sales_detail外键指向product），SPLIT后首次REFRESH FAST ON COMMIT大概率报ORA-12008 + ORA-02291。根本原因不是数据缺失，而是Oracle在提交时校验外键约束，但父表数据尚未刷入MV。
临时解法（仅限紧急恢复）：
- 改用
REFRESH FAST ON DEMAND，手动控制顺序：EXEC DBMS_MVIEW.REFRESH('mv_product', 'F'); EXEC DBMS_MVIEW.REFRESH('mv_sales_detail', 'F'); - 禁止在子表MV中用
WHERE过滤分区（如WHERE sale_date >= ADD_MONTHS(SYSDATE,-3)），否则外键列值在MV中“残缺”，约束检查必败 - 长期方案：把父表关键列显式加入子表MV定义，或改用SELECT子查询包裹外键字段（如
NVL((SELECT p.name FROM product p WHERE p.id = s.prod_id), 'UNKNOWN')）
最易被忽略的是：SPLIT本身不修改数据，但会重置分区级统计信息和日志偏移点，导致后续所有FAST刷新都基于错误的“起点”。重建日志+COMPILE+手动顺序刷新，三步缺一不可。
