Buffer cache 和 share pool 是sga中最重要最复杂的部分。
一.Buffer Cache
通常数据的读取、修改都是通过buffer cache 来完成的。buffer cache 中的数据 ，oracle是通过LRU 和dirty list 这样的链表来管理的。
除了这2个，还有 hash bucket 和 cache buffer chain
hash bucket：查找方法类似老式图书馆查书
二.Shared Pool
1.shared pool 是oracle sga中重要的一部分，它主要作用是 sql共享、减少代码硬解析等
shared_pool_size设置：oracle9以后，设置成200-300M是比较合适的
2.ora-04031问题
当尝试在共享内存分配大的连续内存失败后，oracle会清空没用的对象，尝试合并内存；如果仍然没有足够大的内存空间，就提供ora-04031.
如果shared_pool_size 设置的够大，也不存在系统bug；那么大部分引起该问题的原因：共享池中大量的sql引起过多的内存碎片导致
1）sql没有足够的共享空间
2）大量不必要的解析
3）sql没有使用绑定变量
另外，虽然可以通过强制刷新系统共享内存以达到共享内存碎片合并目的，但该操作是不推荐的。
alter system flush shared_pool。
实际上，share pool的调整根本是从应用入手，应用代码的编写、调整才是根本。
3.Version_count 过高的现象：
应用系统一段时间运行缓慢，一时正常。查看了$session_wait 发现 latch free 比较多。
通过 v$latch 表查看到 shared pool 和 liberary cache 比较大。
通过v$sqlarea 查看到 version_count>1000 的有几个。
问题解决：1）调整timed_statistics=true 为false
-----该参数是系统对 比如sql解析、执行、等待等等分别消耗了多少时间进行统计
2）调整cursor_sharing=similar 为 force--强制匹配 或者 exact--精确匹配（缺省值）
-----该参数是sql强制变量绑定
另外：说明一下cursor_sharing
根据oracle官方建议在11g中不推荐使用cursor_sharing=SIMILAR,其实在所有版本中都不推荐,设置为该值很容易导致高版本问题.
而且该值会出现莫名其妙的,无法解释的高版本问题.而且根据oracle相关文档,在即将发布的12c版本中,将除掉SIMILAR值.
对于客户库的该问题,因为很多sql未绑定参数,为了减少硬解析, 建议在业务低谷时设置cursor_sharing=FORCE,并刷新shared pool.
