晚上開發人員告訴我，過程一編譯就當機。檢視v$session_wait有library cache pin等待。開發人員告訴我，編譯前執行過這個過程，發現有誤透過kill -9把JOB殺了,job是過程建立的。（並沒有殺程式，而是殺的JOB）

根據幾個系統內部表一步步的找到了阻塞編譯的會話。
select a.sid,a.username,a.program,b.addr,b.KGLPNADR,b.KGLPNUSE,b.KGLPNSES,b.KGLPNHDL,
b.kGLPNLCK, b.KGLPNMOD, b.KGLPNREQ
from v$session a,x$kglpn b
where a.saddr=b.kglpnuse and b.kglpnhdl = 'C0000005C63EBD48' and b.KGLPNMOD<>0

kglpnhdl 的值是v$session_wait裡的p1raw的值。根據查詢結果，發現sid為7432的會話擁有這個handle。

查詢這個會話的v$session_wait，存在一條記錄，顯示等待gc current multi block request。一般來說這個等待很短，可是我執行了N此查詢，這個等待一直都存在，其實這個會話已經死掉了。

根據v$session,v$process找到作業系統程式，然後kill -9掉，問題解決。

還有一點不明白：一個過程執行過程中，這個時候有人編譯，會產生library cache pin嗎？

如果一個過程正在執行，這個時候編譯這個過程，會產生library cache pin

相關文章