oracle10g 内存结构

1.SGA

1.1 从查询sga相关视图开始

1.1.1 gv$sga_dynamic_components

SQL> select * from gv$sga_dynamic_components;

PS:

1)SGA的分配单元为granule,sga中的components都是由granule组成的，granule的信息由granule entry来管理，每个entry维护了granule的类型和状态，当sga<=128M时granule为4M，当sga>128M时 granule为16M,特殊情况是32BIT的windows NT则为8M,从视图查询的结果可以看出当前的granule为16M

2)sga的主要成分为：buffer cache,shared pool,java pool,large pool

 

1.1.2 v$sga_current_resize_ops

SQL> desc v$sga_current_resize_ops;
Name             Type         Nullable
—————- ———— ——–
COMPONENT        VARCHAR2(64) Y
OPER_TYPE        VARCHAR2(13) Y
OPER_MODE        VARCHAR2(9)  Y
PARAMETER        VARCHAR2(80) Y
INITIAL_SIZE     NUMBER       Y
TARGET_SIZE      NUMBER       Y
CURRENT_SIZE     NUMBER       Y
START_TIME       DATE         Y
LAST_UPDATE_TIME DATE         Y

PS:

1)oracle利用一个scoreboard来管理sga中每个component及其granules的信息，scoreboard记录了 component包含多少granule,正在对component执行的修改操作，修改的目标大小，修改的过程，操作的开始时间

2) 当修改1个component的granule数目时，oracle立刻在scoreboard中记录此操作，target size，操作开始时间，修改完成后，oracle用target size 代替current size，并且清空target size。

3)oracle记录了最近100个修改操作，即scoreboard是循环使用的一种buffer。

1.1.3 v$sgainfo

SQL> select * from v$sgainfo;

NAME                                  BYTES RESIZEABLE
——————————– ———- ———-
Fixed SGA Size                      2086592 No
Redo Buffers                       14688256 No
Buffer Cache Size                3103784960 Yes
Shared Pool Size                 5335154688 Yes
Large Pool Size                    67108864 Yes
Java Pool Size                     33554432 Yes
Streams Pool Size                  33554432 Yes
Granule Size                       16777216 No
Maximum SGA Size                 8589934592 No
Startup overhead in Shared Pool   301989888 No
Free SGA Memory Available                 0

PS:

1)sga中不是所有component都可以动态修改的，如上查询结果所示。

1.1.4 v$sgastat

SQL> select * from v$sgastat;
POOL         NAME                            BYTES
———— ————————– ———-
fixed_sga                     2086592
buffer_cache               3103784960
log_buffer                   14688256
shared pool  VIRTUAL CIRCUITS              3867480
shared pool  transaction                   4026704
shared pool  table definiti                   5896
shared pool  kgl lock hash table state      203280
shared pool  kwqmncal: allocate buffer        4048
shared pool  qmn tasks                        4128
shared pool  Cursor Stats                 40715832
shared pool  enqueue                       3096464
shared pool  X$SKGXPIA                        2680
shared pool  sessions                      8778128
shared pool  row cache                     7506880
shared pool  enqueue_hash                   160560
shared pool  processes                       12000
shared pool  db_block_hash_buckets        23592960
shared pool  X$KSFQP ANCHOR                     80
shared pool  ASM rollback operations          2592
shared pool  X$KSVIT table                     512
……..
shared pool  kso req alloc                    4136
shared pool  kwqmncini-slv                     240
shared pool  Temporary Tables State Ob      389736
shared pool  enqueue_hash_chain_latche        1280
shared pool  KTPR HIST TB                     2808
large pool   free memory                  66032864
large pool   PX msg pool                   1076000
java pool    free memory                  33554432
streams pool free memory                  33554432

690 rows selected

可以利用thomas kyte的方法：

SQL> compute sum of bytes on pool
SQL> break on pool skip 1
SQL> select pool,name,bytes from v$sgastat order by pool,name;

POOL         NAME                            BYTES
———— ————————– ———-
java pool    free memory                   4194304
************                            ———-
sum                                        4194304

large pool   PX msg pool                    206208
free memory                   3988096
************                            ———-
sum                                        4194304

shared pool  1:kngisga                       16044
x$ksmfs table                      12
x$rule_set                      16804

……
xscalc                           3528
xslongops                        4040
xsoqmehift                       4168
xsoqojhift                       3272
xsoqophift                       4168
xsoqsehift                       2376
xssinfo                          5532
************                            ———-
sum                                      113250900

buffer_cache                 46137344
fixed_sga                     1260696
log_buffer                    2932736
************                            ———-
sum                                       50330776

1.2 sga 特性

1)在unix系统中，sga在操作系统中表现为一个独立的物理实体，即一段独立的shared memory segment，你可以通过ipcs -m|grep ora来查到该共享内存段。

[root@seagull ~]# ipcs -m |grep ora
0×5c7384ec 14516224   oracle10  640        169869312  22
0×7256e224 22544385   oracle9   640        117440512  35

有可能会出现没有对应后台进程的sga，此时表明oracle不正常crash，但共享内存段没有释放，这时要用ipcrm命令来清除共享内存，或者重启机器。

2)在windows系统中，只有1个oracle.exe进程，以及系统分配给oracle.exe的私有内存，包括了sga和其它所有oracle内存(pga,uga)，因此无法看到单独的sga。

1.3 sga的构成

sga_max_size, sga_target

1)java pool:为了在数据库中运行的JVM而分配的内存，在10g中可以动态调整

java_pool_size

2)large pool:用于在sharedserver模式下作为session memory,在并行执行情况下作为消息缓冲，在RMAN中作为disk I/O buffer，该部分在10g和9iR2中可以动态调整

large_pool_size

3)shared pool:存储共享cursors,存储过程，字典等,在10g和9i中可以动态调整

shared_pool_size

4)streams pool:专门用户oracle stream功能的，如果使用了该功能但没有配置streams pool,oracle将会用10%的shared pool作为streams memory

streams_pool_size

5)”Null” memory：block buffers + fixed sga + redo buffer

db_*_cache_size

log_buffer

1.4 10g中的ASSM

在10g中，sga某些component可以自动被oracle调整，具体参见我之前写的帖子：http://blog.chinaunix.net/u1/50863/showart_414883.html

1.5 fixed_sga

1)fixed sga的官方解释1：The fixed SGA is a component of the SGA that varies in size from platform. to platform. and from release to release. It is “compiled” into the Oracle binary itself at installation time (hence the name “fixed”). The fixed SGA contains a set of variables that point to the other components of the SGA, and variables that contain the values of various parameters. The size of the fixed SGA is something with which we have no control over, and it is generally very small.
Think of this area as a “bootstrap” section of the SGA—something Oracle uses internally to find the other bits and pieces of the SGA.

2)fixed sga的官方解释2：Part of the SGA contains general information about the state of the database and the instance, which the background processes need to access; this is called the fixed SGA.

1.6 redo buffer

1)存放redo entries，lgwr负责写redo entries 到online redo log file,写的时机有以下：

a.每3s

b.commit

c.log switch

d.1m or 1/3 full

2)redo entries包含了insert,update,delete,create,alter,drop等操作的信息，可以在必要的时候用以数据库恢复，它们在buffer中是连续的、序列化的。

3)大部分情况下，log_buffer不需要很大，2M以内就可以了，以下情况可能需要大一点：

a.并发事务很多，大的log_buffer可以保证lgwr在写出的同时，其它session可以写入log buffer

b.有很多long-running session

3)redo buffer 由log_buffer参数指定，一般要大于512k和128K*CPUs ,不过最小值与操作系统相关，要想知道最小值是多少，可以做如下操作：

SQL> alter system set log_buffer=1 scope =spfile;

System altered.

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.

Total System Global Area  171966464 bytes
Fixed Size                  1260720 bytes
Variable Size              62915408 bytes
Database Buffers          104857600 bytes
Redo Buffers                2932736 bytes
Database mounted.
Database opened.
SQL> show parameter log_buffer

NAME                                 TYPE        VALUE

———-                           ——-     ——-

log_buffer                           integer     2887168

1.7 block buffer cache

1.7.1 组成

1) default pool：默认池

2) keep pool:就是那些使用率非常高的块，可以缓存到这里，以提高性能

3) recycle pool：使用率非常低的块，可以缓存到这里

4) 从9i开始，增加了db_nk_cache_size，以支持非默认的block size的表的缓存。

所有的这些buffer cache的内部管理方式都是一样的

1.7.2 Managing blocks in the buffer cache

1) dirty lists  ：needed to be written by the dbwr to the disk

2) nodirty lists:该list采用touch count机制计算buffer访问频率(热点块问题的理论基础，x$bh视图的tch字段)，采用LRU算法来控制buffer的使用:

2.1)这个list包括了free buffers(还未使用的),pinned buffers(正在被访问的),dirty buffers(还未move到dirty list的脏块)

2.2)oracle进程访问一个buffer时，会将该buffer move到LIST的MRU(most recently used)端，随着更多的buffers move到MRU端，那些dirty buffers就会age toward到LRU端。

2.3)当进程访问一个数据时，首先会在database buffer cache(用hash算法)查找，如果找到，称为cache hit，如果没有找到，称为cache miss，此时oracle进程从datafile 里copy该block到buffer中。

2.4)当需要copy block到buffer时，进程必须先要找到1个free buffer，找的方法如下：

a.从nondirty list的LRU端如果找到dirty buffer，则将其move到dirty list，然后继续找free buffer

b.如果找到free buffer,则copy block到该buffer，并将其move到MRU端

c.如果一直到threshold(就是一个上限，找多少个找不到后就不找了)还没有找到，则停止寻找，并通知DBWR进程写一些dirty buffers到disk中.

2.5)如果是full table scan,那么buffer不会move 到LRU端，而是MRU端，除非该表在创建时指定了cache语句。

1.7.3 multiple blocksize

略

1.8 shared pool

1.8.1 概述

1)包括library cache,dictionary cache,buffers for parallel execution messages,control structures

2)由shared_pool_size参数指定shared pool的大小

1.8.2 library cache

1)包括sharedsqlareas,private sql areas(共享服务器模式下),pl/sql,package,control structure(比如locks,library cache handles)

2)一个sql语句的执行涉及到两个area,其中shared sql area是多个session可以共享的，private sql area是每个sql会话独占的。

3)shared sql area:

3.1)包括了sql的parse tree,execution plan等

3.2)当1个新的sql被parsed时，就被存放到shared sql area,需要的memory size取决于sql复杂度，如果没有剩余的memory可用，oracle会用LRU算法腾出剩余空间

4)private sql area:

4.1)当共享服务器模式时，private sql area处于sga的libary cache中，当专有服务器模式时，private sql area处于pga中

4.2)private sql area主要包括了bind information和runtime memory structure ，每个发出sql的session都有自己的一个private sql area,但发出同样sql的众多session共用1个shared sql area

4.3)private sql area又可分成两部分，且lifetime是不同的

a.persistent area：包含bind information，当cursor close时被释放

b.runtime area   :当execution is terminated时被释放，在执行请求时的第一步创建。对于INSERT、UPDATE 和DELETE命令，该区在执行语句后释放，对于查询操作，该区只在提取所有行或取消查询后释放。

4.4)cursor和sql area的关系：

a.cursor 就是指向private sql area的句柄，应用程序可以显示的打开cursor，此时cursor是作为一种具有名字的资源(比如我们在编写pl/sql中定义的cursor name), ORACLE也会隐式的打开一些cursor，比如recursive cursor

b.user process负责private sql area的management,而且private sql area的allocation和deallocation很大程度上与使用的application tool有关，一个user process能够打开的最大cursors由open_cursors参数指定

c.直到cursor被关闭，private sql area才被完全释放，如果statment执行完毕，但没有close cursor,此时只有run time area被释放，persistent area仍然处于waiting状态，所以开发人员应该及时close cursor。

1.8.3 dictionary cache
1)dictionary是关于oracle结构、用户的所有定义信息，sql执行时需要查询这些信息，dictionary对数据库至关重要

2)oracle有两部分区域用于存放dictionary data
a.一个叫data dictionary cache(也叫row cache)，这里解释一下为什么可以叫row cache，因为 row cache以row的方式存放数据，而不是以  buffer(block)的方式
b.另外一个地方在library cache中。

1.8.4 shared pool 中内存的分配和释放
shared pool中的内存空间计算方法采用LRU算法，当某个会话执行1个sql执行时，oracle执行以下步骤来shared poll中的内存分配：

1)首先查找是否有1个shared sql area中有相同sql存在，如果存在，则使用该shared sql area，否则，oracle分配一个新的shared sql area(采用LRU算法寻找free空间)给该会话。
2)接着oracle再分配一个private sql area给该会话，private sql area的位置取决于是否采用了shared server模式，采用了则在shared pool中，否则在pga中。

另外，在以下情况下，oracle会释放shared pool中的shared sql areas :
1)修改对象的statistics的analyze语句将会导致相关对象所涉及的sql语句所在的shared sql areas被flused from the shared pool
2)对象被改变，比如加了字段，相关shared sql area也会被flused 3)如果改变了database name，全部shared pool信息都会被flused 4)alter system flush shared_pool

1.8.5 Thomos Kyte对shared pool的理解

1)shared pool大小非常关键，shared pool使用的不好，对性能有极大影响

2)shared pool由lots of small chunks(<=4K,但不是hard limit) of memory组成， 使用小的chunks目的是为了减少碎片，及时是比较大的package，由于采用paging mechanism，因此只有被执行的相关code才会被装入一些small chunks中

3)shared pool的分配算法采用LRU，但可以利用DBMS_SHARED_POOL来改变其分配的算法，以使得某些Objects被pin在shared pool中，比如，你可以用该包来使得某些经常使用的package或procedure在数据库启动时便装入了shared_pool

4)不使用bind variables，将会导致shared pool的性能大大下降，甚至down掉数据库，因为： a.重复的parse会消耗cpu b.使用大量的资源来管理shared pool中那些无法重用但又占用了空间的sql 因此，我们应该尽量使用bind，以重用sql，在大部分系统中，也应该只有几百个unique queries而已，即使是超大型的系统，我发现的unique quries只在10000－20000个。

5)v$sgastat与shared_pool_size
a.通过select sum(bytes) from v$sgastat where pool=’shared_pool’可以查询当前shared pool的实际大小
b.在10g以前，用这种方法查出的大小要比shared_pool_size参数大一点，这是因为shared pool中除了存放shared_pool_size参数指定的share pool内存外，像control_files参数也会消耗264字节在shared pool中。
c.在10g，两者是对应的，即用v$sgastat查处的跟shared_pool_size参数应该是对应的(当然，如果采用了ASMM，则shared_pool_size不起作用了)

1.9 large pool

1.9.1 large pool 的主要作用

1)shared server模式下作为session memory

2)parallel execution of statements ,to allow for the allocation of interprocesses message buffers ,which are used to coordinate the parallel query servers

3)backup for rman disk i/o buffers in some cases

1.9.2 large pool 的特点

1)”large”，指的是其分配单元相对于shared pool，要大很多，主要是为了特定的任务

2)分配算法采用heap管理方式，和LRU不同，用完即释放，他的目的是为了完成特定任务时有内存，而不是像shared pool是为了cache和reuse

3)large pool往往和dbwr_io_slaves,parallel_max_servers参数成正比

1.10 java pool

1.10.1 java pool的主要作用

1)用于缓存在数据库中执行的java code代码和相关数据

1.10.2 java pool的特点

1)在dedicated server模式下,java pool里包括:

a.只包括java class的缓存，大概每个class有4k或8k的的空间

2)在shared server模式下,java pool里包括:    a.The shared part of each Java class

b.每个session的uga中的一部分状态信息

1.11 streams pool

1.11.1 streams pool的主要作用

1)支持数据库的streams功能，streams是10g的新功能

2)The Streams pool (or up to 10 percent of the Shared pool if no Streams pool is configured) is used to buffer queue messages used by the Streams process as it is moving/copying data from one database to another.

2.pga

2.1 pga的特点

  1)进程全局区(PGA)即可以理解为Process Global Area,也可以理解为Program Global Area.它的内存段是在进程私有区(Process Private Memory)而不是在共享区(Shared Memory).它是个全局区意味着它包含了所有代码有可能进入的全局变量和数据结构,但是它是不被所有进程共享的.每个Oracle的服务器进程都包含有属于自己的PGA,它只包含了本进程的相关特定信息.PGA中的结构不需要由latches来保护,因为其它的进程是不能进入到这里面来访问的.
2)很多人都搞不清楚PGA和UGA两者之间的区别,实际上两者之间的区别跟一个进程和一个会话之间的区别是类似的.尽管说进程和会话之间一般都是一对一的关系,但实际上比这个更复杂.一个很明显的情况是MTS配置,会话往往会比进程多得多.在这种配置下,每一个进程会有一个PGA,每一个会话会有一个 UGA.PGA所包含的信息跟会话是无任何关联的,而UGA包含的信息是以特定的会话为基础的.
另外,而UGA所处的位置完全由session连接的方式决定：
a.如果session是通过共享服务器（shared server）方式连到数据库的，则毫无疑问，UGA必须能够被所有进程访问，所以这个时候UGA是从SGA中进行分配的。进一步说，如果SGA中设置了 large pool，则UGA从large pool里进行分配；否则，如果没有设置large pool，则UGA只能从shared pool里进行分配了。
b.如果session是通过专用服务器（dedicated server）方式连到数据库的，则UGA是从进程的PGA中进行分配的。

3)PGA包含两个主要区域:Fixed PGA和Variable PGA或称为PGA Heap. Fixed PGA的作用跟Fixed SGA是类似的,都包含原子变量(不可分的),小的数据结构和指向Variable PGA的指针.  Variable PGA是一个堆(heap).它的Chunks可以从Fixed Table X$KSMPP查看得到,PGA HEAP包含了一些有关Fixed Table的永久性内存,如果session使用的是专用连接方式,则还含有uga子堆.
2.2 content of pga
  2.1.1 private sql area
1)persistent area:这里存放了相同SQL语句多次执行时都需要的一些游标信息，比如绑定变量信息、数据类型转换信息等。这部分内存只有在游标被关闭时才会被释放.
2)run time area (其实就是uga中的sql work area):这里存放了当SQL语句运行时所使用的一些信息。在处理SQL语句时的第一步就是要创建运行时区域，对于DML（INSERT、 UPDATE、DELETE）语句来说，SQL语句执行完毕就释放该区域；而对于查询语句（SELECT）来说，则是在所有数据行都被获取并传递给用户以后被释放，或者该查询被取消以后也会被释放。
2.1.2 session memory
1)session memory包含了一个sessoin的variable信息(logon information)和其它会话相关信息，对于shared server模式，该结构是共享的.

2.3 sql work area（run time area）
1)对于sort,hash-join,bitmap-merge,create-bitmap操作使用

2.4 相关视图
1)v$sysstat,v$sesstat,v$pgastat,v$sql_workarea,v$sql_workarea_active
2)v$process的pga_used_mem,pga_allcated_mem,pga_max_mem字段

2.5 相关文章

关于pga,网上有一些很精辟的分析文章，附件如下：

3.SoftWare Code Areas

1)用于存放oracle代码的区域，大小通常是固定的，只有当oracle updated或reinstall时才会变化
2)该区域和用户程序的内存区域格开，且严格被保护
3)该区域可以装成共享或者不共享的，有些平台不能装成共享的，比如windows
4)oracle尽量会使得代码共享，这样多个用户进程可以共享代码以节约内存。