关于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

Library Cache Activity

• "Pct Misses" should be very low

Back to Library Cache Statistics 

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

Cache Sizes

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.96
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

--------再看个例子-------

Top 5 Timed Events

RAC Statistics

对于oracle数据库中的latch，如果进程无法获得某个latch，那么会进行自旋，我们称为spin，经过一段时间后再次申请获得该latch，如果仍然无法获得，那么继续进行自旋状态，每次的时间间隔逐渐增加，以此类推。如果spin次数达到_spin_count（默认为2000，当前该系统为4000）之后，仍然无法获得该latch，那么该进程将进行sleep状态，经过一段时间后，该进程将被唤醒，继续申请获得该latch，每sleep 1次，Sleeps指标的值加1. spin和sleep的区别是spin消耗cpu，sleep不消耗cpu

再提及row cache lock，数据字典dc_等待，

Dictionary Cache Stats

• "Pct Misses" should be very low (< 2% in most cases)
• "Final Usage" is the number of cache entries being used

Back to Dictionary Cache Statistics  
Back to Top

buffer busy waits不单单是数据块上的，

Buffer Wait Statistics

• ordered by wait time desc, waits desc

Back to Wait Statistics  
Back to Top