Oracle触发器不支持显式递归调用，因mutating table机制禁止在行级触发器中查询或修改同一表，否则报ORA-04091；可行方案是自治事务写日志表+调度作业异步处理。
Oracle触发器本身不支持显式“递归调用”——你不能在触发器里写 EXECUTE IMMEDIATE 'UPDATE ...' 去修改同一张表，再期望再次触发自身，否则会报 ORA-04091: table is mutating, trigger/function may not see it。这不是配置问题，是 Oracle 的核心保护机制。
为什么触发器里 UPDATE 同一表会报 mutating table 错误
当一个 DML 触发器（尤其是 FOR EACH ROW 行级触发器）正在执行时，Oracle 禁止对该表做任何查询或 DML 操作（包括触发器内部的 SELECT、UPDATE、INSERT），因为此时表处于“变化中”（mutating）状态，读取结果不可靠。
- 哪怕只是
SELECT COUNT(*) FROM my_table也会触发ORA-04091 -
INSTEAD OF触发器可绕过该限制，但它只适用于视图，且逻辑必须完全替代原操作 -
AFTER STATEMENT触发器也不能直接查/改本表——它仍受语句级 mutability 约束
真正可行的递归数据同步方案：用自治事务 + 日志表
想实现“A 表更新 → 自动更新 B 表 → B 表更新又触发 C 表更新”，不能靠链式触发器硬套，而应解耦：
- 主触发器（
AFTER UPDATE ON a_table）只负责把变更写入一张轻量日志表（如sync_log），并提交（用PRAGMA AUTONOMOUS_TRANSACTION） - 另起一个独立作业（
DBMS_SCHEDULER）定时拉取sync_log，按顺序执行下游更新，失败可重试、可记录错误 - 避免在触发器里做耗时操作（如远程调用、复杂计算），否则拖慢主事务
示例片段：
CREATE OR REPLACE TRIGGER tr_a_after_update
AFTER UPDATE ON a_table
FOR EACH ROW
DECLARE
PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
INSERT INTO sync_log (src_table, src_id, action, new_val, ts)
VALUES ('a_table', :NEW.id, 'UPDATE', :NEW.status, SYSTIMESTAMP);
COMMIT; -- 必须显式提交自治事务
END;MAX_DUMP_FILE_SIZE 和触发器毫无关系
MAX_DUMP_FILE_SIZE 是 Oracle 数据库参数，控制 trace 文件、alert 日志等诊断文件的最大大小，单位是字节或带单位（如 10M）。它和触发器运行、错误堆栈、日志输出都无关。
- 调整它不影响触发器行为，也不会让
ORA-04091消失 - 修改需用
ALTER SYSTEM SET MAX_DUMP_FILE_SIZE = 50M SCOPE=BOTH;，且仅对新生成的 trace 文件生效 - 如果你看到大 dump 文件，说明触发器里抛了未捕获异常（比如
NO_DATA_FOUND），但根源仍是逻辑错误，不是 dump 大小的问题
最常被忽略的一点：很多人试图用触发器模拟应用层的“事件总线”，但 Oracle 触发器本质是强事务绑定的同步机制，一旦嵌套过深或依赖外部状态，就极易死锁或不可控。真要递归响应，优先走异步日志+作业，而不是在 BEFORE 里塞 UPDATE。
