调试PL/SQL需三步：用COMPILE DEBUG重新编译、授予DEBUG ANY PROCEDURE和DEBUG CONNECT SESSION权限、确保PLSQL_DEBUG=TRUE；缺一导致断点失效或ORA-01031错误。

DBMS_DEBUG 不是直接调用的工具，而是 Oracle 调试机制底层依赖的包；真正启动调试靠的是 IDE 集成和数据库端配置配合。没配好权限或没带 DEBUG 选项编译，点“开始调试”只会静默失败或报 ORA-01031: insufficient privileges。

调试前必须执行的三步编译操作

PL/SQL 调试不是“写完就能断点”，它依赖编译时嵌入调试符号。缺一不可：

• 用 ALTER PROCEDURE schema.proc_name COMPILE DEBUG 重新编译目标过程（不能只用 CREATE OR REPLACE）
• 确保当前用户有 DEBUG ANY PROCEDURE 和 DEBUG CONNECT SESSION 权限（GRANT DEBUG ANY PROCEDURE TO dev_user）
• 数据库参数 PLSQL_DEBUG 必须为 TRUE（查 SHOW PARAMETER PLSQL_DEBUG，非 TRUE 需 DBA 修改）

SQL Developer 中断点不生效的常见原因

断点灰色、点击无反应，通常不是 IDE 问题，而是服务端未就绪：

Agent Git Oracle

高级仓库分析与重构指南。基于AI推理识别技术债务与架构反模式。

下载

• 没启动调试监听器：在 SQL Developer 中打开“View → Debugger → Start Debugger Listener”，端口默认 4000
• 调试会话未绑定到正确连接：右键过程 → “Test”，弹出窗口里选的连接必须和监听器所属用户一致（不能用 HR 连接去调试 SCOTT 下的过程）
• 代码被优化过：Oracle 12c+ 默认启用 PLSQL_OPTIMIZE_LEVEL=2，会内联或删掉“无用”语句，导致断点跳过；临时加 PRAGMA OPTIMIZE_LEVEL(0) 在过程声明头

匿名块调用时传参与变量监控的实际技巧

调试本质是跑一个带参数的匿名块来触发目标过程，但很多坑藏在参数构造里：

• OUT 参数不能直接赋值，必须声明变量接收：

  BEGIN
    DECLARE
      v_result NUMBER;
    BEGIN
      your_proc(100, v_result);
      DBMS_OUTPUT.PUT_LINE(v_result);
    END;
  END;

• 调试中查看变量值，别只信“Variables”面板——它只显示当前作用域；局部变量在 EXCEPTION 块里可能已销毁，得在 EXCEPTION 前加 DBMS_OUTPUT.PUT_LINE 打印
• 游标类 REF CURSOR 输出无法在变量面板展开，需右键对应参数 → “Open in New Window” 才能看到结果集

调试中遇到 ORA-06512 定位不准怎么办

错误堆栈只告诉你“在第 X 行”，但 PL/SQL 编译后行号常偏移。更可靠的方式是：

• 单步执行到异常抛出处，看高亮行——不是报错行，而是触发异常的那行（比如 SELECT ... INTO 没查到数据，高亮的是 INTO 那行）
• 在疑似问题行前后加 DBMS_OUTPUT.PUT_LINE('step 1');，比断点更稳，尤其对循环体内部逻辑
• 注意 WHEN OTHERS THEN 会吞掉原始错误；临时注释掉它，让真实异常浮出水面

调试真正卡住的地方，往往不是语法或权限，而是你没意识到：调试会话会锁住被调试对象，同一过程不能被其他会话编译或执行——这点在多人协作环境里最容易引发“为什么我断点进不去”的误判。