自治事务日志需独立提交，否则主事务回滚会导致日志丢失；必须显式commit/rollback，封装为存储过程，避免访问主事务未提交临时表数据，合理设计字段并建索引，堆栈需在主异常块中捕获后传入。
pl/sql里用自治事务写日志，为什么不能直接insert？
因为普通insert会和主事务绑死：主事务一回滚，日志也跟着消失。日志表本身就是为了“留下痕迹”，痕迹没了就失去意义。自治事务pragma autonomous_transaction就是为这设计的——它开一个独立事务分支，提交/回滚都不受外层影响。
常见错误现象：ORA-06519: active autonomous transaction detected and rolled back，通常是你忘了在自治过程末尾加COMMIT或ROLLBACK。
- 自治过程必须显式
COMMIT（或ROLLBACK），否则退出时Oracle自动回滚，日志白写 - 不能在匿名块里直接写自治逻辑，必须封装成存储过程或函数
- 自治事务里不能访问主事务中未提交的临时表数据（比如
CREATE GLOBAL TEMPORARY TABLE里的行）
自定义日志表字段怎么设计才够用又不拖慢性能？
字段太少查不出上下文，太多又影响插入速度，尤其高频调用场景。重点保留可定位、可归因、可过滤的最小集合。
推荐基础字段（都加索引）：log_id（主键）、log_time（SYSTIMESTAMP，别用DATE，精度不够）、module_name（模块名，如'ORDER_PROCESS'）、proc_name（过程名，如'calc_discount'）、log_level（'INFO'/'ERROR'）、message（VARCHAR2(4000)足够，超长内容建议存附件表）、session_id（SYS_CONTEXT('USERENV', 'SESSIONID')）。
- 避免在日志表里存BLOB/CLOB，除非真有结构化大文本需求
-
log_time字段务必建索引，按时间范围查日志是最高频操作 - 如果系统并发高，考虑分区（按月或按
log_level），但小系统别过早优化
怎么安全地把异常堆栈写进日志表？
直接拼SQLERRM只有一行错误信息，没堆栈；用DBMS_UTILITY.FORMAT_ERROR_BACKTRACE才能拿到真实出错行号，但这个函数必须在异常处理块里调用，且不能跨自治事务边界。
正确做法：在主过程的EXCEPTION块里收集堆栈，再传给自治日志过程。
BEGIN
-- 主业务逻辑
NULL;
EXCEPTION
WHEN OTHERS THEN
log_error(
p_module => 'PAYMENT',
p_proc => 'submit_payment',
p_msg => SQLERRM,
p_stack => DBMS_UTILITY.FORMAT_ERROR_BACKTRACE
);
RAISE; -- 或按需处理
END;
- 不要在自治过程中再调用
FORMAT_ERROR_BACKTRACE，此时异常上下文已丢失 -
p_stack参数类型建议用VARCHAR2(4000)，超长截断比报错更可控 - 敏感字段如用户ID、金额，记录前做脱敏（比如
REPLACE(p_user_id, SUBSTR(p_user_id, 2), '***')）
日志过程被频繁调用时，哪些地方最容易卡住？
自治事务不是银弹，高频写日志可能反成瓶颈。最常卡在序列取值、索引维护、表锁竞争上。
关键控制点：
- 用
SEQUENCE.NEXTVAL生成log_id没问题，但确保序列CACHE值够大（比如CACHE 1000），避免频繁读取数据字典 - 日志表别加过多触发器（比如自动发邮件），自治事务里触发器也自治，容易引发隐式递归
- 如果发现
enq: TX row lock contention等待，检查是否多个会话同时往同一日志表插数据——这是正常现象，但若持续超100ms，说明日志量已超出单表承载能力
真正难搞的是日志和业务耦合太紧：比如在循环里每轮都记一条日志。这时候得权衡——到底是真要每步留痕，还是只需要关键节点+异常兜底。留痕成本永远存在，只是有时被忽略。
