共享池的优化要从几个方面去考虑：首先是共享池本身的配置，其次是游标的共享，然后是缓解共享池的碎片，最后是分析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 报告，及时发现新的问题是十分必要的。