簡單分析shared pool(一) (r3筆記46天)
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
[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
[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的增長，對應的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的，只能在根據需要的時候才釋放空間。