DBMS_UTILITY.FORMAT_ERROR_BACKTRACE能精准定位异常原始行号和调用链，而SQLERRM仅返回错误码和简短描述；它必须在WHEN OTHERS首行调用，不可与RAISE连用，且需配合FORMAT_ERROR_STACK使用以完整排障。
用 DBMS_UTILITY.FORMAT_ERROR_BACKTRACE 替代 SQLERRM
只靠 sqlerrm 只能拿到错误消息和 ora-编号，比如 ora-00001: unique constraint violated，但完全看不到哪一行、哪个过程出的问题。真正定位问题必须依赖 dbms_utility.format_error_backtrace，它会返回从异常抛出处开始的完整调用链，包括包名、过程名、行号。
关键点：
- 必须在
WHEN OTHERS的第一行就调用，不能先做其他逻辑（如日志写入、事务回滚）再调用，否则堆栈可能被干扰 - 不要和
RAISE连用——RAISE会重置堆栈，导致返回的是RAISE所在行，而不是原始错误行 - 若需封装后重新抛出，改用
RAISE_APPLICATION_ERROR(-20001, msg, TRUE)，第三个参数TRUE表示保留原始堆栈
区分 FORMAT_ERROR_BACKTRACE 和 FORMAT_ERROR_STACK
DBMS_UTILITY.FORMAT_ERROR_STACK 返回的是错误类型 + 消息（类似 SQLERRM），而 FORMAT_ERROR_BACKTRACE 才是带行号的调用路径。两者常被混淆，但用途完全不同。
典型输出对比：
DBMS_UTILITY.FORMAT_ERROR_STACK → ORA-00001: unique constraint (SCOTT.PK_TEST) violated DBMS_UTILITY.FORMAT_ERROR_BACKTRACE → ORA-06512: at "SCOTT.PROC_INSERT", line 2 ORA-06512: at "SCOTT.PKG_UTILS", line 45 ORA-06512: at line 1
所以：记录排障日志时，至少要拼接 SQLERRM || CHR(10) || DBMS_UTILITY.FORMAT_ERROR_BACKTRACE；仅用 FORMAT_ERROR_STACK 等于没记。
Oracle 12c+ 推荐用 UTL_CALL_STACK 获取结构化堆栈
UTL_CALL_STACK 是 Oracle 12c 引入的替代方案，比 DBMS_UTILITY 函数更可控：支持逐层读取深度、获取对象名/行号/调用类型，还能跳过匿名块等干扰项。
常用组合：
-
UTL_CALL_STACK.DYNAMIC_DEPTH获取当前堆栈深度 -
UTL_CALL_STACK.UNIT_LINE(1)取最内层（即错误发生处）的行号 -
UTL_CALL_STACK.OWNER(1) || '.' || UTL_CALL_STACK.UNIT_NAME(1)拼出完整对象引用
注意：UTL_CALL_STACK 在异常处理块中调用是安全的，但它本身不捕获“错误发生点”，仍需配合 FORMAT_ERROR_BACKTRACE 使用才能还原原始上下文。
Spring Boot 调用存储过程时堆栈信息容易丢失
JDBC 驱动默认只暴露 SQLException.getMessage()，原始 PL/SQL 堆栈被截断。即使你在存储过程中正确写了 DBMS_OUTPUT.PUT_LINE，Java 层也收不到。
解决办法只有两个：
- 在存储过程的
EXCEPTION块里，把DBMS_UTILITY.FORMAT_ERROR_BACKTRACE结果写进一张日志表（如err_log），再由 Java 查询该表 - 或改用
RAISE_APPLICATION_ERROR(-20001, '详细错误:' || DBMS_UTILITY.FORMAT_ERROR_BACKTRACE, TRUE)，让 JDBC 把消息原样透传到SQLException.getMessage()
别指望 getStackTrace() 或日志框架自动补全 PL/SQL 行号——那属于数据库内部执行流，JVM 根本看不见。
