自治事务必须声明在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），而非实时查主表状态。
