必须使用 PRAGMA AUTONOMOUS_TRANSACTION，否则日志随主事务回滚丢失；自治过程需顶部声明、显式提交、日志表独立，缺一不可。
能，而且必须用 PRAGMA AUTONOMOUS_TRANSACTION，否则日志一定随主事务回滚丢失。
为什么普通 INSERT + COMMIT 在异常处理里会失败
在存储过程的 EXCEPTION 块里直接写 INSERT INTO log_table ...; COMMIT; 看似可行，但 Oracle 会报错 ORA-06519: active autonomous transaction detected and rolled back 或更隐蔽地让整个块编译失败。根本原因是：PL/SQL 默认不允许在非自治的匿名块或子程序中执行 COMMIT/ROLLBACK，除非它被明确定义为自治事务。
- 主事务未结束时，任何显式
COMMIT都会被视为对整个事务上下文的操作，违反 PL/SQL 事务控制规则 - 即使你把日志插入写在
EXCEPTION里，只要没加PRAGMA，该语句仍属于主事务，一回滚全清空 - 不加
PRAGMA的日志写入，和业务表 DML 共享同一回滚段，锁、一致性读、UNDO 都耦合在一起
自治日志过程必须满足的三个硬性条件
一个真正可靠的错误日志过程，不能只靠加一行 PRAGMA 就完事。以下三点缺一不可：
- 过程体顶部必须有且仅有
PRAGMA AUTONOMOUS_TRANSACTION;（注意分号），且必须放在声明区最前面，不能在BEGIN后面 - 过程内必须显式调用
COMMIT;（或ROLLBACK;），自治事务不会自动提交；漏掉这句，日志写入会滞留在 UNDO 中，下次调用时可能报ORA-06519 - 日志表要独立于业务表——最好指定
TABLESPACE LOG_TBS，避免因业务表空间满导致日志写入失败进而拖垮主流程
典型错误场景与正确写法对比
假设你要记录用户注册失败的日志，主过程叫 p_register_user，日志过程叫 p_log_error：
❌ 错误写法（看似简洁，实则无效）：
CREATE OR REPLACE PROCEDURE p_log_error(err_msg VARCHAR2) AS BEGIN INSERT INTO error_log VALUES (SYSTIMESTAMP, USER, err_msg); COMMIT; -- 这里会报错或静默失败 END;
✅ 正确写法（带完整自治事务契约）：
CREATE OR REPLACE PROCEDURE p_log_error(err_msg VARCHAR2) AS
PRAGMA AUTONOMOUS_TRANSACTION; -- 必须第一行，声明即生效
BEGIN
INSERT INTO error_log (log_time, os_user, message)
VALUES (SYSTIMESTAMP, SYS_CONTEXT('USERENV', 'OS_USER'), err_msg);
COMMIT; -- 必须显式提交，否则不持久
EXCEPTION
WHEN OTHERS THEN
ROLLBACK; -- 自治事务内出错也要清理自己，不干扰主事务
RAISE; -- 让主过程知道日志本身也失败了（可选）
END;调用时无需额外处理：EXCEPTION WHEN OTHERS THEN p_log_error(SQLERRM); RAISE; 即可。
容易被忽略的兼容性与性能细节
Oracle 19c 虽然完全支持自治事务，但有两点实际使用中常踩坑：
-
SYSDATE在自治事务中返回的是自治事务启动时刻的时间，不是主事务开始时间；如需对齐，应由主过程传入SYSTIMESTAMP值，自治过程只负责存，不负责生成 - 自治事务会消耗额外的回滚段和会话内存，高频调用（如每条 SQL 都记日志）会导致
ORA-01562: failed to extend rollback segment；建议仅用于关键路径（异常、审计、告警），不要用于常规 trace - 触发器里用自治事务写日志时，
:OLD和:NEW是可用的，但不能在自治事务块里再查当前正被修改的业务表（否则可能触发ORA-04091），所有上下文信息应提前提取并作为参数传入
自治事务不是“免死金牌”，它是把主事务的事务边界切开一道缝——缝切得不准，日志进不去，业务还卡住。关键就三件事：声明、提交、隔离。少做一样，都白搭。
