【每日一摩斯】-Shared Pool优化和Library Cache Latch冲突优化 (1523934.1)-系列4(二)
得shared pool latch被持有的时间变长，进而导致性能问题。在这种情况下，较小的shared pool也许比较大的shared pool好。因为 Bug:986149的改进，这个问题在8.0.6和8.1.6以上版本被大大减少了。
注意: 一定要避免由于shared pool设置过大进而导致的swap的发生的情况，因为当swap发生的时候性能会急剧下降。
参考 Note:1012046.6 来根据工作量计算SHARED_POOL_SIZE 需要的大小。
预编译器的HOLD_CURSOR和RELEASE_CURSOR选项
当使用Oracle 预编译器预编译程序的时候，shared pool的行为可以通过参数RELEASE_CURSOR和HOLD_CURSOR来控制。这些参数可以决定当cursor执行完毕之后library cache和session cache中cursor的状态。
关于这个参数的更多信息，请参考 Note:73922.1
将cursor固定(pinning)在shared pool中
另外一种减少library cache latch使用的方法是将cursor固定在shared pool中，详见以下文档：
Note:130699.1 How to Reduce 'LIBRARY CACHE LATCH' Contention Using a Procedure to KEEP Cursors Executed> 10 times
这个存储过程 (RDBMS/ADMIN 目录下的DBMSPOOL.SQL脚本中有定义) 可以用来将对象KEEP到shared pool中， DBMS_SHARED_POOL.KEEP可以 'KEEP' packages, procedures, functions, triggers (7.3+) 和 sequences (7.3.3.1+) ，在 Note:61760.1中有完整的描述。
通常情况下，建议将那些需要经常使用的package一直keep在shared pool中。KEEP操作在
数据库启动后需要尽快实施，因为在shutdown之后
Oracle不会自动重新keep这些对象。
注意:在Oracle 7.2之前DBMS_SHARED_POOL.KEEP实际上不会把需要KEEP的对象完整的放到shared pool中。所以建议在每一个要被KEEP的package中放一个空的存储过程，在执行完DBMS_SHARED_POOL.KEEP之后再调用一下这个空存储过程来保证对象被完全装载。这在7.2之后已经修复了。