如何解決library cache pin及library cache lock故障

這期內容當中小編將會給大家帶來有關如何解決library cache pin及library cache lock故障，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

某個客戶， 突然發生前端零售業務卡頓的情況。因為當時在處理其他客戶的事宜， 所以當時沒有進行monitor。由另外一位同事進行處理， 直接緊急重啟了應用。
問題解決。但是業務不得已中斷。
事后調查原因， 從卡頓的時間段來看發現大量的library cache pin等待事件，并且伴有library cache lock。

另外，同事也保存了阻塞相關的會話信息
create table block_sess1018 as
select *  from v$session where blocking_session is not null
結合
select * from dba_hist_active_sess_history h where h.sample_time > to_date('20171018 15:25:00', 'yyyymmdd hh34:mi:ss')
and  h.sample_time < to_date('20171018 16:00:00', 'yyyymmdd hh34:mi:ss') and event like 'library cache%'

library cache pin幾個參數的意思：

p1=handle address
p2=pin address
p3=namespace&&encoded mode

對于p1raw可以對應于x$kglob中的KGLHDADR字段x$kglpn中的KGLPNHDL字段，x$kgllk中的KGLLKHDL字段，后邊有sql關聯。

dba_hist_active_sess_history中的P1可以轉換成16進制之后，再去v$object_dependency通過to_address定位到pin的對象

SQL> select  s.sid, s.saddr, sw.p1raw
     from v$session_wait sw, v$session s
     where sw.sid = s.sid and sw.event='library cache pin';

       SID SADDR            P1RAW
---------- ---------------- ----------------
        53 0000000077204A80 000000006DBC5BE8  

Now using the P1RAW and SADDR values find the the address of the user session that is holding the lock

SQL> select b.KGLLKUSE from dba_kgllock w , dba_kgllock b
     where w.KGLLKHDL  = b.KGLLKHDL
     and   w.KGLLKREQ  > 0 and b.KGLLKMOD > 0
     and   w.KGLLKTYPE = b.KGLLKTYPE
     and   w.KGLLKUSE  = '0000000077204A80' -- SADDR
     and   w.KGLLKHDL  = '000000006DBC5BE8' -- P1RAW

 select to_owner, to_name from v$object_dependency 
     where to_address = '000000016B500270';

select * from dba_ddl_locks where owner = 'HR';

找到了library cache pin的對象。

再進一步發現（通過logminer挖掘日志），故障開始前，有開發的同事對一個基礎表進行了DDL操作，引發了其后一連串的編譯的動作(有很多對象依賴于此表)。
很多對象，比如觸發器（產品的邏輯很多是用觸發器完成）， 過程，函數，視圖等依賴于此表。
由于此時正值業務高峰，所以出現了大面積的卡頓。

以下是DDL時間順序




執行的DDL語句:

上述就是小編為大家分享的如何解決library cache pin及library cache lock故障了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。