[size=large]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里。这样，下次启动实例时，就可以直接把顾问得出的建议值拿来作为启动内存池的依据了。
如果我们启用了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所覆盖。[/size]
从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里。这样，下次启动实例时，就可以直接把顾问得出的建议值拿来作为启动内存池的依据了。
如果我们启用了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所覆盖。[/size]
扫一扫
894
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
