深入浅出Oracle学习笔记：Buffer Cache 和Shared pool

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.