ORA-06512本身不是根因，而是未捕获异常的堆栈展开标记；真正错误在其上一行，如ORA-06502、ORA-01400或ORA-01031等，需优先排查该行错误码及上下文。
ORA-06512总是伴随其他错误出现，先看堆栈最上面那条
ORA-06512本身不是根因，它只是告诉你“异常没被处理，堆栈展开到了这一行”。真正的问题藏在它上面那条错误里——比如 ORA-06502（数字或值错误）、ORA-01400（不能插入 NULL）、ORA-01031（权限不足）等。不看上一行，光盯 ORA-06512 就像修车只换轮胎却不查刹车油漏了。
常见现象：
- 执行存储过程报错，但错误信息里有两行甚至三行
ORA-06512，最后一行才是真实出错位置 - PL/SQL Developer 或 SQL*Plus 中看到类似
ORA-06512: at "SCHEMA.PROC_NAME", line 27，这行只是异常传播路径，不是源头
字符串缓冲区太小（ORA-06502 + ORA-06512）：变量长度和参数 size 必须匹配
这是最常踩的坑：输出参数定义太短，但实际返回内容超长。比如存储过程声明 v_ret VARCHAR2(10)，却赋值了 15 个字符的字符串；或者应用层调用时，没给 OUT 参数预留足够空间。
- 在 PL/SQL 内部，优先改用
CLOB替代VARCHAR2接收不确定长度的拼接结果，例如：v_result CLOB := EMPTY_CLOB(); - 用
DBMS_LOB拼接大文本，避免隐式转换和截断：DBMS_LOB.WRITEAPPEND(v_result, LENGTH(str), str); - 如果是 .NET 或 Delphi 等客户端调用，必须显式设置参数
Size属性（如param.Size = 32767），不能依赖默认值；IDataParameter不支持Size，得换用IDbDataParameter - Java 使用
CallableStatement时，对registerOutParameter的第三个参数要传具体长度，例如：cs.registerOutParameter(2, Types.VARCHAR, 32767);
权限问题引发的 ORA-06512（ORA-01031 + ORA-06512）：角色权限在存储过程中无效
即使用户被授予了 DBA 角色，存储过程里执行 CREATE TABLE 或访问其他 schema 的表仍会报 ORA-01031，然后触发 ORA-06512。因为角色权限在定义者权限（AUTHID DEFINER）模式下不生效。
- 检查存储过程头部是否写了
AUTHID CURRENT_USER—— 这会让过程以调用者身份执行，继承其角色权限 - 更稳妥的做法是：直接给用户授予权限，比如
GRANT SELECT ON other_schema.table TO your_user;，而不是依赖角色 - 如果过程里用了
EXECUTE IMMEDIATE，注意动态 SQL 默认走调用者权限，除非明确指定AUTHID DEFINER并确保定义者有对应权限 - 查询
DBA_TAB_PRIVS和DBA_SYS_PRIVS确认缺失权限，别只查ROLE_TAB_PRIVS
表空间或作业配置失效导致的 ORA-06512
这类错误容易被忽略，因为它看起来和 PL/SQL 无关。比如数据库自动任务（如 AUTO_SPACE_ADVISOR_JOB）尝试访问已被删掉的表空间，就会抛出底层异常，最终表现为未捕获的 ORA-06512。
- 查当前无效表空间：
SELECT name FROM ts$ WHERE name NOT IN (SELECT tablespace_name FROM dba_tablespaces); - 清理失效记录：
DELETE FROM dba_auto_segadv_ctl WHERE tablespace_name NOT IN (SELECT tablespace_name FROM dba_tablespaces); - 检查作业状态：
SELECT job_name, state, enabled FROM dba_scheduler_jobs WHERE job_name LIKE '%AUTO%';，禁用或重配异常作业 - 这类错误往往出现在凌晨维护窗口后，日志里会有
ORA-00959或ORA-00942等前置错误，别跳过它们
真正麻烦的不是错误本身，而是它总躲在别的错误后面冒头。定位时务必从错误堆栈顶部开始读，逐行向下追，尤其注意第 2 行那个真正的错误码。很多 case 改完变量长度或加了权限，ORA-06512 自然消失——它只是个信使，不是肇事者。
