Library cache lock 故障解决一例

今天收到同事电话，说是数据库中一张名为acct_balance进行操作是奇慢，第一反映是不是扫行计划有问题，结果我错了，现将过程记录下来。

用pl/sql连上数据库情况：1、对acct_balance表的查询很慢，正常少于0.1s完成，现在要60s完成；2、使用explain plan对语句进行分析，过析比正常情况下慢很多。

下面为处理过程：
1、从v$session_wait中查找有问题的wait
Sql>select event,count(*) from
v$session_wait group by event

2、如果有library cache lock时，查看lock的都是些什么语句

SELECT a.username, a.machine, a.program, a.sid,
a.serial#, a.status, c.piece, c.sql_text
FROM v$session a, v$process b,
v$sqltext c
WHERE b.addr=a.paddr AND a.sql_address=c.address(+)
and
a.sid in (select sid from v$session_wait where event = 'db file sequential
read')
and a.sid =2646
ORDER BY a.sid,c.piece

3、发现有Library语句我们需要进一步blocker会话是谁

SELECT s.sid, kglpnmod "Mode", kglpnreq "Req", SPID "OS
Process"
FROM v$session_wait w, x$kglpn p, v$session s ,v$process o
WHERE
p.kglpnuse=s.saddr
AND kglpnhdl=w.p1raw
and w.event like '%library cache
lock%'
and s.paddr=o.addr

结果中发现

SID       Mode        Req OS
Process

----------
---------- ---------- ------------

396          0          2
6381970

396          0          2
6381970

396          0          2
6381970

396          0          2
6381970

341          3          0
4092132

341          3          0
4092132

从上可以看出341以exclusive模式lock住library cache lock,为时396被迫等待，事情差不多能解决了，我直接kill了341的进程，acct_balance表恢复正常

4、故障原因：

1）主机在3月4日晚6点自动执行对地州查询用户授权时，grant和revoke语句阻塞在library cache中，造成library cache lock,阻塞进程一直停留在GRANT SELECT ON ACCT.ACCT_BALANCE TO UQRY过程中，使其它对acct_balance表访问的语句无法正常命中library cache数据，从而导致对acct_balance访问速度下降。

2）进一步对阻碍的原因进行跟踪，发现系统中存在使用plsql工具的可疑帐号，该帐号客户端名为YNTELCOM,用户名为GH@BYN,登陆时间为2010年3月4日13：00点左右，因无法抓取出该帐号操作记录，阻碍真正原因暂不确定。推断原因为：①、操作人员执行不可预知SQL语句；②、操作人员使用非正常手段退出plsql工具。

注：关连表信息

SQL> desc x$kgllk;
名称 类型
----------
-----------
ADDR RAW(4)
INDX NUMBER
INST_ID NUMBER
KGLLKADR
RAW(4)
KGLLKUSE RAW(4) ---会话地址(对应v$session的saddr)
KGLLKSES
RAW(4) ---owner地址
KGLLKSNM NUMBER
---SID
KGLLKHDL RAW(4) ---library cache object 句柄
KGLLKPNC RAW(4)
---the address of the call pin
KGLLKPNS RAW(4) ---对应跟踪文件中的session
pin值
KGLLKCNT
NUMBER
KGLLKMOD NUMBER ---持有锁的模式(0为no lock/pin
held﹐1为null,2为share﹐3为exclusive)
KGLLKREQ NUMBER ---请求锁的模式(0为no lock/pin
held﹐1为null,2为share﹐3为exclusive)
KGLLKFLG NUMBER ---cursor的状态﹐8(10g前)或2048(10g)表示这个sql正在运行﹐
KGLLKSPN NUMBER
---对应跟踪文件的savepoint的值
KGLLKHTB
RAW(4)
KGLNAHSH NUMBER ---sql的hash值(对应v$session的sql_hash_value)
KGLLKSQLID VARCHAR2(13) ---sql
ID，sql标识符
KGLHDPAR RAW(4)
---sql地址(对应v$session的sql_address)
KGLHDNSP NUMBER
USER_NAME VARCHAR2(30)
---会话的用戶名
KGLNAOBJ
VARCHAR2(60) ---对象名称或者已分析并打开cursor的sql的前60个字符

3)
x$kglpn
X$KGLPN--[K]ernel [G]eneric [L]ibrary Cache Manager object
[P]i[N]s
它是与x$kgllk相对应的表﹐是关于pin的相关信息。它主要用于解决library cache
pin
引用该表的视图有﹕
DBA_KGLLOCK

SQL> desc x$kglpn;
名称 类型
------------
----------------------------
ADDR RAW(4)
INDX NUMBER
INST_ID
NUMBER
KGLPNADR RAW(4)
KGLPNUSE RAW(4) ---会话地址(对应v$session的saddr)
KGLPNSES
RAW(4) ---owner地址
KGLPNHDL RAW(4)
---句柄
KGLPNLCK
RAW(4)
KGLPNCNT NUMBER
KGLPNMOD NUMBER ---持有pin的模式(0为no lock/pin
held﹐1为null,2为share﹐3为exclusive)
KGLPNREQ NUMBER ---请求pin的模式(0为no lock/pin
held﹐1为null,2为share﹐3为exclusive)
KGLPNDMK NUMBER
KGLPNSPN NUMBER
---对应跟踪文件的savepoint的值

----------------------
x$kglpn  kglpnuse 会话的saddr KGLLKMOD
持有的锁 KGLPNREQ
请求锁模式
x$kgllk 
kgllkuse 会话的saddr
KGLPNMOD持有的锁 KGLLKREQ
请求锁模式
Kglhdlmd是Library cache
lock的模式，为0时表示没有锁，1是NULL锁，2是共享锁，3是独占锁。Kglhdpmd是Library cache
pin的模式，0是没有Pin，2是共享Pin，3是独占Pin
x$kgllk
KGLLKSNM NUMBER
---SID
-----------------------------------------x$kglob
 父游标、子游标都有记录
 kglhdadr:
本记录游标地址
 kglhpadr:
父游标地址
 kglhdobj:LIBRARY OBJECT(代表 library object
handle 的物理地址)
 kglobhd0:heap0
的地址
 ......
 kglobhd7:heap7的地址
一个sql语句至少有一个子游标，所有在x$kglob里至少有2个library cache
object
一个sql的library cache
至少有2个堆heap 0 heap
6