说到优化，咱们先从shared_pool开始说起，shared_pool(共享池),里面包括了library_cache,dictionary_cache，library_cache存的是编译好的SQL语句和PL/SQL.里面遵循的是lru算法，而dictionary_cache里面存的是使用过的数据字典的信息，是比较静态的信息,我们要优化共享池，主要优化的就是library_cache，我们首先对shared_pool有个简单的了解，首先，我们不能单独调整library_cache和library_cache的大小，我们只能调整全局的shared_pool_size,但现在oracle推出了一个自动内存管理，在内存管理模式下，我们只需要调整sga_target这个参数，系统会根据情况自动调整其他参数，比如：db_cache_size,shared_pool_size,large_pool_size,java_pool_size.如果我们想手工管理内存，只需要直接修改shared_pool_size就可以了。
在这里，我们先说一说当我们执行一条SQL语句之后，oracle内部都做了什么？
当我们执行一个SQL语句的时候，oracle会对它进行编译(parse),但在编译之前，会先查找，如果发现已经编译好了，就直接共享了，这种编译叫做软编译，如果没有查到，就会把文本编译成一个可以执行的代码，保存在library_cache中。如果两个语句想共享一个执行代码的时候，会有条件，oracle自动决定一个语句和共享池里的一个语句是否一样。具体
过程如下：
1.发出的sql语句会和shared_pool已经存在的进行对比，如果一样，就利用已经编译好的代码。
2.比较的过程是先hash，产生hash值，对比hash值，如果hash值不同，说明根本就不一样。这时就硬解析了。
3.如果发现hash值是一样的，oracle 会把这个字符串进行逐个比较，看看是否完全相同，必须是完全一样的，空格，大小写和注释，一个不同都不好使：
select * from scott.emp;
select * From scott.emp;
select * from scott.emp 这三个就不一样，不能共享。
所以，shared_pool对性能影响的主要问题就是：在library_cache里最大化的共享已经编译好的SQL代码。
在生产中有两种数据库：OLTP和OLAP
OLTP:用的人多，每次执行的时间非常短
OLAP:用的人少，但每次执行的时间却非常长。
所以，如果要提高OLTP系统的性能，就需要提高软解析的数量，减少硬解析，因为对于OLAP系统来说，不需要操心reparing(重解析),因为重解析的时间相对于查询的时间来说实在是微不足道啊。
--TO BE CONTINUED[@more@]