oracle自动共享内存管理(ASMM) .

一篇关于ASSM的好文章：http://blog.csdn.net/liyongjie/article/details/7443825

oracle自动共享内存管理(ASMM)

从Oracle 10g开始，Oracle提供了自动SGA的管理（简称ASMM，即Automatic Shared Memory Management）新特性。所谓ASMM，就是指我们不再需要手工设置shared pool、buffer pool等若干内存池的大小，而是为SGA设置一个总的大小尺寸即可。Oracle 10g数据库会根据系统负载的变化，自动调整各个组件的大小，从而使得内存始终能够流向最需要它的地方。

比如，假设某个系统，白天属于OLTP应用，因此会需要较多的buffer cache。而该系统在晚上属于DSS应用。对于DSS应用，很多的SQL语句由于都是进行全表扫描，因此都会采取并行方式完成。我们知道，并行时需要靠若干的从属进程完成工作，而从属进程会从large pool中进行分配。于是，晚上会需要较多的large pool。如果我们启用了ASMM，则数据库会根据负载的变化而自动的对内存大小进行调整，就不需要DBA进行手工调整了。

Oracle 10g提供了一个新的初始化参数：sga_target来启动ASMM，该参数定义了整个SGA的总容量。同时，初始化参数statistics_level必须设置为typical或all才能启动ASMM，否则如果设置为basic，则关闭ASMM。

ASMM只能自动调整5个内存池的大小，它们是：shared pool、buffer cache、large pool、java pool和stream pool。我们不再需要设置shared_pool_size、db_cache_size、large_pool_size、 java_pool_size、streams_pool_size这五个初始化参数。而其他的内存池，比如log buffer、keep buffer cache等仍然需要DBA手工进行调整。

举例来说，假设我们将sga_target设置为500MB，表示SGA总容量为500MB。但是如果我们需要配置100MB的keep buffer cache，则必须手工设置参数db_keep_cache_size为100MB。同时如果设置参数log_buffer为3MB，那么shared pool、buffer cache等可以调整的5个部分的总容量就是397MB（500-100-3=397）。

Oracle 10g还提供了另一个初始化参数sga_max_size。sga_target的值不能超过sga_max_size的值，修改sga_max_size时，必须重启实例才能生效，而sga_target则可以在线修改，立即生效，无须重启实例。

为了实现ASMM，Oracle新引入了一个名为MMAN（Memory Manager）的后台进程。每隔很短的一段时间，MMAN进程就会启动，然后去询问一下Oracle提供的各个内存组件顾问，比如有buffer cache顾问，也有shared pool顾问，由这些顾问根据当前的负载情况，将这5个可以自动调整的内存池的、建议的大小尺寸，返回给MMAN。于是，MMAN进程就会根据该返回的值，来设置各个内存池。同时，如果我们使用了spfile，还会将这些顾问得出的建议值写入spfile里。这样，下次启动实例时，就可以直接把顾问得出的建议值拿来作为启动内存池的依据了。

{

MMAN (Memory Manager) is a background process that manages the dynamic resizing of SGA memory areas as the workload increases or decreases.

This process was introduced in Oracle 10g.

MMON (Memory Monitor) is a background process that gathers memory statistics (snapshots) stores this information in the AWR (automatic workload repository). MMON is also responsible for issuing alerts for metrics that exceed their thresholds.

This process was introduced in Oracle 10g.

}

如果我们启用了ASMM，同时又手工设置了可以自动调整大小的内存池的尺寸，比如设置了参数shared_pool_size为一个非0值的时候，会怎么样？对于Oracle 10g来说，我们为自动调整大小的内存组件设置了值，则会以我们设置的值作为自动调整的最小值。也就是说，假设sga_target为4GB，而我们将 shared_pool_size设置为600MB，则MMAN在进行自动调整时，永远不会将shared pool设置为600MB以下。

实际上，为了使用ASMM，Oracle为这5个可自动调整的组件又提供了5个控制它们大小尺寸的参数，以“__”（两个下画线开头）。我们把当前的spfile导出到pfile里。

SQL> create pfile='/u01/init.ora' from spfile;

SQL> !vi /u01/init.ora

打开该pfile以后，我们会发现文件的前5行，会显示如下的内容（具体值可能不一样）：

ora10g.__db_cache_size=134217728

ora10g.__java_pool_size=4194304

ora10g.__large_pool_size=4194304

ora10g.__shared_pool_size=62914560

ora10g.__streams_pool_size=0

可以看到，这5个初始化参数都以“__”开头，后面的部分与我们手工设置内存池大小的参数相同。比如__db_cache_size与 db_cache_size对应等。这种以“_”开头的参数我们叫做隐藏参数。所谓隐藏参数，就是没有官方文档对其含义进行说明的参数。这种参数会根据版本的不同而发生改变。这5个隐藏参数（比如__shared_pool_size）由MMAN进程负责修改，而与之相对应的其他参数（比如 shared_pool_size）则由DBA进行设定。因此，当我们启动数据库时，数据库内核会在初始化参数__shared_pool_size与 shared_pool_size之间进行比较。如果shared_pool_size没有设定，或设定为0，或设定的值比 __shared_pool_size小，则以MMAN自动调整的值来设置内存池的尺寸。否则，以DBA设定的值来设置内存池的尺寸 如果我们在数据库运行过程中，修改了某个可自动调整的内存池的大小，这时会怎么样？如果我们设置的值比MMAN自动调整出来的值要大，则该内存池立即调整为设定的值的大小，同时我们所设定的值作为MMAN新的、自动调整的最小值；反之，如果设置的值比MMAN自动调整出来的值要小，则该内存池的大小不会变化，而我们所设置的值则只作为自动调整的最小值存在。比如，当前MMAN自动调整出来的shared pool大小为150MB，也就是__shared_pool_size为150MB，同时shared_pool_size为60MB。这时，如果我们将参数shared_pool_size从60MB设置为100MB的话，则shared pool的大小仍然为150MB，但是新设置的100MB将作为自动调整时的下限；如果我们将参数shared_pool_size从60MB设置为 200MB，则shared pool立即扩张，从150MB扩张到200MB，同时200MB也将作为自动调整的新的下限。

我们来验证一下。视图v$sga_dynamic_components里记录了能够动态调整的各个内存池的大小。

SQL> SELECT component, current_size/1024/1024 size_mb
2 FROM v$sga_dynamic_components where comp;

COMPONENT SIZE_MB
------------------------------------ ------------
shared pool 80

当前MMAN自动调整出来的shared pool大小为80MB。

SQL> alter system set shared_pool_size=70M;
SQL> SELECT component, current_size/1024/1024 size_mb
2 FROM v$sga_dynamic_components where comp;

COMPONENT SIZE_MB
------------------------------------ ------------
shared pool 80

我们将shared_pool_size设定为70MB，小于自动调整出来的值。可以看到，shared pool没有缩小，仍然是80MB。我们再将其从80MB扩大到100MB。

SQL> alter system set shared_pool_size=100M;
SQL> SELECT component, current_size/1024/1024 size_mb
2 FROM v$sga_dynamic_components where comp;

COMPONENT SIZE_MB
------------------------------------ ------------
shared pool 100

显然，只要我们设定的值比自动调整出来的值大，就会立即生效。
同时，如果当前我们启用了ASMM，同时并没有为这5个可以自动调整的内存池参数指定具体的值。当数据库在ASMM状态下运行一段时间以后，我们再禁用ASMM，会发生什么？我们来看下面的试验。

SQL> select name,value from v$parameter
2 where name in('shared_pool_size','db_cache_size','
java_pool_size','large_pool_size',' streams_pool_size');

NAME VALUE
-------------------- --------------
shared_pool_size 96468992
large_pool_size 0
java_pool_size 0
streams_pool_size 0
db_cache_size 0

可以看到，除了shared pool为DBA指定以外（因为shared_pool_size大于0），其他的内存池都由ASMM指定。

SQL> select component, current_size FROM v$sga_dynamic_
components 2 where component like '%pool' or comp;

COMPONENT SIZE_MB
---------------------------------- -----------
shared pool 138412032
large pool 4194304
java pool 4194304
streams pool 0
DEF***T buffer cache 373293056
我们看到，ASMM根据当前的负载情况，为这5个内存池指定了大小。

SQL> alter system set sga_target=0;
SQL> select name,value from v$parameter
2 where name in('shared_pool_size','db_cache_size','
java_pool_size','large_pool_size',' streams_pool_size');

NAME VALUE
-------------------- --------------
shared_pool_size 138412032
large_pool_size 4194304
java_pool_size 4194304
streams_pool_size 0
db_cache_size 373293056

当我们将sga_target设置为0，从而禁用ASMM时，会发现，Oracle会自动将当前内存池的大小赋给对应的初始化参数（shared_pool_size、db_cache_size等）。同时我们也可以注意到，shared_pool_size的值也不再是DBA当时指定的96468992，而是被ASMM自动调整出来的138412032所覆盖。