cursor:pin S wait on X

关于library cache里的一些基本对象,基本原理在这就不赘述了  嘿嘿。我们来说说cursor pin s wait on X

                    Library Cache handle
  
我们对 Library cache 中所有对象的访问是通过利用 library cache handle 来实现的,也就是说我们想要访问 library cache object ,我们必须先找到 library cache handle Library cache handle 指向 library cache object, 它包含了 l i brary object 的名字,命名空间,时间戳,引用列表, lock 对象以及 pin 对象的列表信息等等。 Library cache handle 也被 library cache 用来记录哪个用户在这个这个 handle 上有 lock ,或者是哪个用户正在等待获得这个 lock 。那么这里我们也知道了 library cache lock 是发生在 handle 上的。

    当一个进程请求 library cache object, library cache manager 就会应用一个 hash 算法,从而得到一个 hash 值,根据相应的 hash 值到相应的 hash bucket 中去寻找。这里的 hash 算法原理与 buffer cache 中快速定位 block 的原理是一样的。如果 library cache object 在内存中,那么这个 library cache handle 就会被找到。有时候,当 shared pool 不够大, library cache handle 会保留在内存中,然而 library cache heap 由于内存不足被 age out ,这个时候我们请求的 object heap 就会被重载。最坏的情况下, library cache handle 在内存中没有找到,这个时候就必须分配一个新的 library cache handle ,同时 object heap 也会被加载到内存中。

Library Cache Object

 

Library Cache Object 是由一些独立的heap所组成,前面说了Library cache handle指向Library cache Object,其实handle是指向第一个heap,这个heap 我们就称之为heap 0。Heap 0记录了指向其他heap的指针信息。




select name,gets,misses,sleeps    from v$latch where name like '%library%';

Library Cache lock有3中模式:
Share(S):     当读取一个library cache object的时候获得
Exclusive(X): 当创建/修改一个library cache object的时候获得
Null(N):     用来确保对象依赖性

Library Cache pin有2种模式:
Share(S):     读取
object heap Exclusive(X):修改object heap

所以这里的cursor pin S wait on X 就是读(pin S)在等待修改(pin X)的情况,那么这说明了肯定有相同的sql在同时执行,不要然只有cursor pin S 或者cursor pin X。还有library cache 中有秀逗的object就是说,oracle不知道这些sql能否编译成功也要申请一块内存去编译。这样也会有pin X的。
--------------------------------------
--------------------------------------

Top 5 Timed Events

Event Waits Time(s) Avg Wait(ms) % Total Call Time Wait Class CPU time   10,061   76.0   cursor: pin S wait on X 254,229 2,485 10 18.8 Concurrency db file sequential read 148,935 428 3 3.2 User I/O direct path read 159,372 123 1 .9 User I/O gc cr multi block request 195,173 59 0 .4 Cluster


Library Cache Activity

"Pct Misses" should be very low

Namespace Get Requests Pct Miss Pin Requests Pct Miss Reloads Invali- dations BODY 674 1.63 2,474 2.75 53 0 CLUSTER 329 2.13 431 2.78 5 0 INDEX 45 51.11 133 18.05 1 0 SQL AREA 170,513 29.10 745,128 11.40 6,190 1,978 TABLE/PROCEDURE 72,027 1.22 389,103 2.27 4,134 0 TRIGGER 2,819 0.46 8,335 0.61 37 0

Back to Library Cache Statistics  

6190次还算是有些高,这个reload现象就是大sql文本进来和硬解析sql,同时有shared pool扩张的现象。

Cache Sizes


Begin End

Buffer Cache: 22,288M 22,128M Std Block Size: 8K Shared Pool Size: 2,128M 2,288M Log Buffer: 14,288K shared pool 在变大, Oracle只有在万不得已的情况下才会去resize pool

Time Model Statistics

Total time in database user-calls (DB Time): 13235.7s

Statistics including the word "background" measure background process time, and so do not contribute to the DB time statistic

Ordered by % or DB time desc, Statistic name

Statistic Name Time (s) % of DB Time DB CPU 10,060.63 76.01 parse time elapsed 8,461.29 63.93 sql execute elapsed time 6,271.82 47.39 hard parse elapsed time 5,951.34 44.9 6 hard parse (sharing criteria) elapsed time 18.15 0.14 PL/SQL execution elapsed time 15.16 0.11 hard parse (bind mismatch) elapsed time 8.31 0.06 failed parse elapsed time 3.53 0.03 PL/SQL compilation elapsed time 2.92 0.02 sequence load elapsed time 2.24 0.02 connection management call elapsed time 0.65 0.00 repeated bind elapsed time 0.26 0.00 DB time 13,235.66   background elapsed time 157.59   background cpu time 136.26  


SQL ordered by Sharable Memory

Only Statements with Sharable Memory greater than 1048576 are displayed

Sharable Mem (b) Executions % Total SQL Id SQL Module SQL Text 1,074,722 2 0.04 67p9d6rhbhg80 JDBC Thin Client select * from (select "GAMS_AS... 1,074,722 2 0.04 b2r48c8mwv1pw JDBC Thin Client select * from (select "GAMS_AS... 1,074,720 1 0.04 2rbxdyjc2kh98 JDBC Thin Client select * from (select "GAMS_AS... 1,074,718 1 0.04 76t18q2v1vsbm JDBC Thin Client select * from (select "GAMS_AS... 1,074,718 1 0.04 fn52y3mx8wmhq JDBC Thin Client select * from (select "GAMS_AS... 1,074,716 2 0.04 2cxfzr2xb0vnz JDBC Thin Client select * from (select "GAMS_AS... 1,074,716 2 0.04 ahf940uh6qn6h JDBC Thin Client select * from (select "GAMS_AS... 1,074,716 1 0.04 g7qnp8s33tym4 JDBC Thin Client select * from (select "GAMS_AS... 1,074,714 2 0.04 ay3p6x0ku8ps9 JDBC Thin Client select * from (select "GAMS_AS... 1,074,633 2 0.04 42j1ccmvt0qxc JDBC Thin Client select * from (select "GAMS_AS... 1,074,632 2 0.04 g2uzmn9xm99bc JDBC Thin Client select * from (select "GAMS_AS... 1,074,618 5 0.04 5mabhc2tpu1yk JDBC Thin Client select * from (select "GAMS_AS... 1,074,618 3 0.04 67b1kczyhay73 JDBC Thin Client select * from (select "GAMS_AS... 1,074,617 3 0.04 42yjwfxb387ky JDBC Thin Client select * from (select "GAMS_AS... 1,074,617 2 0.04 fs2w84hjrk0sy JDBC Thin Client select * from (select "GAMS_AS...

一个sql 占用空间大1.02483463M

latch: shared pool

Shared pool latch 用来保护共享池的结构,在分配,释放共享池空间的时候就会获得该 latch ,那么在这个案例中,由于共享池太小,在对一个新的 SQL 进行硬解析的时候需要age-out 某些对象,为新对象腾出空间,那么reload 对象 释放空间的过程就需要获得 shared pool latch 。当然了,在进行硬解析,也需要获得一个 shared pool latch 因为硬解析需要申请分配 shared pool 空间,而分配空间的时候就需要获得该 latch

参考:
http://blog.csdn.net/robinson1988/article/details/6037925

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

转载于:http://blog.itpub.net/29990276/viewspace-1629560/

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值