必须用 UTL_CALL_STACK 替代 FORMAT_ERROR_BACKTRACE，因其提供结构化、抗污染的堆栈信息，支持精准定位错误对象名、行号及调用层级，且需在 EXCEPTION 块内使用，避免版本兼容与调用时机错误。
必须用 UTL_CALL_STACK 替代 FORMAT_ERROR_BACKTRACE
Oracle 12c+ 环境下，UTL_CALL_STACK 是获取结构化堆栈信息的首选，不是可选项。它能逐层读取调用深度、对象名、行号、调用类型，避免 DBMS_UTILITY.FORMAT_ERROR_BACKTRACE 返回纯文本后还需手动解析的麻烦。
关键差异在于：UTL_CALL_STACK 不依赖错误发生时的隐式堆栈快照，不会因中间 RAISE 或事务操作被污染；而 FORMAT_ERROR_BACKTRACE 必须放在 WHEN OTHERS 第一行，稍有前置操作就失效。
-
UTL_CALL_STACK.DYNAMIC_DEPTH返回当前堆栈总层数（至少为 1） - 最内层（即错误实际发生处）是索引
1，不是0或DYNAMIC_DEPTH：用UTL_CALL_STACK.UNIT_LINE(1)取行号，UTL_CALL_STACK.OWNER(1) || '.' || UTL_CALL_STACK.UNIT_NAME(1)拼出完整对象引用 - 用
UTL_CALL_STACK.CONTEXT(1)判断是否为匿名块——若返回ANONYMOUS_BLOCK，说明调用链顶层无意义，应跳过或只记录下一层
不能只靠 SQLERRM 和 SQLCODE 定位问题
SQLERRM 和 SQLCODE 只告诉你“什么错了”，但完全不提供位置信息。比如 ORA-01403: no data found 这类消息，在大型包里可能出现在十几处 SELECT 后面，没行号等于盲猜。
更危险的是：这两个值只在当前 EXCEPTION 块内有效。一旦你把 SQLERRM 赋给变量再传进日志过程，进过程时值就变成空串或 0 —— 因为异常上下文已退出。
- 务必在
WHEN OTHERS块内直接使用SQLERRM和SQLCODE，不要中转 - 入库前对
SQLERRM做截断：SUBSTR(SQLERRM, 1, 3999)，防止超长报错 - 若需拼接完整诊断信息，格式应为：
SQLERRM || CHR(10) || DBMS_UTILITY.FORMAT_ERROR_BACKTRACE（12c+ 可用UTL_CALL_STACK替代后半部分）
WHEN OTHERS 里调用 UTL_CALL_STACK 的典型写法
下面这段代码能在 12c+ 稳定输出错误发生点的对象名、行号、调用层级，且兼容嵌套包和触发器场景：
EXCEPTION
WHEN OTHERS THEN
DECLARE
l_depth PLS_INTEGER := UTL_CALL_STACK.DYNAMIC_DEPTH;
l_owner VARCHAR2(128);
l_unit VARCHAR2(128);
l_line PLS_INTEGER;
BEGIN
-- 从最内层开始找，跳过匿名块
FOR i IN REVERSE 1..l_depth LOOP
IF UTL_CALL_STACK.CONTEXT(i) != 'ANONYMOUS_BLOCK' THEN
l_owner := UTL_CALL_STACK.OWNER(i);
l_unit := UTL_CALL_STACK.UNIT_NAME(i);
l_line := UTL_CALL_STACK.UNIT_LINE(i);
EXIT;
END IF;
END LOOP;
<pre class='brush:php;toolbar:false;'> INSERT INTO error_log (err_code, err_msg, unit, line_no, call_stack)
VALUES (
SQLCODE,
SUBSTR(SQLERRM, 1, 3999),
NVL(l_owner || '.', '') || l_unit,
l_line,
DBMS_UTILITY.FORMAT_ERROR_BACKTRACE
);
COMMIT;
END;END;
注意：DBMS_UTILITY.FORMAT_ERROR_BACKTRACE 在这里仅作补充，主定位靠 UTL_CALL_STACK；COMMIT 前确保日志表有足够权限，否则会二次报错。
容易被忽略的兼容性陷阱
很多人写了 UTL_CALL_STACK 逻辑却在线上收不到有效数据，问题常出在版本判断和调用时机上：
- 如果数据库实际是 11g，但代码里硬写了
UTL_CALL_STACK.DYNAMIC_DEPTH，会直接编译失败，报PLS-00201: identifier 'UTL_CALL_STACK' must be declared -
UTL_CALL_STACK函数必须在EXCEPTION块内调用，不能提前放在BEGIN里——此时堆栈为空，DYNAMIC_DEPTH返回 0 - Spring Boot 通过 JDBC 调用存储过程时，
UTL_CALL_STACK生成的信息默认不会透出到SQLException，需在存储过程中用RAISE_APPLICATION_ERROR(-20001, msg, TRUE)的第三个参数TRUE显式保留堆栈
真正难处理的，是那些跨多层包调用 + 触发器 + 动态 SQL 的组合场景：UTL_CALL_STACK 能拿到 PL/SQL 层调用点，但拿不到绑定变量值或 SQL 文本——这部分得靠额外开启 DBMS_MONITOR 或会话级跟踪。
