DBMS_UTILITY.FORMAT_CALL_STACK返回当前PL/SQL调用栈字符串，每行含行号、包名/过程名及对象名，仅限PL/SQL层、最大4096字节、不可在SQL中直接调用。
DBMS_UTILITY.FORMAT_CALL_STACK 返回什么
dbms_utility.format_call_stack 返回一个包含当前 pl/sql 调用栈的字符串，每行一条调用记录，格式为「行号 + 包名/过程名 + 所在对象」。它不包含 sql 层调用（比如触发器里调用的 sql 语句），也不包含操作系统级堆栈；只反映 pl/sql 运行时的嵌套调用路径。
常见错误现象：直接在匿名块里调用，结果只有两行（anonymous block 和 FORMAT_CALL_STACK 自身），误以为“没生效”。这是因为调用太浅，没形成有意义的栈。
- 必须在至少一层嵌套调用中使用（比如 A → B → C，你在 C 里查，才能看到 A/B/C）
- 返回值最大长度为 4096 字节，超长会被截断，且不报错
- 不能在 SQL 表达式中直接调用（如
SELECT DBMS_UTILITY.FORMAT_CALL_STACK FROM DUAL会报ORA-14551: cannot perform a DML operation inside a query）
怎么安全地在异常处理中捕获调用栈
最实用的场景是在 EXCEPTION 块里记录错误上下文。但要注意：FORMAT_CALL_STACK 返回的是「当前执行点」的栈，不是「异常抛出点」的栈——如果异常被上层 EXCEPTION 捕获后再调用它，栈顶已经是异常处理器本身了。
- 应在异常刚被触发的位置立即调用，推荐放在最内层
EXCEPTION的第一行 - 搭配
DBMS_UTILITY.FORMAT_ERROR_STACK使用，前者看“怎么走到这”，后者看“错在哪一行” - 别用
RAISE后再调用——那样栈已被重置；要用RAISE_APPLICATION_ERROR封装前先取栈
示例：
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_LINE(1)获取最内层调用行号，UNIT_NAME(1)获取过程名，无字符串解析负担 - 兼容性注意：11g 及更早版本不支持，若需跨版本，得兜底用
DBMS_UTILITY并加长度判断
容易被忽略的权限和字符集问题
调用 DBMS_UTILITY 或 UTL_CALL_STACK 不需要额外授权（PUBLIC 已有 EXECUTE），但输出内容受当前会话字符集影响。如果数据库是 AL32UTF8，而客户端是 WE8MSWIN1252，中文包名或注释可能显示为乱码或问号——这不是函数问题，是 NLS 环境不一致。
- 检查
SELECT SYS_CONTEXT('USERENV', 'NLS_LANGUAGE') FROM DUAL和客户端实际编码是否匹配 - 日志写入表时，确保目标列是
NCLOB或NVARCHAR2，否则 Unicode 栈信息会被静默转义或截断 - 在
AFTER SERVERERROR触发器中调用？不行。DBMS_UTILITY.FORMAT_CALL_STACK在服务器错误上下文中不可用，会报ORA-06502
调用栈不是万能的调试镜，它只告诉你「谁调了谁」，不告诉你「变量值是多少」或「SQL 执行了多久」。真要定位深层逻辑问题，得配合 DBMS_OUTPUT 插桩、DBMS_PROFILER 或实时 SQL 监控。
