ORA-06512本身不是错误原因，而是错误位置标记，必须结合前置错误码（如ORA-06502、ORA-01403）才能诊断；它指向异常抛出点而非实际出错点，真正问题总在它前面一行，堆栈首行才是关键。
ORA-06512本身不是错误原因，而是错误位置标记
ORA-06512单独出现几乎没有诊断价值——它只是告诉你“错误从这里往上抛”，真正的问题永远在它前面那一行（比如 ORA-06502、ORA-01403、ORA-01031）。堆栈里第一行才是关键，后面所有 ORA-06512 都是调用链路回溯。
常见现象：日志里一连串 ORA-06512: at "SCOTT.PROC_A", line 42、ORA-06512: at "SCOTT.PKG_B", line 18，但没看到真正的错误码。这说明异常被 RAISE 重抛过，原始错误信息丢了。
- 必须结合前一个错误码一起读，例如
ORA-06502: PL/SQL: numeric or value error+ORA-06512: at "SCOTT.PROC_INSERT", line 12→ 问题就在第 12 行的变量赋值或字符串拼接 - 如果堆栈里只有
ORA-06512没有前置错误，大概率是异常被空的WHEN OTHERS THEN NULL;吞掉了 -
ORA-06512行号指向的是“抛出点”，不一定是“出错点”——比如第 12 行执行了raise_application_error，实际逻辑错误可能在第 8 行
用DBMS_UTILITY.FORMAT_ERROR_BACKTRACE定位原始行号
这个函数只在 EXCEPTION 块里有效，返回带行号的反向堆栈，首行就是最内层出错位置。它不告诉你“什么错了”，只告诉你“从哪来”。
正确写法：
EXCEPTION
WHEN OTHERS THEN
DBMS_OUTPUT.PUT_LINE(DBMS_UTILITY.FORMAT_ERROR_BACKTRACE);
DBMS_OUTPUT.PUT_LINE(SQLERRM);
END;容易踩的坑：
- 在
BEGIN块里提前调用DBMS_UTILITY.FORMAT_ERROR_BACKTRACE→ 返回NULL - 用
SELECT DBMS_UTILITY.FORMAT_ERROR_BACKTRACE FROM DUAL→ 报错或空值 - 没开
SET SERVEROUTPUT ON→ 看不到输出 - 异常被
RAISE重新抛出后，再调用该函数 → 只反映最后一次抛出处，原始位置丢失
ORA-06512常与表空间、作业调度关联，别只盯PL/SQL代码
当错误堆栈指向系统包（如 DBMS_SCHEDULER、DBMS_AUTO_TASK_ADMIN）或报错中出现 AUTO_SPACE_ADVISOR_JOB、TS$ 等关键词，问题往往不在你的过程里。
典型场景：
- 自动统计任务失败，因为引用的表空间已被删除 → 查
SELECT * FROM TS$ WHERE NAME NOT IN (SELECT TABLESPACE_NAME FROM DBA_TABLESPACES) -
DBA_AUTO_SEGADV_CTL里存了已不存在的表空间名 → 执行DELETE FROM DBA_AUTO_SEGADV_CTL WHERE TABLESPACE_NAME NOT IN (SELECT TABLESPACE_NAME FROM DBA_TABLESPACES) - 作业配置里硬编码了旧表空间名，而当前环境已改名 → 查
DBA_SCHEDULER_JOBS和DBA_SCHEDULER_JOB_ARGS
这类问题不会在你的存储过程代码里暴露，但会以 ORA-06512 形式出现在调用堆栈顶部。
捕获完整错误信息必须拼接三要素
只记录 SQLERRM 或只用 FORMAT_ERROR_BACKTRACE 都不完整。排障日志至少要包含：
SQLERRM || CHR(10) || DBMS_UTILITY.FORMAT_ERROR_BACKTRACE || CHR(10) || DBMS_UTILITY.FORMAT_ERROR_STACK
三者分工明确：
-
SQLERRM→ 错误类型和简要描述（如ORA-00001: unique constraint violated） -
FORMAT_ERROR_BACKTRACE→ 原始出错行号（at "SCOTT.PROC_INSERT", line 12） -
FORMAT_ERROR_STACK→ 完整错误码序列（含所有前置错误，不止第一个）
漏掉任意一项，都可能让排查卡在“知道在哪错，但不知道为什么错”或“知道为什么错，但找不到在哪错”的状态。
