dbms_utility.format_error_backtrace能精准定位异常原始行号，必须在exception块中调用，依赖客户端开启set serveroutput on，返回带行号的反向堆栈（如ora-06512: at "scott.proc_insert", line 12），而sqlerrm仅返回泛化错误信息且无位置信息。
它能直接告诉你错误发生在哪一行，但必须在 EXCEPTION 块里调用，且依赖客户端开启输出。
为什么 DBMS_UTILITY.FORMAT_ERROR_BACKTRACE 比 SQLERRM 有用
SQLERRM 只返回类似 ORA-01403: no data found 这样的泛化信息，完全不指明位置；而 DBMS_UTILITY.FORMAT_ERROR_BACKTRACE 返回的是带行号的反向堆栈，首行就是异常源头。比如：
ORA-06512: at "SCOTT.PROC_INSERT", line 12 ORA-06512: at "SCOTT.PKG_UTILS", line 45 ORA-06512: at line 1
这意味着第 12 行的 PROC_INSERT 是实际出错点，后续是调用链路。即使嵌套了三层存储过程，它也不会丢掉原始行号。
- 它不显示错误“是什么”，只回答“从哪来”——所以别指望靠它替代
SQLERRM或DBMS_UTILITY.FORMAT_ERROR_STACK - 它不解析语法错误（如
PLS-00103），只对运行时异常有效 - 如果异常被
RAISE重新抛出，堆栈会重置，FORMAT_ERROR_BACKTRACE只反映最后一次抛出处
必须在 EXCEPTION 块中调用，且不能脱离 PL/SQL 上下文
这个函数不是通用日志工具，它读取 Oracle 内部的异常栈状态，一旦离开 EXCEPTION 分支就失效。下面这些写法都无效：
- 在
BEGIN块里提前调用：DBMS_OUTPUT.PUT_LINE(DBMS_UTILITY.FORMAT_ERROR_BACKTRACE);→ 返回NULL - 在匿名块外单独执行：
SELECT DBMS_UTILITY.FORMAT_ERROR_BACKTRACE FROM DUAL;→ 报错或空值 - 在 Java/JDBC 中调用存储过程后，期望自动拿到输出 → 不会传回，必须显式调用
DBMS_OUTPUT.GET_LINES
正确姿势只有一种：在 WHEN OTHERS THEN 或具体异常处理器内调用。
看不到输出？先检查这三件事
写了 DBMS_OUTPUT.PUT_LINE 却没看到结果，90% 是环境配置问题，不是代码错：
- SQL*Plus 或 SQL Developer 执行前没运行：
SET SERVEROUTPUT ON - PL/SQL Developer 默认关闭输出面板，得手动打开 “Output” 窗口并勾选 “Enable DBMS Output”
- 输出内容超长被截断，报
ORU-10027: buffer overflow→ 改用：SET SERVEROUTPUT ON SIZE 1000000
注意：JDBC/ODP.NET 等应用层不会自动接收 DBMS_OUTPUT，需额外调用 DBMS_OUTPUT.GET_LINES 才能取到。
记录日志时别只记一个字段
单靠 DBMS_UTILITY.FORMAT_ERROR_BACKTRACE 无法还原错误类型，单靠 SQLERRM 又找不到位置。线上排障日志至少要拼接：
SQLERRM || CHR(10) || DBMS_UTILITY.FORMAT_ERROR_BACKTRACE
更稳妥的做法是三者都留：
-
SQLCODE（错误码数字） -
SQLERRM（错误主体） -
DBMS_UTILITY.FORMAT_ERROR_BACKTRACE（源头行号） -
DBMS_UTILITY.FORMAT_CALL_STACK（可选，看调用路径）
真正容易被忽略的，是那个必须手动开启的 SET SERVEROUTPUT ON —— 很多人反复改代码，却卡在这一步上。
