Oracle触发器中调用DBMS_MVIEW.REFRESH必然失败，因其内部含DML/DDL操作，违反“查询中不可修改”限制，即使自治事务也无法绕过日志一致性与水位推进约束。
Oracle PL/SQL 中无法用触发器实现物化视图的“自动增量刷新”——触发器本身不能调用 REFRESH FAST，且 DBMS_MVIEW.REFRESH 在触发器中执行会报 ORA-14551（cannot perform a DML operation inside a query）。
为什么触发器里调 DBMS_MVIEW.REFRESH 一定会失败
Oracle 触发器运行在 SQL 执行上下文中，而 DBMS_MVIEW.REFRESH 是一个会发起事务、读写日志表（如 MLOG$_t）、甚至可能锁基表的 PL/SQL 过程。它内部包含 DML 和 DDL 操作，违反了“查询中不能做修改”的硬性限制。
- 常见错误信息：
ORA-14551: cannot perform a DML operation inside a query或ORA-14552: cannot perform a DDL, commit or rollback inside a query or DML - 即使包装成自治事务（
PRAGMA AUTONOMOUS_TRANSACTION），也无法绕过日志表与 MV 状态的耦合逻辑——FAST刷新依赖SNAPTIME$$水位和日志一致性，触发器无法安全推进这个状态 -
REFRESH COMPLETE同样不行：它会TRUNCATE+ 全量重插，同样触发 DML 限制
REFRESH ON COMMIT 看似自动，但和触发器无关
ON COMMIT 是 Oracle 内置机制，不是靠用户写的触发器驱动的。它由 Oracle 自己在事务提交时检查日志并触发增量逻辑，前提是物化视图日志和 MV 定义完全合规。
- 启用方式：
REFRESH FAST ON COMMIT，不是写触发器 - 必须满足所有 FAST 条件：日志含
SEQUENCE$$、ROWID、INCLUDING NEW VALUES；MV 查询不能含SYSDATE、分析函数、外连接等 - 查状态：
SELECT FAST_REFRESHABLE, REFRESH_MODE FROM DBA_MVIEWS WHERE MVIEW_NAME = 'MV_T'，若FAST_REFRESHABLE不是YES，ON COMMIT实际静默退化为ON DEMAND
真要“自动”，只能用外部调度 + 显式水位管理
想让增量刷新看起来“自动”，唯一可控路径是脱离触发器，改用 DBMS_SCHEDULER 定时调用 DBMS_MVIEW.REFRESH，并配合人工维护的时间戳水位。
- 建一张水位表：
CREATE TABLE mv_watermark (mv_name VARCHAR2(30), last_ts DATE)，初始化为起始时间 - MV 查询中显式过滤：
SELECT id, name, updated_at 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'; COMMIT; DBMS_MVIEW.REFRESH('MV_T', 'F'); END; - 关键验证点：每次刷新后立刻查
SELECT COUNT(*) FROM MLOG$_t WHERE SNAPTIME$$ > (SELECT last_ts FROM mv_watermark WHERE mv_name = 'MV_T') - INTERVAL '1' SECOND，非零才说明日志被真正消费
最容易被忽略的崩溃点
所有“自动”尝试都卡在同一个地方：Oracle 的 FAST 刷新不是基于业务逻辑，而是基于日志表里的物理变更记录。一旦日志没建对、字段大小写不一致、或基表被 TRUNCATE 过，REFRESH 就静默走 COMPLETE——不报错，但性能归零。你得每天看 DBA_MVIEWS.FAST_REFRESHABLE 和 MLOG$_t 行数变化，而不是只盯着调度任务是否跑成功。
