【故障现象】

某些session执行操作被堵塞，检查event发现’library cache lock/pin’等待；

【可能故障原因】

library cache lock/pin发生在多个session对相同library cache对象进行争用发生，一般来说在存储过程编译过程中发生并堵塞编译。

【应急措施】

堵塞和被堵塞session在同一个实例上：

查找导致library cache lock/pin的对象；

1

2

3

4

SELECT 
KGLNAOWN,KGLNAOBJ

FROM 
x$kglob 

WHERE 
kglhdadr 
in
(

select 
P1RAW 
from 
v$session_wait 
where 
event 
like 
'library cache%'
);

继续查找那些session导致了library cache lock/pin等待：

1

2

3

4

5

6

select 
sid, serial#,program ,machine 
from 
v$session

where 
paddr 
in 
(

SELECT 
s.paddr 
FROM 
x$kglpn p, v$session s

WHERE 
p.kglpnuse=s.saddr(+) 
AND 
p.kglpnmod <> 0 
and 
kglpnhdl 
in 
(

select 
p1raw  
from 
v$session_wait

where 
event 
in 
(
'library cache pin'
,
'library cache lock' 
,
'library cache load lock'
)));

注：如果上述SQL时间执行时间较长，可手动分步执行，如先执行IN中的子SQL。

根据实际情况严重程度进行如下紧急处理：

a) 对所有导致library cache lock/pin的session进行kill，解决堵塞情况。

堵塞和被堵塞session不在同一个实例上：

查找导致library cache lock/pin的对象；（同情况1）

1

2

3

4

SELECT 
KGLNAOWN,KGLNAOBJ

FROM 
x$kglob 

WHERE 
kglhdadr 
in
(

select 
P1RAW 
from 
v$session_wait 
where 
event 
like 
'library cache%'
);

在其他实例上陆续进行查找导致了library cache lock/pin等待的session，首先确认其他实例上的堵塞对象的地址，参考上面查询结果：

1

2

3

4

5

select 
sid, serial#, sql_text 
from 
dba_kgllock w, v$session s, v$sqlarea a

where 
w.kgllkuse = s.saddr 
and 
w.kgllkhdl 
in
(

select 
kglhdadr 
from 
x$kglob 
where 
kglnaown=
'SYS' 
and 
kglnaobj = 
'DUMMY'
)

and 
s.sql_address = a.address

and 
s.sql_hash_value = a.hash_value;

根据实际情况严重程度进行如下紧急处理：

a) 对所有导致library cache lock/pin的session进行kill，解决堵塞情况。

注意在os级别kill之前，先用ps命令查看一下该进程，如果是DB进程，不可随意kill，否则会导致系统crash

【后续分析】

此类问题主要是由于并发执行对象编译导致的，解决思路就是将编译动作串行执行，减少并发争用。

同时，后续需要查询此类操作为什么发起，在业务高峰期应当避免。

ITPub博客

library cache lock/pin排查与处理

最新文章