今天有位同事在使用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。
至此，案列总结完毕！
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/20801486/viewspace-1063758/ ，如需转载，请注明出处，否则将追究法律责任。
