改进共享池的性能
改进共享池的性能就是提高库缓存和数据字典缓存的命中率，有以下一些方法：
增大共享池
• 增大共享池能减慢库缓存和数据字典缓存被LRU算法移出的速度，从而提高命中率；
• 库缓存命中率和数据字典缓存命中率通常都趋向于一致，极少出现一高一低的情形；
• 共享池的大小由初始化参数SHARED_POOL_SIZE来确定；
• 已使用库缓存的大小可以通过sum(V$DB_OBJECT_CACHE.SHARABLE_MEM)（非SQL对象）和 sum(V$SQLAREA.SHARABLE_MEM)（SQL语句） 来查询；
• 可以用ALTER SYSTEM SET SHARED_POOL_SIZE = XX; 来动态更改共享池的大小，但需保证更改后SGA的大小不大于SGA_MAX_SIZE，否则会现ORA-04033的错误；
• 也可以通过关机更改初始参数SHARED_POOL_SIZE再重启来手工更改共享池的大小，这种方法适于同时改大SGA_MAX_SIZE这个参数；
• 无统计数据时，可以按照下面的策略来为ORACLE服务器分配内存：
Ø 操作系统（NT需要的较UNIX多），ORACLE后台进程，服务器进程，其它非ORACLE进程共需内存= 服务器总内存 * 45%（1G以下时） or 25~40%（1G以上时）；
Ø TSGA（SGA总内存） = 服务器总内存 * 55%（1G以下时） or 60~75%（1G以上时）；
Ø TSGAI（单个实例的SGA内存） = TSGA / 服务器上的实例数；
Ø 共享池 = TSGAI * 45%；
Ø 数据缓存 = TSGAI * 45%；
Ø 日志缓存 = TSGAI * 10% （10%的日志缓存通常都偏大，可待有统计数据后视情形将多出的部分分给共享池，数据缓存或者大池）；
Ø 若需配置大池和JAVA池时，从本实例SGA总内存中分配。
为大的PL/SQL语句留空间；
• 执行大的PL/SQL程序时，为了获得足够的缓存空间，LRU算法会移出许多已解析的语句，尔后这些刚被移出的语句可能又要重新装入，这样就降低的库缓存的命中率，为了避免这样的情形，可以设置共享池保留区给大的PL/SQL对象使用；
• 参数SHARED_POOL_RESERVED_SIZE用来指定共享池保留区的大小，最大可指定到共享池的一半，默认值是共享池的5%，ORACLE建议从共享池的10%开始调整；
• 可以从V$DB_OBJECT_CACHE查到目前缓存对象及其使用空间（OWNER, NAME, SHARABLE_MEM）；
• 可以用V$SHARED_POOL_RESERVED视图来监控保留区的使用情况以决定正确的保留区大小：
Ø REQUESTS 从保留区中请求空间的次数；
Ø REQUEST_MISSES 保留区无空间可用而需要从非保留区清洗对象的请求次数；这个值为零或者一直很稳定表示保留区空间设置偏大；
Ø FREE_SPACE 保留区未用的空间；这个空间大于保留区的一半时表示保留区空间设置偏大；
Ø REQUEST_FAILURES 请求无法满足，出现ORA-04031错误的次数； 这个值非零或者稳定增加时表示保留区太小；
Ø 隐含参数_shared_pool_reserve_min_alloc（4400）确定请求保留区的起始大小；
Ø 调整保留区的目标是使REQUEST_MISSES, REQUEST_FAILURES接近零。
• 可以用DBMS_SHARED_POOL.ABORT_REQUEST_THRESHOLD这个包过程设置一个阀值，大于这个值的库缓存请求将会失败。
Keep PL/SQL
• 将重用率高的PL/SQL代码KEEP在库缓存中可以提高命中率，这个过程又称Pinning，由DBMS_SHARED_POOL.KEEP过程来完成，这些对象存放在共享池保留区中；
• 清洗共享池语句（ALTER SYSTEM FLUSH SHARED_POOL;）并不会清洗Pinned对象，但是系统重启后，这些对象将不再是Pinned。
• Keep相关：
Ø DBMS_SHARED_POOL这个包并没有在运行catproc.sql时安装，需运行一次dbmspool.sql这个脚本；
Ø 可以用这个包中的KEEP, UNKEEP来pin 和unpin存储对象；
Ø 可从V$DB_OBJECT_CACHE.KEEP这个栏位得知哪些对象已被Pinned。
• 要确定哪些对象适于KEEP，可以激活审计功能来查看是哪些对象被频繁地调用，要KEEP匿名的PL/SQL程序比较麻烦，建议将经常使用且长度超过500个字符的匿名块写成过程和包再进行KEEP；
• 因为重启后所有的KEEP都将失效，所以将KEEP的动作放在系统触发器中（AFTER STARTUP ON DATABASE）是较合适的。
代码重用；
• 确定是否需要对语句进行（硬）解析时，是先比较语句的哈希值，下面的两种方法有助于获得相同的哈希值，从而可以实现重用代码，提高命中率：
Ø 开发组的所有成员都使用相同的编码规范（包括大小写，空格，换行等）；
IXDBA.NET社区论坛
Ø 使用绑定变量（提高命中率的同时可能会产生不够好的执行计划，因为优化器不知道变量的确定值，在有栏位的柱状图统计数据时也不能够利用）。
调整相关初始化参数。
OPEN_CURSORS
• 这个参数指定每个用户会话能打开的游标个数；
• 增大这个值可以减少重新解析会话曾打开的语句的机会，提高命中率，但需要更大的共享池空间。
CURSOR_SPACE_FOR_TIME
• 这个参数设为真时，只有当所有引用共享SQL的游标都关闭后，LRU才有可能移出这个SQL所占的缓存空间来重用，默认值是FALSE；
• 只有在共享池足够大的情况下才能考虑设为真，设为真时可以减少重解析，提高命中率，加快游标的执行（空间换时间）。
SESSION_CACHED_CURSORS
• 这个参数指定会话能够缓存游标的个数，默认值是零；
• 如果会话反复执行某些语句，设置该值大于零能提高游标的执行速度，这些缓存也是用LRU算法来管理的。
CURSOR_SHARING
• 这个参数决定什么样的SQL语句能够共享游标，有三个取值：FORCE, SIMILAR, EXACT；
Ø FORCE 两个语句的差异只在字面值，这些差异不会改变语句的含义时可共享游标；
Ø SIMILAR两个语句的差异只在字面值，这些差异不会改变语句的含义和执行计划时可共享游标（这个值是在9i 中引入，如果有差异的栏位上有柱状图统计，这时执行计划会改变，不能共享游标，行为同于EXACT，如果差异栏位上没有柱状图统计，执行计划相同，这时的行为同于FORCE）；
Ø EXACT 两个语句必须精确匹配才能共享游标，这是默认值。
