簡單分析shared pool(一)

oracle中的shared pool很重要，但是感覺知之甚少。今天想在原來的認識上能夠有一點更深入的瞭解。
簡單做了一個總結。
首先是轉儲一下shared pool共享記憶體的內容。
SQL> alter session set events 'immediate trace name heapdump level 2';
Session altered.
這個步驟會得到一個trace檔案。簡單的換算一下，就得到了trace檔案的大體資訊。

SQL> select sid from v$mystat where rownum<2;
       SID
----------
        24
SQL> select sid,serial# ,paddr from v$session where sid=24;
       SID    SERIAL# PADDR
---------- ---------- ----------------
        24         83 00000000727B03B0
SQL> select spid from v$process where addr='00000000727B03B0';
SPID
------------------------
18155
SQL> host
簡單驗證一下，對應的process是否存在。
[ora11g@rac1 ~]$ ps -ef|grep 18155
ora11g   18155 18106  0 06:00 ?        00:00:02 oracleTEST01 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
ora11g   19326 19167  0 06:21 pts/0    00:00:00 grep 18155
在trace檔案目錄下檢視日誌檔案是否存在。

[ora11g@rac1 trace]$ ls -l *18155*.trc
-rw-r----- 1 ora11g dba 6900360 Nov  4 06:11 TEST01_ora_18155.trc
對於shared pool來說，儲存單位是chunk,多個chunk組成一個連結串列，也叫做bucket.
每個bucket都對chunk的大小都有一定的範圍，是一個連續的值，沒有交叉。
在10g，11g中都設定了255個bucket。
簡單透過trace檔案來看一下。
[ora11g@rac1 trace]$ grep Bucket *18155*.trc
 Bucket 0 size=32
 Bucket 1 size=40
 Bucket 2 size=48
 Bucket 3 size=56
 Bucket 4 size=64
 Bucket 5 size=72
...
 Bucket 250 size=12352
 Bucket 251 size=12360
 Bucket 252 size=16408
 Bucket 253 size=32792
 Bucket 254 size=65560
可能對於bucket的大小沒有一個直觀的感受，可以生成一個圖來看看就很清楚了。

隨著bucket的增長，對應的chunk大小都在遞增，絕大多數的bucket中，chunk的大小都在5k以內。只有很小的一部分bucket的支援的chunk size很大，
這個也是oracle在不斷的改進中得到的一個最優值，按照比例來劃分，保證每次訪問需要的chunk大小都能夠合理的分配，儘量減少冗餘。
同時不是每個bucket裡面都是有chunk的，這個chunk的分配還是根據進入shared pool以後申請chunk大小緊密相關，bucket中的chunk數目可不是平均的。


如果想看看shared Pool比較細節一下的資訊。可以參考x$ksmsp
這個基表中還是包含了不少的資訊值得我們去學習。首先x$ksmsp裡面的每一條記錄代表一個chunk

SQL> select count(*)from x$ksmsp;

  COUNT(*)
----------
     53317
如果你馬上執行了一個其它的查詢，再來看x$ksmsp的條數，就很可能發生變化。
SQL> select count(*)from all_objects;

  COUNT(*)
----------
     13225

SQL> select count(*)from x$ksmsp;

  COUNT(*)
----------
     53363

大體來說對於chunk的分配還是一個動態的過程，比如shared pool分為library cache,dictionary cache,如果chunk存放的sql相關的資訊時，chunk就屬於library cache.
如果chunk存放的資訊時dictionary cache的話，chunk就屬於dictionary cache.
按照大多數物件的生命週期，chunk的情況也大體如此，可能在不同的資料庫版本中會略有不同。
比如在11gR2中的結果會和10g有一些不同。chunk的狀態可能有多種，但是大體還是可以理解為4類，free,recr,perm,freeable
KSMCHCLS   COUNT(*)
-------- ----------
freeabl       20196
recr          26469
perm            581
R-freea         134
R-free           60
R-perm            4
free           5918
R-recr            1

首先,可以分配空間的chunk,這種型別的chunk是free,
如果某個session執行的sql語句，同時另外一個session也執行了同樣的sql語句，在shared pool中這種型別的chunk就可以臨時移出記憶體，因為可以在需要的時候進行重建。這種chunk就是recreatable的。
如果某個session執行的sql語句都是不同的，或者沒有繫結變數，導致在執行的時候生成的sql_id都不同，這種型別的chunk是不能臨時欲出記憶體的，只能在需要的時候進行釋放。這種chunk就是freeable的。
如果某個物件透過dbms_pool給直接pin在了shared pool裡面，那麼對應的chunk就是permanent的，只能在根據需要的時候才釋放空間。