SHARED POOL作爲一塊共享內存區域是SGA的重要組件之一，所以對其優化是有必要的而且是必須的。下面主要是介紹SHARED POOL的優化思路，SGA的組成結構以及每個結構的包括的內容及其作用不做介紹：
1.確保shared pool的大小足夠：
隨着新版本的推出，存放在oracle中的組件越來越多，對shared pool的要求也就越來越高。如果數據庫升級，建議適當的擴大shared pool。當shared pool內存不夠的時候，相關的組件會因爲內存不足而產生爭用，而且如果shared pool內存緊張，還可能導致cursor失效或者頻繁的被交換出shared pool，可以使用dbms_shared_pool.keep將重要的cursor保存在shared pool中。
2.使用sub pool：
從Oracle9i開始，Oracle推出了sub pool技術，即在shared pool中分出多個子池，每個子池獨立的擁有shared pool latch。從理論上來說sub pool技術提高了shared pool的併發能力，但是sub pool相當於分割成了幾個內存片，服務器進程在其中一個sub pool中分配不到內存的時候，不會無限制的去另外的sub pool中去尋找空閒的內存，所以sub pool技術增大了ora-04031的錯誤發生概率。
3.對於shared pool，夠用就行：
如果shared pool過大，oracle就會儘可能的利用shared pool中的內存，當其搜索cursor時的效率會大大降低，搜索期間會持有各類的mutex和latch，從而導致數據庫的性能下降。所以也需要注意在自動內存管理的情況下，shared pool過度擴張的情況。
4.注意內存碎片：
當shared pool中出現內存碎片的時候，不能貿然的flush shared pool，嚴重的時候會hang住整個實例。不要對對象進行頻繁的DDL、賦權、收集統計信息等操作，這些操作會使shared pool中相關的cursor失效，cursor無效則會加劇row cache和library cache爭用，降低數據庫的性能。
5.儘可能的使用軟解析：
shared pool上的性能問題很大程度上是由併發引起的，當發生大量的硬解析的時候，最好能夠從應用層修改代碼，如果應用程序無法修改，則建議設置cursor_sharing參數爲force（設置爲similar可能存在較多的bug，需要注意），並根據應用設置session_cached_cursors和open_cursors參數。
6.注意綁定變量窺視：
如果sql中的選擇謂詞存在柱狀圖，其上有有綁定變量，那麼就需要注意綁定變量窺視的問題了。綁定變量窺視容易引起執行計劃不穩定。在rac系統中，可能會導致節點之間sql執行計劃不同的情況。
7.注意sql高版本：
高版本的sql會導致服務器進程搜索handle的時間變長，從而加大了library cache latch的爭用的概率。oracle bug 往往會導致sql的版本莫名的升高。
8.不要收集無意義的柱狀圖：
如果sql的執行計劃穩定，那麼收集過多的柱狀圖反而會增加row cache的壓力，嚴重時會引起row cache objects latch爭用。
9.注意Oracle bug：
由於Oracle不斷的往shared pool中引入新特性，新特性往往會帶來新的bug，當shared pool出現莫名的性能問題時，需要檢查是否是由bug引起的。
注：摘錄自《DBA實戰攻略》