PGA

SGA系统全局区内存结构了解

[日期：2008-10-18]   来源：互联网整理  作者：佚名   [字体：大 中 小]

    新闻简介：    System global area(SGA) 是一组共享的内存结构，它里面存储了oracle数据库实例（instance）的数据和控制文件信息。如果有多个用户同时连接到数据库，他们会共享这一区域，因此SGA也称之为shared global area。

         关 键 词:  

    System global area(SGA) 是一组共享的内存结构，它里面存储了oracle数据库实例（instance）的数据和控制文件信息。如果有多个用户同时连接到数据库，他们会共享这一区域，因此SGA也称之为shared global area。

    SGA和oracle的进程组成了oracle的实例（instance）。在实例启动的时候内存会自动分配，当实例shutdown的时候操作系统会将内存回收的。没一个实例（instance）拥有自己的SGA。

    SGA是可以读写的，每一个用户连到数据库实例时都是可以读实例的SGA的内容，oracle通过服务器进程执行一个命令去写SGA的数据。

SGA包含以下的数据结构：

l Database buffer cache 

l Redo log buffer 

l Shared pool 

l Java pool 

l Large pool (optional) 

l Data dictionary cache 

l Other miscellaneous information 


SGA中还包含了后台进程访问的一些关于数据库和实例状态的信息，称之为fixed SGA，用户的信息是不会存储在这块区域中的。进程之间的一些交流的信息也会存储在SGA中。如果使用共享server模式，有些PGA的内容也会存储在SGA中。

SGA是可以动态调整大小的，也就是说调整其大小是不用shutdown数据库的。在初始化参数中设置可以设置sga_max_size这个参数，当SGA的各部分的和要大于设置的sga_max_size的参数的时候，设置的sga_max_size将会被忽略掉，而是将各部分的大小相加。当sga_max_size的大小大于各部分的大小相加时，会使用sga_max_size的参数。

对于性能的考虑，SGA区域的内存应该是真正的内存，如果使用需拟内存，会大大降低性能。下面这几个参数最严重的影响到了SGA的大小：

DB_CACHE_SIZE
 The size of the cache of standard blocks.
 
LOG_BUFFER
 The number of bytes allocated for the redo log buffer.
 
SHARED_POOL_SIZE
 The size in bytes of the area devoted to shared SQL and PL/SQL statements.
 
LARGE_POOL_SIZE
 The size of the large pool; the default is 0.
 


SGA分配的最小单元

SGA在分配和回收的时候是采用一个叫做granule的单元进行分配的，granule的大小是由SGA的大小决定的，如果SGA小于128mb，则granule就是4mb，大于128mb，则为8mb或者16mb，当分配内存的时候，将会以granule的整数倍去分配，比如设置DB_CACHE_SIZE=131mb，grance为4mb时，系统会将DB_CACHE_SIZE=132mb。所有关于granule的信息都会存储在granule entry，在granule entry中管理每个granule的状态等信息。

Database buffer cache

Database buffer cache 是SGA中的一部分，它存储的是从数据文件中读取的数据块的拷贝，所有的数据库连接都会共享访问这个区域。Database buffer cache 和sql的共享区分在不同的逻辑segment集中（database buffer cache 和 shared pool 是不同的两个内存区域），这样可以降低他们之间的争用情况。

Database buffer cache的组织方式

这块内存区域中被组织成两个链表：一个是写的链表，一个是最近最少使用（LRU）的链表。写的链表里面是写脏数据的，LRU链表是控制不包含任何数据的空闲空间（free buffers）、正在使用的空间（pinned buffers）和还没有写到写链表的脏数据块。

当一个进程访问一个buffer的时候，进程将会将该buffer移到LRU的末尾，称之为MRU，当越来越多的buffer被移到MRU后，脏数据块就会接近LRU的LRU端。

开始的时候，用户进程需要一些数据，它就会到database buffer cache中去搜索，如果有（cache hit），该进程就可以直接从内存中读数据；如果没有找到（cache miss），那么必须先要从数据文件将数据拷到database buffer cache，然后再去从内存中去访问。Cache hit 要比cache miss 快很多由此可以看出。 [Page]

在读一个数据块到内存中去的时候，进程必须先要找到一个空闲的buffer，这时候进程会从LRU的末尾开始访问LRU链表，直到找到一个空闲的buffer 或者搜索完可以搜索的所有buffer。

当进程在搜索LRU的时候找到一个脏数据buffer，它就会将该buffer移到write list，然后继续查找，直到找到一个空闲buffer，然后候就从硬盘将数据块读到这个buffer并且将这个buffer移到LRU的末尾MRU端。如果这个用户进程找遍了所有的buffer也没有找到一个空闲的buffer，这时候就停止查找LRU，告诉DBW0去写一些脏数据块到硬盘。

LRU算法和全表扫描

当用户进程执行一个全表扫描的时候，它就会读表的所有块到buffer并且将他们放在LRU的LRU端的链表上，因为全表扫描的数据基本上就是比较简短的使用就不再使用了，所以他应该放在LRU的LRU端的链表上的，用完了就需要赶紧交换出去了。

也可以采用一些方法改变这样的一个全表扫描的buffer处理行为，cache可以将表等cache到MRU的末尾，这样可以避免一些io的消耗，当然这样的表应该是比较小的。

根据上面，我对database buffer cache的理解LRU是一个什么样的链表：

LRU

----------------------------------------------------

| buffer| buffer| ..... |buffer|buffer|

-MRU端-----------------------------------LRU端------

因为SGA中只有两个链表：一个是WRITE链表，一个是LRU链表。所以MRU和LRU应该是一个LRU链表中的，而LRU的MRU端是最近最多访问的，LRU的LRU端是最近最少访问的。个人认为write链表在一开始没有脏数据需要写的时候是一个空链表，当有脏数据buffer从LRU链表移过来时，这个链表开始有buffer链在上面，其实此时是不会再另外为写链表分配空间的，直接将LRU中的buffer的指针指向写链表就可以了。