如何在Oracle 11g里用自治事务解决日志记录回滚的问题？

自治事务必须声明在PL/SQL块顶层声明区最开头、紧挨IS或AS之后，否则报PLS-00103；启动后须显式COMMIT或ROLLBACK，否则抛ORA-06519；主事务异常时应仅调用已自治且内部提交的日志过程，不可在主事务中直接写日志并COMMIT。

自治事务必须声明在PL/SQL块顶层

pragma autonomous_transaction不是随便放哪都行的语法糖，它必须出现在存储过程、函数或匿名块的**声明区最开头**，紧挨着is或as之后。放在begin之后、if里、loop里，甚至包体的包规范（spec）里，都会报编译错误pls-00103。

常见错误现象：ORA-06519: active autonomous transaction detected and rolled back——这往往不是没写COMMIT，而是因为声明位置不对，导致Oracle根本没把它当自治事务处理，后续又没按主事务逻辑走完流程。

• 正确位置：CREATE OR REPLACE PROCEDURE p_log(...) IS PRAGMA AUTONOMOUS_TRANSACTION; BEGIN ...
• 错误位置：BEGIN IF cond THEN PRAGMA AUTONOMOUS_TRANSACTION; END IF; ...
• 触发器里也一样：CREATE OR REPLACE TRIGGER ... BEFORE UPDATE ON t FOR EACH ROW DECLARE PRAGMA AUTONOMOUS_TRANSACTION; BEGIN ...

自治日志过程里必须显式COMMIT或ROLLBACK

自治事务一旦启动，就完全脱离主事务控制，Oracle不会帮你兜底。退出时若没执行COMMIT或ROLLBACK，就会抛ORA-06519并自动回滚整个自治块——你写的那条INSERT就白写了，还带出错。

所以每个自治过程的BEGIN后面，不管有没有异常分支，都要确保有且仅有一个提交路径：

• 正常路径末尾加COMMIT
• EXCEPTION分支里必须加ROLLBACK（不能只RAISE），否则异常时自治事务悬空
• 别在自治过程里调用另一个自治过程再漏提交——嵌套自治事务要各自负责自己的事务边界

示例关键片段：

CREATE OR REPLACE PROCEDURE p_log_error(p_msg VARCHAR2) IS  PRAGMA AUTONOMOUS_TRANSACTION;BEGIN  INSERT INTO t_log(msg, ts) VALUES (p_msg, SYSDATE);  COMMIT; -- ← 必须有EXCEPTION  WHEN OTHERS THEN    ROLLBACK; -- ← 出错也要收尾    RAISE;END;

主事务异常时只调用自治过程，不加任何事务语句

很多开发者在主过程的EXCEPTION块里写INSERT INTO t_log ...; COMMIT;，以为能保住日志——结果这条INSERT仍属于主事务，一回滚全丢。真正有效的做法是：把日志逻辑彻底剥离，只留一个自治过程调用。

典型错误写法：

EXCEPTION  WHEN OTHERS THEN    INSERT INTO t_log ...; -- ❌ 还在主事务里    COMMIT;               -- ❌ 主事务还没结束，这里COMMIT会提前提交业务数据    RAISE;

正确模式：

• 主过程里所有DML都不带COMMIT/ROLLBACK（交给调用方或上层控制）
• EXCEPTION分支只做一件事：p_log_error('xxx');，然后RAISE
• 确保p_log_error是自治的、内部已COMMIT，主过程对它的调用不产生任何事务副作用

自治事务看不到主事务未提交的数据

这是容易被忽略的隔离性陷阱。自治事务有自己的事务快照，启动时读不到主事务中INSERT但尚未COMMIT的记录。比如主过程刚插入一条用户数据，紧接着在自治日志里SELECT这个用户做关联记录，会查不到。

影响场景：

• 日志表需要记录业务主键，但主事务还没提交，自治过程无法SELECT FOR UPDATE或JOIN该记录
• 触发器里用自治事务记日志，又试图读取触发行的新值（:NEW）以外的主表其他字段——可能读到旧版本
• 避免死锁：自治事务不要UPDATE/DELETE主事务正在修改的同一行，尤其别用SELECT ... FOR UPDATE去锁主事务的行

解决思路：日志内容尽量只依赖输入参数（如错误码、时间戳、任务ID），而非实时查主表状态。