library cache pin LATCH等待

[复制链接]
查看11 | 回复9 | 2013-3-27 11:17:11 | 显示全部楼层 |阅读模式
Top 5 Timed Events
Event Waits Time(s) Avg Wait(ms) % Total Call Time Wait Class
library cache pin 349 933 2,672 88.8 Concurrency
CPU time
59 5.6
library cache lock 10 25 2,515 2.4 Concurrency
control file parallel write 412 13 32 1.3 System I/O
log file parallel write 1,230 10 8 1.0 System I/O
做了AWRRPT library cache pin LATCH排在第一,我知道一些九个LATCH的概念,
但是如何找到是哪里导致的library cache pin?我需要定位到具体的包上去啊,谢谢。
回复

使用道具 举报

千问 | 2013-3-27 11:17:11 | 显示全部楼层
关注下...
回复

使用道具 举报

千问 | 2013-3-27 11:17:11 | 显示全部楼层
PIN的作用是去修改chunk的表或者索引或者其他一些公用的信息,包过执行计划。
发生PIN的的话是否你有编译一些东西,或者修改表之类,导致表信息从SHARE_POOL刷出,然后再载入。 系统如果繁忙,那么PIN等待是有可能的,

总体我觉得,Library cache latch 可能性比较大,但是PIN和LOCK如果有,多半是表,索引信息之类被刷新, 比如SHARE_POOL比较小,导致不停的刷出去,然后再载入,那么可能有PIN和LOCK。 你可以在发生这个等待的时候抓出SQL,看看到底是那些对象出现这个等待,然后再做动作
回复

使用道具 举报

千问 | 2013-3-27 11:17:11 | 显示全部楼层
在发生libarary cache pin时,可以使用如下sql来定位问题。session,process,object情况都可以得到
select distinctdecode(lob.kglobtyp,

0,

'NEXT OBJECT',

1,

'INDEX',

2,

'TABLE',

3,

'CLUSTER',

4,

'VIEW',

5,

'SYNONYM',

6,

'SEQUENCE',

7,

'PROCEDURE',

8,

'FUNCTION',

9,

'PACKAGE',

11,

'PACKAGE BODY',

12,

'TRIGGER',

13,

'TYPE',

14,

'TYPE BODY',

19,

'TABLE PARTITION',

20,

'INDEX PARTITION',

21,

'LOB',

22,

'LIBRARY',

23,

'DIRECTORY',

24,

'QUEUE',

28,

'JAVA SOURCE',

29,

'JAVA CLASS',

30,

'JAVA RESOURCE',

32,

'INDEXTYPE',

33,

'OPERATOR',

34,

'TABLE SUBPARTITION',

35,

'INDEX SUBPARTITION',

40,

'LOB PARTITION',

41,

'LOB SUBPARTITION',

42,

'MATERIALIZED VIEW',

43,

'DIMENSION',

44,

'CONTEXT',

46,

'RULE SET',

47,

'RESOURCE PLAN',

48,

'CONSUMER GROUP',

51,

'SUBSCRIPTION',

52,

'LOCATION',

55,

'XML SCHEMA',

56,

'JAVA DATA',

57,

'SECURITY PROFILE',

59,

'RULE',

62,

'EVALUATION CONTEXT',

'UNDEFINED') object_type,
lob.KGLNAOBJ object_name,
pn.KGLPNMOD lock_mode_held,
pn.KGLPNREQ lock_mode_requested,
ses.sid,
ses.serial#,
ses.username,
ses.process,
vp.spid
FROM x$kglpn pn, v$session ses, x$kglob lob, v$session_wait vsw, v$process vp
WHERE pn.KGLPNUSE = ses.saddr
and pn.KGLPNHDL = lob.KGLHDADR
and lob.kglhdadr = vsw.p1raw
and ses.PADDR= vp.ADDR
and vsw.event = 'library cache pin'
order by lock_mode_held desc;
回复

使用道具 举报

千问 | 2013-3-27 11:17:11 | 显示全部楼层
如果是10G,通过dba_hist_active_session 之类的视图查看某些SQL等待这个事件
回复

使用道具 举报

千问 | 2013-3-27 11:17:11 | 显示全部楼层
楼上那SQL太烦, 查看hist 的session,看看那些SQL等待什么就很容易知道了。没必要搞个那么大的SQL查询
回复

使用道具 举报

千问 | 2013-3-27 11:17:11 | 显示全部楼层
并不是那么简单,就算你从v$session_wait或者 10g的hist表找到此发生此wait的session 了,要想找到最终祸首,还是要关联这些表的。
当然sql可以简化,去掉你不想要的信息!
[ 本帖最后由 flying.hg 于 2009-9-17 18:11 编辑 ]
回复

使用道具 举报

千问 | 2013-3-27 11:17:11 | 显示全部楼层
你SQL拿出来的是什么? 也不过是一些ob.KGLNAOBJ object_name,
pn.KGLPNMOD lock_mode_held,
pn.KGLPNREQ lock_mode_requested。
就算拿到上面的又能如何?

通过v$sssion_wait或者hist拿出SQL,一目了然。
回复

使用道具 举报

千问 | 2013-3-27 11:17:11 | 显示全部楼层
呵呵,,,还是比较深奥的东西
回复

使用道具 举报

千问 | 2013-3-27 11:17:11 | 显示全部楼层
对这两个视图没有太多的认识
x$kglpn,x$kglob学习下
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

主题

0

回帖

4882万

积分

论坛元老

Rank: 8Rank: 8

积分
48824836
热门排行