library cache lock调整

最新推荐文章于 2023-03-16 16:51:06 发布

cuijiu2464

最新推荐文章于 2023-03-16 16:51:06 发布

阅读量60

点赞数

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

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

下面为处理过程：
t8eOqH FR(rVK;k254965851、从v$session_wait中查找有问题的waitITPUB个人空间;K0pmt]+B:^-n
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
,[pYEr25496585FROM v$session a, v$process b, v$sqltext cITPUB个人空间`Ne#att4D
WHERE b.addr=a.paddr AND a.sql_address=c.address(+)ITPUB个人空间8D*W z:r{c{tVb
and a.sid in (select sid from v$session_wait where event = 'db file sequential read')ITPUB个人空间o/I%B PDX s5Z3T{
and a.sid =2646
h\/w;oRlt eZ6I25496585ORDER BY a.sid,c.piece

#cssMT"T {,G~1]254965853、发现有Library语句我们需要进一步blocker会话是谁

SELECT s.sid, kglpnmod "Mode", kglpnreq "Req", SPID "OS Process"ITPUB个人空间G9V(J vtM X_ c.Z
FROM v$session_wait w, x$kglpn p, v$session s ,v$process o
HCW B;t%t25496585WHERE p.kglpnuse=s.saddr
%x3f?3G$jU K]25496585AND kglpnhdl=w.p1raw
c+{~"P4| { r O25496585and w.event like '%library cache lock%'ITPUB个人空间:F:|]!l[ d
and s.paddr=o.addr

结果中发现

SID Mode Req OS Process

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

396 0 2 6381970

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;ITPUB个人空间^;w Npp[R.M
名称类型
V s1[n~25496585---------- -----------ITPUB个人空间;r;Y2_^M'x*M
ADDR RAW(4)ITPUB个人空间;B:s8J2g9mf7L.Tf1f
INDX NUMBER
#L$^Nl%R25496585INST_ID NUMBERITPUB个人空间#G o x)w._&]!O$?(leF
KGLLKADR RAW(4)
a;r5C5c^KUa3I"K25496585KGLLKUSE RAW(4) ---会话地址(对应v$session的saddr)
x,gWNI6Sr5p&c6m25496585KGLLKSES RAW(4) ---owner地址ITPUB个人空间Z#r:ZZG
KGLLKSNM NUMBER ---SID
g%^`/Rj} Sd^*r25496585KGLLKHDL RAW(4) ---library cache object句柄ITPUB个人空间,x;N7u0x#c i Gb aB
KGLLKPNC RAW(4) ---the address of the call pinITPUB个人空间 v'F x0f&H$i,F
KGLLKPNS RAW(4) ---对应跟踪文件中的session pin值
1DA Qm_^ Z9s25496585KGLLKCNT NUMBER
!o)^} vfv:|25496585KGLLKMOD NUMBER ---持有锁的模式(0为no lock/pin held﹐1为null,2为share﹐3为exclusive)ITPUB个人空间9\\,P+Zp
KGLLKREQ NUMBER ---请求锁的模式(0为no lock/pin held﹐1为null,2为share﹐3为exclusive)ITPUB个人空间I? Y.[)C{)ap8?L
KGLLKFLG NUMBER ---cursor的状态﹐8(10g前)或2048(10g)表示这个sql正在运行﹐ITPUB个人空间4aNU\BNIc
KGLLKSPN NUMBER ---对应跟踪文件的savepoint的值ITPUB个人空间6vRL/jHF)q
KGLLKHTB RAW(4)
pu L\e6hz_*[25496585KGLNAHSH NUMBER ---sql的hash值(对应v$session的sql_hash_value)
HI vC1x\25496585KGLLKSQLID VARCHAR2(13) ---sql ID，sql标识符ITPUB个人空间vP;?^S.Mt"Oz
KGLHDPAR RAW(4) ---sql地址(对应v$session的sql_address)
5HsXU/B#b y0y$e25496585KGLHDNSP NUMBERITPUB个人空间4L[)_5UX4s n
USER_NAME VARCHAR2(30) ---会话的用戶名ITPUB个人空间|lKHeH lO@]
KGLNAOBJ VARCHAR2(60) ---对象名称或者已分析并打开cursor的sql的前60个字符

3) x$kglpnITPUB个人空间Or lU]$H)g
X$KGLPN--[K]ernel [G]eneric [L]ibrary Cache Manager object [P]i[N]sITPUB个人空间i6N:h o{sV9@mJ
它是与x$kgllk相对应的表﹐是关于pin的相关信息。它主要用于解决library cache pinITPUB个人空间1wc5fW&r'l5O
引用该表的视图有﹕ITPUB个人空间9Q G{4?/Vi)RH b_K
DBA_KGLLOCK

SQL> desc x$kglpn;
8pNt9v)g^25496585名称类型ITPUB个人空间xw0S_ W#mE7n
------------ ----------------------------
Q+GAm4{\nI25496585ADDR RAW(4)
)d)K^Ws~ ]om25496585INDX NUMBER
6R/Z'G"? J$T?ssL#?25496585INST_ID NUMBERITPUB个人空间e{5_sGo
KGLPNADR RAW(4)
s T/Qo5CnEW[25496585KGLPNUSE RAW(4) ---会话地址(对应v$session的saddr)
%]-H4{ i#X,hy/S(P]2a!X25496585KGLPNSES RAW(4) ---owner地址
n.Y0T(er0T25496585KGLPNHDL RAW(4) ---句柄ITPUB个人空间Iw nO~:[
KGLPNLCK RAW(4)
1pnG3^!shw25496585KGLPNCNT NUMBER
7TS8??}*e25496585KGLPNMOD NUMBER ---持有pin的模式(0为no lock/pin held﹐1为null,2为share﹐3为exclusive)
'uQ%F0O9~J4QUn25496585KGLPNREQ NUMBER ---请求pin的模式(0为no lock/pin held﹐1为null,2为share﹐3为exclusive)
lx_ _"E25496585KGLPNDMK NUMBERITPUB个人空间z Y0f3o(]8\ Dqsz
KGLPNSPN NUMBER ---对应跟踪文件的savepoint的值

----------------------ITPUB个人空间 n.xJ+dGU.d8\
x$kglpn kglpnuse会话的saddr KGLLKMOD持有的锁KGLPNREQ请求锁模式ITPUB个人空间:|6zk"{Vf2[_D
x$kgllk kgllkuse会话的saddr KGLPNMOD持有的锁KGLLKREQ请求锁模式ITPUB个人空间(D1m)G0ri5F/D aP
Kglhdlmd是Library cache lock的模式，为0时表示没有锁，1是NULL锁，2是共享锁，3是独占锁。Kglhdpmd是Library cache pin的模式，0是没有Pin，2是共享Pin，3是独占Pin
`7i e&@"L25496585x$kgllk KGLLKSNM NUMBER ---SID
c&N%pnm/X N4R25496585-----------------------------------------x$kglob
Y{a{gTiv25496585 父游标、子游标都有记录ITPUB个人空间 ADVX+c3Ry ]
kglhdadr:本记录游标地址
%?-V F9m!T'H_w Ea25496585 kglhpadr:父游标地址ITPUB个人空间:]e0ObV%N dT(A:`_
kglhdobj:LIBRARY OBJECT(代表library object handle的物理地址)ITPUB个人空间S#N'D'?(qph
kglobhd0:heap0的地址
I+rPL6J9e7t25496585 ......ITPUB个人空间| O!uJ1Nx6` K}IlS
kglobhd7:heap7的地址ITPUB个人空间{)H[u*])c9} i7V
一个sql语句至少有一个子游标，所有在x$kglob里至少有2个library cache objectITPUB个人空间8Z2A3Nv IED
一个sql的library cache至少有2个堆heap 0 heap 6

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/25496585/viewspace-689254/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/25496585/viewspace-689254/

cuijiu2464

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
library cache lock调整

今天收到同事电话，说是数据库中一张名为acct_balance进行操作是奇慢，第一反映是不是扫行计划有问题，结果我错了，现将过程记录下来。用pl/sql连上数据库情况：1、对acct_balance表的查询很慢，正常少于0....
复制链接

扫一扫