总的来说，减少parsing 是调优library_cache的主要方针
1.确保用户能使用共享SQL语句。
2.防止已经PARSING过的语句被淘汰掉，使用方法就是分配足够的内存。结合free_memory来看
3.避免表被改造
4.把一些SQL语句PINNING，避免它走LRU算法。

通过以下方法可以降低应用系统中因为PARSE过于频繁而导致的系统问题：
1.使用绑定变量
2.尽量不要使用动态SQL语句
3.连上来的用户尽量不要更改他们优化器的相关设置
4.对于开发程序员来说，对于动态变量，要有一套命名规范，对于空格也要有一个标准
4.尽可能的使用存储过程。
5.有些SQL语句是一样的，但他们不能共享，通过v$SQL_SHARED_CURSOR
6.尽量要用同一个用户连接
7.尽量使用pl/sql，调用PL/SQL包的时候，用不通用户连上来。
8.在OLTP系统业务高峰中避免DDL的操作。
对于OLAP系统来说，以上的优化方法均不适用，建议不适用绑定变量

下面介绍一个重要的性能视图：v$librarycache，他 描述了library_cache的各项指标
gets 找的次数
gethits 在内存里找到了的次数
gethitratio:找到的百分比
PINS：找到了执行的次数
PINhit:执行之后成功的次数
pinhitration：运行的命中率
reload: 已经解析过了，但是某种原因，可能因为LRU算法，时间一长就被淘汰了，就需要重解析
invalidation: 如果一个对象改变了，那已经编译好的执行计划也无效了，需要重新解析

如何查看LIBRARY_CACHE的命中率？
SQL>select namespace,gethitratio,pinhitratio,reload,invalidation from v$library_cache;
注意：reload和invalidation接近0比较好

reload的百分比尽量要小于1%.
SQL>select sum(pins) "executions",sum(reload) "cache misses",sum(reload)/sum(pins)
from v$library_cache；这个语句就是查询reload的百分比

这里我们也要注意v$library_cache也是一个累计值，可能不准确，我们可以像statspack那种方法一样，取
两次值，我们进行相减，然后再计算。如果reload的值大于1%, 说明library_cache有点小了，但我们也要看看v$sgastat中的free_memory的大小，在业务的高峰期执行ddl，也会导致invalidation的增大。

下面在介绍几个关于SQL的性能视图：v$SQL,v$SQLAREA,V$SQLTEXT

SQL>select sql_text from v$sqlarea where execution < 5 order by upper(sql_text);
这就是查看在LIBRARY里查看次数小于5的语句。

如何查看现在正在执行哪些SQL语句？
SQL>select sql_text,users_executing,executing,loads from v$sqlarea;
然后我们可以查询这条语句的完整信息？
SQL>select * from v$sqltext where sql_text like 'select * from emp where ......'