Oracle Memory Management and HugePage （连载二）

作者：沃趣科技高级数据库工程师  魏兴华 

---

MSMM

10G前SGA的管理是通过手工设置一系列的参数来实现的，例如重要的参数有以下几个：

●             buffer_cache_size

●             shared_pool_size

●             large_pool_size

●             stream_pool_size

●             log_buffer

SGA是一大块内存的统称，由上面列出的组件组成，10G之前的版本,DBA需要对SGA的各个内存区域进行手工设置，这可能对一个DBA无形中要求变得非常的高，需要了解业务，了解热点数据量，了解SQL的使用方式，是否存在大量不同文本的SQL等等来决策来给每个区域分配多少内存。使用过这个版本的DBA基本都遭遇过一个经典的报错：ORA-04031，一般是由于shared pool内存不够导致，这个不够的原因可能有很多，共享池内存的严重碎片化，大量的硬解析，巨大的PL/SQL文本等等都可能会导致这个问题。下面我们来看下，手工管理SGA情况下，如何考虑为buffer cache和shared pool这两个最重要的内存组件分配内存。

Buffer Cache

Buffer Cache俗称数据块高速缓存，是用来缓存数据块的拷贝的，Oracle通过改进后的LRU算法以期待这些数据块后续被高效的重用。服务器进程从磁盘读入的数据就放在这块内存中，修改数据时，也是在这个区域对数据进行修改。并没有一个给buffer cache分配内存的黄金法则，还是要根据操作系统的内存大小，业务的热点数据量、业务的类型等因素来决定给buffer cache分配多大的内存大小。我们先看下如何决定整个SGA的大小，对于SGA的分配原则，官方建议如下：

上面的公式格式跟PGA的公式大同小异，刨去20%内存给操作系统之后，分为了不同的系统类型，基本上是OLTP系统，大部分的内存给buffer cache，DSS类的系统，buffer cache没那么重要，可以给到50%甚至更低。 至于SGA中多少可以分配给buffer_cache，要看实际情况。DBA可以通过查看buffer cache的命中率来粗略了解是否给buffer cache分配了足够的内存。但是熟悉我的朋友都知道，我是OWI方法论的践行者，对于命中率的崇拜在Oracle里已然不应该再存在，但是命中率作为一种性能诊断的辅助手段依然具有它的价值。如果系统的SQL都足够优化后，命中率不高，一定程度上意味着可能buffer cache给小了或者你的业务访问的数据非常的离散，热点数量太少。这里肉丝给出的优化思路是自顶向下，命中率低是一个表象，最上层的应用是不是调用了大量不需要调用的SQL，这些SQL是不是缺少索引，SQL都足够优化后，DBA是不是考虑加大buffer cache来提升性能，加大之后还是不行，是不是要考虑增加系统内存来进一步提高buffer cache的大小，最后是不是需要为数据库多加几个盘或者使用SSD来提高性能。采用自顶向下的分析方法有利于真正发现问题所在而且以最低的代价解决问题，如果仅仅是一个SQL由于缺少索引而导致整个数据库系统缓慢，DBA直接就去加盘扩容IO，那么最终会发现花费了这么大的代价，治标不治本，问题依然没有解决。上面给出的公式并不适用于所有情况，特别是OLTP系统，如果进程数非常的多，那么需要进一步降低SGA占用内存的比例，以预留出更多内存给PGA使用。

Shared Pool

Oracle占用量最大的两块内存除了buffer cache区就是Shared Pool的内存了，它的结构非常的复杂，而且由于要缓存SQL代码这种非标准大小的文本，经常会产生大量的碎片化内存，shared pool总体上包含了两大部分，一块是library cache区，用来缓存SQL、PL/SQL代码，保存它们的执行计划，提高SQL的解析效率，如果你的应用代码从来不使用绑定变量，那么这一块的内存对你来说是一个很大的负担，但是Oracle里是无法关闭library cache区的，因此对于OLTP系统，请确保SQL都使用了绑定变量。第二大块区域是row cache区，用来缓存数据库的数据字典，由于保存在里面的信息是以行的形式存在，因此叫row cache。对于这一块的内存，依据数据库中元信息（metadata）的多少而决定，如果数据库中有几十万的对象，那么这一块的内存就会占用比较大，同时表上的很多列都有直方图信息，也会导致这一区的内存占用比较大。在一个稳定的系统中，这一区域的内存基本上是静态的，Oracle中几乎没有操作会频繁修改row cache区。有个例外情况是没有cache属性的sequence，如果这种sequence调用频繁，就会触发频繁的修改sequence的属性值，进而可能会产生row cache lock的一些等待，优化的办法是为每一个sequence设置足够的cache值。 >如果应用程序没有使用绑定变量，而且难以修改，可以通过设置cursor_sharing为force来尝试解决问题。

这里肉丝再讲一个亲身经历的案例，老DBA嘛，可能技能已经不多，但故事还是有的????，曾经帮一位客户解决了一个free buffer waits的案例，这个等待事件的出现一般说明buffer cache过小，或者全表扫描、写入操作比较多、写脏数据比较慢，从AWR报告看，free buffer waits排在TOP EVENT的第一名,占用的DB TIME已达到了百分之七八十，而且从awr报告中发现客户的shared pool内存占用已经达到了接近50G，而分析数据库一个月之前的AWR报告，shared pool的内存只有3个G左右的大小，基本上可以认定为shared pool内存占用过大，而导致buffer cache不够用，进而出现了free buffer waits等待事件，经过跟客户沟通后知道，以前一直比较稳定，最近做过的大的变更是给数据库使用了oracle 的flahcache，通过MOS上搜索flashcache关键字最终发现，在11.2.0.4，Oracle RAC如果使用了flash cache，那么会在shared pool 中分配额外的内存存放GCS资源。多出的内存为：208 bytes * the total number of (flash) buffer blocks。因为这里提醒广大DBA朋友，如果你打算使