cursor:pin S wait on X

哎呀我的天吶發表於2015-05-08
AI

關於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/，如需轉載，請註明出處，否則將追究法律責任。

相關文章