根本原因是RAC负载均衡将调试所需的两个会话分发到不同节点，导致调试协议握手失败；解决方法是tnsnames.ora中显式指定INSTANCE_NAME并禁用Multiplexed连接模式。
调试挂起不是卡死，而是两个会话被分配到不同RAC节点上导致的通信中断。
为什么F9后按钮全灰、单步不可用
按F9启动调试后，Step Into、Step Over 等按钮变灰，状态栏长时间显示“Debugging…”却无响应，常见于RAC环境。根本原因不是权限或调试信息缺失，而是PL/SQL Developer在调试时需建立两个数据库会话：一个运行测试块（client session），一个承载调试器（debugger session）。当这两个会话被Oracle RAC的负载均衡策略分发到不同instance上时，调试协议无法完成握手，整个流程就僵在初始化阶段。
- 可通过
SELECT * FROM v$instance在两个独立SQL窗口中分别执行，看返回的INSTANCE_NAME是否一致 - tnsnames.ora 中若只配了
SERVICE_NAME未指定INSTANCE_NAME，就极易触发该问题 - 多路会话（Multiplexed）连接模式会加剧此现象，因会话路由更不可控
如何确认是RAC节点分散导致的挂起
不靠猜，用最简验证法：
- 临时改用单实例连接串（如直连某台DB服务器的IP+端口+SID），F9后立刻可单步 → 基本锁定RAC分布问题
- 在调试卡住时，查
v$session：开两个会话，一个查SELECT sid, serial#, program, machine FROM v$session WHERE program LIKE '%PLSQL%'，另一个查SELECT instance_name FROM v$instance，比对sid归属的instance是否一致 - 观察tnsnames.ora里对应连接别名下是否有
INSTANCE_NAME或FAILOVER_MODE配置；没有即为高风险配置
绕过挂起的实操方案
优先选稳定、低侵入的方式：
- 修改tnsnames.ora，在
CONNECT_DATA段内显式添加(INSTANCE_NAME = your_inst_name)，确保两个会话强制落在同一节点 - 禁用Multiplexed连接：进入
Tools → Preferences → Connection，把Connection mode改为Normal（双路）而非Multiplexed—— 注意此时该PL/SQL Developer实例只能干一件事，不能同时写脚本、查表 - 避免在测试库频繁重编译：别人一次
CREATE OR REPLACE就可能清掉你的调试信息，导致你反复F9失败，误判为挂起
真正难处理的不是挂起本身，而是它常和权限缺失、调试信息丢失等现象并存。一旦F9后没反应，先做RAC分布验证，再回头查权限和编译状态——顺序错了，就会在错误的方向上浪费大量时间。
