使用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。

    至此，案列總結完畢！