plsql一直正在编译_使用plsql/devlop编译过程hang住案列小结

今天有位同事在使用plsql/devleop编译存储过程时老是导致整个操作界面hang住长时间无法响应，以下是我的处理过程，简要记录之。

1.查询v$session视图确定hang住的会话相关信息，比如event,blocking_session,sid,serail#等

在以上查询结果中发现此会话正经历library cache pin的等待事件，且通过blocking_session字段定位阻塞者的sid。

2.接着查询阻塞者会话的相关信息

此会话的sql_id字段为空，但是经历的event为SQL*Net more data from dblink,这里有个小疑问，根据等待事件应该可以认为该会话正在执行包含dblink的sql语句,可是此时的sql_id字段确为空？

3.由于当前需要对存储过程进行更新编译，所以考虑强制kill掉阻塞会话，不过这里通过alter system kill session命令无法完全杀掉该会话，且该数据库部署在windows平台上所以无法通过kill进程ID的方法释放该会话持有的资源。

4.根据第二步查询出来的module信息，发现阻塞会话其实是由于一个job进程自动调用的，于是考虑使用停止job的方法来释放该会话的资源。

5.通过查询dba_jobs_running和dba_scheduler_running_jobs数据字典确定了该job调用方式为scheduler。

6.使用dbms_schedule.stop_job存储过程尝试停止该job，这里需要增加参数'force=>true',否则会触发ORA-27478:job "TL.TEST_JOB" is running的错误，不过这里仍然无法停止该job。

7.正确的操作步骤应该是先使用dbms_scheduler.disable停用job，同样需要增加参数'force=>true',否则会触发ORA-27478:job "TL.TEST_JOB" is running的错误，执行成功后再次运行dbms_scheduler.stop_job(不要忘记加force参数)停止job。

8.接着编译存储过程，操作成功。

9.最后使用dbms_scheduler_enable启用job。