DBMS_UTILITY.FORMAT_CALL_STACK返回一个纯文本字符串，每行含行号、包名.过程名及对象名，仅反映PL/SQL层调用路径，最大4096字节且静默截断，不可在SQL中直接调用。
DBMS_UTILITY.FORMAT_CALL_STACK 返回什么
dbms_utility.format_call_stack 返回一个纯文本字符串，每行一条调用记录，格式固定为：行号 包名.过程名 [对象名]。它只反映 pl/sql 层的动态调用路径，不包含 sql 语句、触发器内部执行的 dml、操作系统帧或 java 调用链。
常见错误现象是直接在匿名块里调用，结果只有两行：anonymous block 和 FORMAT_CALL_STACK 自身——这不是函数失效，而是调用深度太浅，没形成有意义的嵌套栈。
- 必须在至少一层嵌套中使用（比如
p1 → p2 → p3，在p3里查才能看到完整三层） - 返回值最大 4096 字节，超长会被静默截断（不报错、不警告）
- 不能在 SQL 表达式中调用，
SELECT DBMS_UTILITY.FORMAT_CALL_STACK FROM DUAL会触发ORA-14551
在 EXCEPTION 块中安全捕获调用栈
最实用的场景是在异常处理中记录上下文，但关键点在于：它返回的是「当前执行点」的栈，不是「异常最初抛出处」的栈。如果异常被上层 EXCEPTION 捕获后再调用它，栈顶已经是异常处理器本身了。
- 应在异常刚被触发的位置立即调用，即放在最内层
EXCEPTION的第一行 - 不要用
RAISE后再调用——那样栈已被重置；要用RAISE_APPLICATION_ERROR封装前先取栈 - 务必搭配
DBMS_UTILITY.FORMAT_ERROR_STACK使用：前者看“怎么走到这”，后者看“错在哪一行”
示例：
CREATE OR REPLACE PROCEDURE p2 IS
BEGIN
RAISE NO_DATA_FOUND;
EXCEPTION
WHEN NO_DATA_FOUND THEN
DBMS_OUTPUT.PUT_LINE('Call stack:');
DBMS_OUTPUT.PUT_LINE(DBMS_UTILITY.FORMAT_CALL_STACK);
DBMS_OUTPUT.PUT_LINE('Error stack:');
DBMS_OUTPUT.PUT_LINE(DBMS_UTILITY.FORMAT_ERROR_STACK);
END;
为什么建议优先用 UTL_CALL_STACK 替代
UTL_CALL_STACK 是 Oracle 12c 引入的现代接口，比 DBMS_UTILITY.FORMAT_CALL_STACK 更可靠、更结构化，也规避了字符串截断和解析负担问题。
-
UTL_CALL_STACK.DYNAMIC_DEPTH()返回精确的动态调用深度（不含初始化块），比数FORMAT_CALL_STACK的换行数准得多 -
UTL_CALL_STACK.UNIT_NAME(1)和UTL_CALL_STACK.UNIT_LINE(1)直接获取最内层调用的包名和行号，无需字符串切分 - 支持从外向内遍历：
FOR j IN REVERSE 1..UTL_CALL_STACK.DYNAMIC_DEPTH() LOOP ... END LOOP - 没有 4096 字节硬限制，也不依赖输出格式稳定性
容易被忽略的兼容性与权限细节
虽然 DBMS_UTILITY 是公开包，但部分环境（如某些云数据库或受限租户）可能禁用或限制其使用；而 UTL_CALL_STACK 需要 12c 及以上版本，且调用者需有 EXECUTE 权限（通常默认具备）。
另一个常被跳过的点是：若存储过程被 SQL 调用（如视图中调用函数），FORMAT_CALL_STACK 仍无法反映 SQL 层调用链——此时应考虑 DBMS_UTILITY.FORMAT_ERROR_BACKTRACE，它专为异常后回溯设计，能穿透到触发异常的实际 PL/SQL 行，即使异常被多次 RAISE 传递也不会丢失原始位置。
