共享池最佳化思路

共享池的最佳化要從幾個方面去考慮：首先是共享池本身的配置，其次是遊標的共享，然後是緩解共享池的碎片，最後是分析Bug 和補丁。                                            
  共享池配置主要是看共享池的容量是否足夠。10 多年前，DBA 管理共享池是十分痛苦的，     
  由於實體記憶體總是無法滿足應用系統的需要，因此總是無法分配給共享池足夠的空間，我們必須
  想盡一切辦法來減少應用對共享池的使用，從而使更多的併發訪問能夠儘可能地對共享池產生最
  小的影響。而共享池管理總是希望某個字典快取或者庫快取能夠在共享池中儲存更多的時間。在
  目前的硬體條件下，實體記憶體幾乎是無極限的（由於記憶體的廉價和伺服器可配置記憶體總量的大幅
  提升），因此我們總是可以給共享池分配足夠的空間，從而保證共享池的高效運作。在現階段來
  看，保持共享池配置有足夠的空間是共享池最佳化工作中十分重要的一點。                    
  在共享池的配置中，子池的數量也是一個十分重要的因素。在11g 版本之前，共享池子池的    
  最小值偏小，而由於目前多核CPU 的廣泛使用，使得Oracle 識別的邏輯CPU 總數很多，基於每 
  4 個CPU 分配一個子池的原則，很容易自動分配較多的子池。如果共享池偏小，而且碎片化比較
  嚴重，那麼減少子池的數量，使每個子池不小於256MB 甚至512MB 是十分必要的。            
  在遊標共享方面，儘可能使用繫結變數是非常重要的。共享遊標可以減少大量的共享池空間，  
  減少共享池中游標的總數量，從而減少共享池的爭用。透過使用繫結變數和良好的SQL 書寫風  
  格可以增加遊標的共享。如果應用程式未使用繫結變數，我們也可以透過將CURSOR_SHARING 
  引數設定為FORCE或者SIMILAR 來加強遊標的共享。很多專家都建議使用CURSOR_SHARING            
  =FORCE，而不建議使用SIMILAR。這是因為SIMILAR 可能出現另外的問題，使某個遊標出現       
  大量不能共享的子游標。實際上FORCE 也有其自身的問題，如果某條SQL 在引數不同時需要使    
  用不同的執行計劃，那麼使用了FORCE 之後，就存在問題了（在11g 版本中由於ACS 的出現，    
  這個問題已經得到了很明顯的改善），某些SQL 執行計劃的錯誤相比共享池中的遊標不能共享來  
  說，可能具有更大的危害，在這方面我們需要做好權衡。                                    
  基於上述原因，老白建議在11g 之前的版本中，還是透過適當地使用繫結變數來解決遊標的      
  共享問題。在某些需要根據柱狀圖的不同而採用不同執行計劃的情況下，儘可能不使用繫結變數。
  而對於11g 版本的系統，儘可能使用繫結變數吧（在使用時要注意，如果存在較多SQL 版本，    
  可能是碰到了ACS 的Bug）。                                                             
  遊標共享可以減少硬解析的數量，從而緩解共享池相關爭用。在有些情況下，呼叫的次數很      
  多，從而導致接卸的數量很大，達到每秒幾千甚至上萬。在這種情況下，減少軟解析也是十分關  
  鍵的，透過加大OPEN_CURSORS 和SESSION_CACHED_CURSORS 引數，儘可能保持熱點遊            
  標處於開放和快取狀態，減少軟解析的數量，可以有效地緩解共享池的效能問題，加大系統併發  
  處理能力。                                                                            
  如果共享池碎片化十分嚴重，就需要了解碎片產生的原因，從根本上解決問題。如果暫時無      
  法找到問題的根源，也可以透過定期在業務較小的時候手工重新整理共享池來保持共享池的效率，減  
  少由於共享池碎片化而導致的效能問題。為了緩解碎片化的問題，將一些重要的PL/SQL 物件和   
  SQL 保留在共享池中也是十分有效的方法。特別是一些較大的PL/SQL 物件，每次資料庫重啟後， 
  透過DBMS_SHARED_POOL.KEEP 儲存過程將其保留在共享池中，可以減少這些大型物件重新        
  載入的次數，從而緩解其載入過程對共享池的影響。                                        
  為了減少共享池產生效能問題，在業務高峰期儘可能不要修改表結構也是十分重要的，在業      
  務高峰期進行表和索引的修改、授權等操作，可能導致共享記憶體中大量的遊標失效，從而產生大  
  量的硬解析，嚴重時甚至會導致掛起。
  從 10g 版本開始，由於共享記憶體自動管理的引入，共享池的最佳化工作也簡化了許多，只要設                                                       
  置足夠大的SGA_TARGET 引數，共享記憶體就可以被Oracle 自動管理了。不過使用共享記憶體自動  
  管理（或者11g 版本的記憶體自動管理）也不能一勞永逸地解決共享池問題。在某些情況下，如果
  SGA_TARGET 不足，共享記憶體可能出現抖動，從而造成嚴重的共享池問題。因此在使用共享內   
  存自動管理時不能太過簡單， 除了設定SGA_TARGET 外， 還需要設定共享池的               
  SHARED_POOL_SIZE 引數。透過該引數，設定共享池的最小值，將這個值設定得足夠大，可以   
  確保共享池不會由於SGA 抖動而出現嚴重的效能問題。                                    
  另外很多共享池的效能問題是由於Bug 引起的，在安裝資料庫的時候，儘可能用最新的補丁    
  集，減少由於Bug導致問題的可能性。不過安裝最新的補丁包並不等於高枕無憂，定期分析ALERT
  LOG，分析AWR 報告，及時發現新的問題是十分必要的。