深入浅出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.