Oracle中触发器调用含commit的存储过程，使用自治事务是否合理？

结论先行 #

你当前使用pragma autonomous_transaction的实现是临时规避报错的hack手段，绝大多数业务场景下不属于正确解决方案。

原报错原因 #

Oracle普通触发器默认运行在触发它的主事务上下文内，为了保证主事务的原子性，触发器执行过程中不允许直接/间接执行commit或rollback语句，你调用的存储过程内部包含commit，所以直接触发报错。

加自治事务后的运行逻辑变化 #

添加自治事务声明后，触发器内的执行逻辑会被封装为完全独立于主事务的新事务：

• 存储过程内的commit只会提交自治事务范畴内的DML操作，不会和主事务产生冲突，所以不再报错
• 自治事务的提交/回滚完全不影响主事务的执行状态，主事务的回滚也不会影响自治事务已经提交的结果

现有实现的核心隐患 #

你的场景里触发器调用的是业务DML操作，和主事务插入表A的操作应该是强关联的，用自治事务会直接破坏数据一致性：

• 如果插入表A的主事务后续执行失败回滚，proc1/proc2已经提交到X、Y表的数据不会跟着回滚，会出现「表A无对应记录，但X/Y表有衍生数据」的逻辑错误
• 自治事务启动时主事务还未提交，如果你存储过程内需要查询表A刚插入的这条新记录，自治事务是读不到的，会导致逻辑异常

推荐的正确解决方案 #

1. 优先改造存储过程，移除内部的commit语句，让存储过程的DML操作加入主事务上下文，和主事务同提交同回滚，保证业务逻辑的原子性
2. 如果proc1/proc2是公共逻辑，其他业务调用需要保留内部commit，可以额外封装一层不带commit的版本专供触发器调用
3. 只有当触发器内的操作是日志、审计这类需要脱离主事务独立留存的场景时，使用自治事务才是合理的

内容的提问来源于stack exchange，提问作者Tommy