ORA-06512本身不是错误原因，而是错误位置标记；真正问题总在它前面一行（如ORA-06502），堆栈首行才是根因，需结合SQLERRM与DBMS_UTILITY.FORMAT_ERROR_BACKTRACE定位原始出错行。
ORA-06512 本身不是“调用栈溢出”，它是 Oracle 报出的**错误位置标记**，真正的问题永远在它前面那个错误（比如 ORA-06502、ORA-01476、ORA-00942 等）。所谓“调用栈溢出”是误读——你看到一长串 ORA-06512 堆栈，只是说明错误从底层函数逐层向上抛出，没被截断而已。
查清楚真正触发错误的那个 ORA-xxxxx
Oracle 错误堆栈永远倒着读：最上面一行才是根因。例如：
ORA-06502: PL/SQL: numeric or value error: character string buffer too small ORA-06512: at "SCOTT.PACKAGE_A", line 87 ORA-06512: at "SCOTT.PROC_B", line 22 ORA-06512: at line 5
重点不是后面三行 ORA-06512，而是第一行 ORA-06502 —— 它告诉你发生了“字符串缓冲区太小”。后面所有 ORA-06512 只是告诉你这个 ORA-06502 是怎么一层层冒上来的。
- 运行时用
SQLERRM只能拿到最外层错误信息，看不到原始错误；必须用DBMS_UTILITY.FORMAT_ERROR_BACKTRACE配合SQLERRM才能定位到最初出错那行 - 如果堆栈里出现
AUTO_SPACE_ADVISOR_JOB、DBMS_SCHEDULER或TS$，大概率问题不在你的代码里，而在数据库自动任务或表空间配置 - 别在
EXCEPTION块开头就调用DBMS_UTILITY.FORMAT_ERROR_BACKTRACE—— 此时异常还没被真正捕获，返回值是NULL
修复常见根因：字符串、数字、类型三类硬伤
ORA-06502 占了绝大多数实际场景，核心就是“装不下”或“对不上”：
- 给
VARCHAR2(10)赋值长度 15 的字符串 → 改成VARCHAR2(50)或直接用CLOB - 把
'abc'赋给NUMBER(3)变量 → 检查来源字段是否含非数字字符，加TO_NUMBER(... DEFAULT NULL ON CONVERSION ERROR)（12c+） - 动态 SQL 拼接过长 → 不要用
VARCHAR2累加，改用DBMS_LOB.WRITEAPPEND写CLOB - XMLAGG 返回超长字符串 → 加
SUBSTR(..., 1, 32767)截断，或用LISTAGG（11gR2+）替代
避免 DBMS_OUTPUT 成为新瓶颈
调试时狂打 DBMS_OUTPUT.PUT_LINE 很容易自己触发新错误：
- 单次输出超过 32767 字节 → 触发
ORA-06502（buffer too small） - 累积输出超过 1MB 默认缓冲区 → 报
ORA-06512: buffer overflow, 超出1000000字节限制 - 没开
SET SERVEROUTPUT ON→ 看不到任何输出，误以为没执行到 - 解决方案：
SET SERVEROUTPUT ON SIZE UNLIMITED（12c+），或改用写表/UTL_FILE 写文件
当堆栈指向系统包或作业时，别修代码
如果 ORA-06512 明确指向 DBMS_AUTO_TASK_ADMIN、DBMS_SPACE 或作业名如 AUTO_SPACE_ADVISOR_JOB，说明错误来自 Oracle 自动维护任务：
- 查
SELECT * FROM DBA_AUTO_SEGADV_CTL WHERE TABLESPACE_NAME NOT IN (SELECT TABLESPACE_NAME FROM DBA_TABLESPACES)—— 找出已删表空间却仍被任务引用的残留记录 - 停掉对应作业：
EXEC DBMS_AUTO_TASK_ADMIN.DISABLE(client_name => 'auto space advisor', operation => NULL, window_name => NULL) - 检查
DBA_SCHEDULER_JOB_LOG中最近失败记录，看ADDITIONAL_INFO字段是否有真实线索
这类问题修 PL/SQL 代码毫无意义——错误根本不在你的过程里，而在于数据库环境配置和自动任务状态。堆栈越深，越要先确认是不是外部依赖出了问题。
