dbms_mview.refresh 在触发器中调用必然失败，因oracle执行模型禁止在sql上下文中执行其内部所需的dml、ddl及事务操作，即使使用autonomous_transaction也无法绕过内核对水位和日志一致性的严格管控。

DBMS_MVIEW.REFRESH 在触发器里直接调用一定会失败，这不是写法问题，而是 Oracle 的执行模型硬性限制。

Agent Git Oracle

高级仓库分析与重构指南。基于AI推理识别技术债务与架构反模式。

下载

触发器里调 DBMS_MVIEW.REFRESH 为什么必然报错

• 触发器运行在 SQL 执行上下文中，而 DBMS_MVIEW.REFRESH 内部会执行 DML（如更新日志表 MLOG$_t）、DDL（如临时索引操作）甚至隐式事务控制
• 直接触发会抛出 ORA-14551: cannot perform a DML operation inside a query 或 ORA-14552: cannot perform a DDL, commit or rollback inside a query
• 即使用 PRAGMA AUTONOMOUS_TRANSACTION 包装，也无法绕过物化视图的水位推进逻辑（比如 SNAPTIME$$）与基表日志的一致性校验 —— 这些状态由 Oracle 内核严格管理，用户触发器无权安全推进

REFRESH FAST ON COMMIT 和触发器完全无关

• REFRESH FAST ON COMMIT 是 Oracle 自带机制，不是靠你写的触发器驱动的
• 它依赖基表上已存在的物化视图日志（含 ROWID、SEQUENCE$$、INCLUDING NEW VALUES），且 MV 定义不能含 SYSDATE、分析函数、外连接等禁用项
• 查状态必须确认：SELECT FAST_REFRESHABLE, REFRESH_MODE FROM DBA_MVIEWS WHERE MVIEW_NAME = 'YOUR_MV'，若 FAST_REFRESHABLE 不是 YES，ON COMMIT 实际退化为 ON DEMAND，不报错但也不生效

真正可控的“自动”路径：调度 + 水位表

• 放弃触发器，改用 DBMS_SCHEDULER 定时调用刷新，并配合人工维护的时间戳水位
• 建水位表：CREATE TABLE mv_watermark (mv_name VARCHAR2(30), last_ts DATE)，初始化为起始时间
• MV 查询中显式过滤：SELECT * FROM t WHERE updated_at > (SELECT last_ts FROM mv_watermark WHERE mv_name = 'MV_T')
• 调度任务中先更新水位再刷新：

  BEGIN
  UPDATE mv_watermark SET last_ts = SYSDATE WHERE mv_name = 'MV_T';
  DBMS_MVIEW.REFRESH('MV_T', 'F');
  COMMIT;
  END;

复杂点在于水位更新和刷新必须原子执行（否则中间有新数据写入会导致漏刷），且 REFRESH FAST 要求基表变更期间不能有并发 DDL。这些细节容易被忽略，但一旦出错，增量数据就不可逆丢失。