编译失败后应立即查询user_errors或all_errors获取具体错误位置和信息；常见错误包括标识符未声明、调用语法不合法、参数类型不匹配、游标处理不当；对象锁住或依赖失效会导致编译卡死或无效，需逐级检查并修复依赖。
编译失败后第一件事：查 user_errors
Oracle不会直接告诉你哪行错了，只返回 procedure created with compilation errors。这时候别猜，立刻查错误详情：
- 在当前用户 schema 下执行：
select line, position, text from user_errors where name = 'YOUR_PROC_NAME' and type = 'PROCEDURE' order by sequence; - 如果过程在别的 schema（比如
SYS或HR），改查all_errors，并带上owner条件 -
line和position指向具体字符位置，不是“第几行”，注意 PL/SQL 中换行和空格也占位置 - 常见错误文本如
PLS-00201: identifier 'XXX' must be declared，说明变量或对象没声明或不可见
ORA-06550 不是运行时报的错，是解析就挂了
Java 调用时抛出 ORA-06550，不代表存储过程本身有问题，而是你发过去的调用语句不合法。关键点：
- 带
OUT参数必须用匿名块：begin my_proc(?, ?); end;，不能只写{call my_proc(?, ?)} -
schema必须显式写出，my_proc和hr.my_proc在 Oracle 看来是两个东西 - JDBC 传参类型必须严格匹配：传
Integer给NUMBER可以，但传String给NUMBER会直接在解析阶段报PLS-00306 - 游标参数必须用
registerOutParameter(n, Types.OTHER)，且不能调用setXXX() - 调用后必须用
execute()，不是executeUpdate()
编译卡死？大概率是对象被锁住了
PL/SQL Developer 或 SQL*Plus 编译时无响应，不是客户端卡，是 Oracle 内部锁冲突。典型现象是执行 ALTER PROCEDURE ... COMPILE 一直 hang。
- 先查谁在用这个过程：
select * from v$access where object='YOUR_PROC_NAME'; - 再查会话状态：
select sid, serial#, status, program from v$session where sid = <sid_from_above>; - 如果状态是
ACTIVE或INACTIVE且长时间没释放，执行：alter system kill session '<sid>,<serial#>'; - 若会话状态变成
KILLED却迟迟不退出，需查v$process拿到spid，在操作系统层用kill -9（Linux）或orakill（Windows）干掉
状态为 INVALID 的过程，光重编译不一定能救活
status = 'INVALID' 只是表象，背后可能是依赖断裂。单纯 ALTER PROCEDURE xxx COMPILE 常失败或无效。
- 先看它依赖啥：
select referenced_owner, referenced_name, referenced_type from all_dependencies where name = 'YOUR_PROC_NAME' and owner = 'YOUR_SCHEMA'; - 检查这些依赖对象是否也都
VALID；尤其注意视图、同义词、DBLink 是否可用 - 如果依赖对象权限缺失（比如当前用户没
SELECT权限），即使编译通过，运行时也会报ORA-00942，而该错误常被包裹在ORA-06550堆栈里 - 修复顺序：先确保所有依赖对象存在、有效、有权限 → 再逐级重新编译（从底层依赖开始）→ 最后编译主过程
真正麻烦的不是语法错，而是错误信息藏在层层嵌套里：一个 ORA-06550 可能由权限缺失引发，而权限缺失又源于同义词指向了不存在的表——得一层层剥开看，不能只盯着最外层报错。
