兩個概念：1、chain 2、chunk
SHARED POOL
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
FREE
這裏要引入一個概念：ORA—4031這是一個經典的free空間的報錯：
主要的原因就是 free中都是小的chunk，這時候來了一個大的sql語句做硬解析，而free中沒有大的chunk了，報ORA—4031
有人問了，爲什麼free中都是小的chunk了呢？主要是由於大量的硬解析，產生了大量的小的chunk（我們也稱之爲碎片），產生的過程見上圖
這就是爲什麼我看free還有200M，還會報ORA—4031的原因，因爲都是些小的chunk組成了你這200M啊~！！
有的DBA用 alter system flush shared_pool 這條命令去消除4031錯誤
這樣確實能佔時消除4031錯誤，因爲library cache鏈上的chunk被沒清空了，回到了free中，free中就有了大的chunk
但是，這是所有的sql都會走硬解析，隨着系統的運行，free中的chunk又回到了library cache中，繼續產生小的chunk在free中，最後還是可能會報4031錯誤
治標不治本，濛濛甲方還可以。。。。
------------------------------------------------------------------------------------------------------------------------------------------------------------
library cache
select count(*) from x$ksmsp; ---這個字典中每行對應shared_pool中的一個chunk，這條語句查的就是shared_pool中的chunk總數
如果oracle執行了硬解析，那麼chunk數就會增加。所以有時候我們可以用這條語句去看一段時間內是否做了大量的硬解析（行數大量增加）
當然我們一般還是用這個語句去看解析的狀況：select name,value from v$sysstat where name like 'parse%';
注：我上圖中，oracle去5號鏈上遍歷，會把5號鏈鎖住（libaray cache latch），這樣的話如果咱們吧shared_pool設的很大，library cache中緩存的sql/執行計劃就會很多，鏈就會很長，那麼遍歷的時間就長，鎖住鏈的時間就會很長。