分区大表不能用 REFRESH ON COMMIT，因其要求基表有主键、所有连接/过滤列被索引，而分区键常缺乏全局唯一约束与索引；物化视图日志需显式指定 SEQUENCE 和 INCLUDING NEW VALUES，且含聚合或连接时直接报错 ORA-12052；FAST REFRESH + 分区感知调度才是可行路径。
REFRESH ON COMMIT 在分区大表上根本不可用——它不支持跨分区键的复杂查询，也不兼容多数分区策略下的物化视图日志机制。Oracle 19c 没有“实时物化视图”，所谓“实时”只能靠组合手段逼近秒级延迟，且必须放弃 ON COMMIT 这条路径。
为什么分区大表不能用 REFRESH ON COMMIT
分区表本身不构成障碍，但 REFRESH ON COMMIT 的硬性前提与分区场景天然冲突：
- 基表必须有
PRIMARY KEY，且物化视图查询中所有连接列、过滤列都需被索引——而分区键常为日期或范围字段，若未在每个分区上显式维护唯一约束+索引，ON COMMIT创建会静默失败或后续不刷新 - 物化视图日志必须含
INCLUDING NEW VALUES和SEQUENCE，但 Oracle 对分区表建日志时默认不启用SEQUENCE，需手动指定；漏掉就导致FAST刷新退化为COMPLETE - 若物化视图含聚合（如按月统计销售）、连接（如订单+客户+产品），哪怕基表已分区，
ON COMMIT直接报ORA-12052或无提示失效 - 分区表常搭配本地索引，但
ON COMMIT要求所有关联列有全局唯一性保障，本地索引无法满足
FAST REFRESH + 分区感知调度才是可行路径
对千万级以上分区大表，应放弃“事务级同步”幻想，改用可控、可观测的增量刷新链路：
- 先确保基表日志完整：
CREATE MATERIALIZED VIEW LOG ON sales PARTITION BY RANGE(sale_date) WITH PRIMARY KEY, SEQUENCE(sale_id, amount), INCLUDING NEW VALUES;—— 注意PARTITION BY RANGE必须与基表分区策略一致，否则日志写入失败 - 物化视图定义中显式声明分区键参与查询，例如：
SELECT sale_date, SUM(amount) FROM sales GROUP BY sale_date，这样FAST REFRESH才能按分区粒度识别变更 - 调度 job 时避免全表扫描：用
DBMS_MVIEW.REFRESH的list参数指定待刷分区，如list => 'SALES_P202609, SALES_P202610'，跳过历史冷分区 -
NEXT表达式必须返回DATE类型，'SYSDATE + 1/1440'是字符串字面量，job 不执行；正确写法是NEXT SYSDATE + 1/1440（无引号）
物化视图日志膨胀会直接卡死 DML
分区大表的 MLOG$_sales 日志表极易失控，尤其当刷新延迟或失败时：
- 日志表本身也应分区，且分区策略与基表对齐，否则单个日志段暴涨至 GB 级，
FAST REFRESH扫描耗时从毫秒变分钟 - 定期清理旧日志：
DELETE FROM mlog$_sales WHERE snaptime$$ ，但必须配合 <code>DBMS_MVIEW.PURGE_LOG，否则触发器残留导致 DML hang - 检查日志积压：
SELECT COUNT(*) FROM mlog$_sales;若持续 > 100 万行，说明刷新 job 失败或调度间隔太长 - 权限陷阱：job 运行用户需对基表有
SELECT（非SELECT ANY TABLE），且 DB Link 密码未过期——否则FAILURES字段递增但无错误日志
真正接近实时的底线是：基表变更 → 日志落盘 → job 触发 → 分区级增量应用，端到端稳定压在 30 秒内。这要求你放弃“自动一切”的幻想，亲手控制日志生命周期、调度节奏和分区边界。任何想靠一个 ON COMMIT 开关解决分区大表同步的方案，上线后都会在高并发下暴露为不可观测的延迟黑洞。
