dbms_utility.format_error_backtrace必须在when others首行调用，以获取原始错误行号的完整调用链；需与sqlerrm拼接记录，缺一不可，且仅在exception块内有效。
DBMS_UTILITY.FORMAT_ERROR_BACKTRACE 必须在 WHEN OTHERS 第一行调用
它不是普通函数，而是读取 Oracle 当前异常栈的快照；一旦你在 WHEN OTHERS 块里先做了变量赋值、日志写入、事务回滚或 RAISE，栈信息就可能被覆盖或重置。常见错误包括：
- 在调用前执行
INSERT INTO log_table VALUES (...)→ 返回NULL或不完整堆栈 - 先写
DBMS_OUTPUT.PUT_LINE(SQLERRM)再调用 → 仍能返回，但已非“原始第一现场” - 调用后紧跟
RAISE;→ 堆栈指向RAISE所在行，而非真实出错行
正确姿势是：进入 WHEN OTHERS 后立刻执行 DBMS_UTILITY.FORMAT_ERROR_BACKTRACE，并把结果存入变量或直接拼接进日志。
只用 FORMAT_ERROR_BACKTRACE 不够，必须和 SQLERRM 拼一起
DBMS_UTILITY.FORMAT_ERROR_BACKTRACE 告诉你“在哪错”，SQLERRM 告诉你“什么错”。两者缺一不可：
-
FORMAT_ERROR_BACKTRACE输出类似：ORA-06512: at "SCOTT.INS_EMP", line 12 -
SQLERRM输出类似：ORA-01403: no data found - 单独记
SQLERRM→ 日志里只有“没查到数据”，找不到过程名和行号 - 单独记
FORMAT_ERROR_BACKTRACE→ 看到行号，但不知道是空值、唯一冲突还是除零
推荐日志拼接方式：SQLERRM || CHR(10) || DBMS_UTILITY.FORMAT_ERROR_BACKTRACE，确保错误类型 + 完整调用链一次落库。
别在匿名块外或异常上下文外调用 FORMAT_ERROR_BACKTRACE
这个函数依赖 Oracle 内部的异常栈状态，脱离 EXCEPTION 块就失效：
-
SELECT DBMS_UTILITY.FORMAT_ERROR_BACKTRACE FROM DUAL→ 报错或返回NULL - 在存储过程主逻辑（
BEGIN和EXCEPTION之间）调用 → 返回NULL - 在
WHEN NO_DATA_FOUND这类具体异常分支里调用 → 可用，但不如WHEN OTHERS全面（因其他错误不会进这个分支）
它只在当前异常处理作用域内有效，且必须是“正在处理的异常”——也就是刚被抛出、尚未被清除的那个。
动态 SQL（EXECUTE IMMEDIATE）会让堆栈断在调用行，不是内部语句行
如果错误发生在 EXECUTE IMMEDIATE 执行的字符串里（比如拼错表名、字段不存在），FORMAT_ERROR_BACKTRACE 显示的会是 EXECUTE IMMEDIATE 那一行，而不是动态 SQL 字符串里的第几行：
- 示例：在
proc_a的第 25 行执行EXECUTE IMMEDIATE 'SELECT x FROM nonexst_tab'; - 堆栈输出：
ORA-06512: at "SCOTT.PROC_A", line 25，而非 “nonexst_tab 不存在” 的实际位置 - 此时需结合日志中记录的完整动态 SQL 内容，再人工定位语法问题
这是它的固有限制，不是 bug；真正想追溯动态 SQL 内部细节，得靠提前打印 SQL 字符串 + 用 DBMS_UTILITY.FORMAT_CALL_STACK 辅助看调用路径。
最易被忽略的一点：它只对 PL/SQL 异常生效，对 SQL 层报错（如 INSERT 时违反约束但没包在 PL/SQL 块里）完全不触发。必须确保错误落在 EXCEPTION 块能捕获的范围内，否则连调用机会都没有。
