ASMM自动管理的功能[通俗易懂]

Automatic Shared Memory Management(ASMM)是ORACLE10g另外一个自动管理的功能。
只需指定SGA_TARGET参数(SAG的总大小),数据库将会根据负载和历史信息来自动分配SAG的每个组件。
启用ASSM需将STATISTICS_LEVEL参数设为TYPICAL或ALL,并且SGA_TARGET参数为非0.
ASSM自动分配以下SGA组件：
–DB_CACHE_SIZE
–SHARED_POOL_SIZE
–LARGE_POOL_SIZE
–JAVE_POOL_SIZE
以下的组件还需要手动来管理
–LOG_BUFFER
–DB_KEEP_CACHE_SIZE,DB_RECYCLE_CACHE_SIZE,DB_nK_CACHE_SIZE
–STREAMS_POOL_SIZE
–Fixed-SGA area and internal allocations
手动管理的组件也包括在SAG_TARGET中，比如SGA_TARGET是400M，LOG_BUFFER为1M，DB_KEEP_CACHE_SIZE为500M，那么可供ASSM来自动管理的大小只有349M。
SAG_TARGET参数可以通过ALTER SYSTEM来动态的改变大小，但不能超过SGA_MAX_SIZE参数大小，SGA_MAX_SIZE不是动态可以改变的。
可以通过V$SGA_DYNAMIC_COMPONENTS视图来查看当前SGA组件的大小。
如SGA_TARGET设为0来关闭ASSM，当前各组件的SIZE将会写入SPFILE用来下次的启动。

动态SGA相关的视图：
V$SGA_CURRENT_RESIZE_OPS
V$SGA_RESIZE_OPS
V$SGA_DYNAMIC_COMPONENTS
V$SGA_DYNAMIC_FREE_MEMORY

ORACLE10G用MMAN进程来管理automatic shared memory.MMAN进程观察系统的负载来决定比较理想的内存分配。
根据负载的情况，ASSM做以下工作：
–在后台周期性捕获统计信息
–用不同的内存建议
–分析内存组件的情况
–如有需要移除内存
–如SPFILE被使用，关闭数据库时记录当前各组件大小

　　当重新设置了sga_target的大小的时候,只有新值比当前组件的值大的时候才会立刻改变.如果你设置sga_target为8g,设置shared_pool_size为2g,你确信为了容纳必要的内存,共享池至少2g.当你把共享池调为1g的时候,不会立刻改变共享池的大小.它只会告诉自动内存调整算法在需要的时候,会把共享池改为1g.另外,如果一开始共享池是1g,你把它设置为2g,那么马上就生效.在重新改变操作中使用的内存是从一个或几个其它的自动调整的组件中得到了,手工的组件不受影响.
　　
　　手工改变大小的组件也可以动态的修改,但是他们的不同就是马上就是设置的值.这样,如果手工组件的值增加,额外的内存就是从一个或多个自动调整的组件中获得的.如果手工组件的值减少了,释放出来的内存就给了自动调整大小的组件.

在共享内存自动管理（ASMM）机制出现之前，共享内存的管理是一个十分复杂的工作。Oracle 9i开始支持部分SGA参数可以动态调整，这个功能大大提升了DBA进行内存管理的能力，调整部分内存参数不需要重启数据库。从9.0.1开始，共享池和default pool的大小可以动态修改，从9.2开始，又增加了LARGE POOL的动态调整。Oracle 10G则出现了一种革命性的技术-ASMM。共享内存自动管理可以把部分缓冲区的管理智能交给Oracle数据库管理器本身。RDBMS根据系统的负载情况，自动调整这些缓冲区，从而达到优化系统性能的作用。

在安装ORACLE 10G的时候，ASMM缺省是关闭的，因为SGA_TARGET参数的缺省值是0，当该参数为非0值，并且STATISTICS_LEVEL是TYPICAL 或者ALL的时候，ORACLE RDBMS启用ASMM。由于广大用户对ASMM还不了解，因此目前应用ASMM的数据库并不多，特别是大型数据库，很少使用ASMM。在最近的一些Oracle版本中，总是能够出现一些自动化管理的功能，广大用户也是在最初不理解，并不敢用的情况下，逐步消除了顾虑，并且广泛的应用了这些自动管理机制。以回滚段自动管理机制来说，该机制大大简化了DBA管理回滚段的工作，起到了十分好的效果。PGA自动管理的引入，也大大提高了PGA各种工作区的利用率，节省了大量宝贵的内存资源。因此我们有理由相信，ORACLE ASMM技术也将会大大减轻DBA管理共享内存的工作量。和其他自动管理机制一样，对于内存资源竞争不是很激烈的系统或者是系统压力不是很大的系统，使用ASMM可以减轻DBA的工作量。

ASMM的另外一个优势是能够把有限的内存资源合理分配，不会因为DBA设置错误而导致部分缓冲区性能下降。一个新的后台进程mman会对系统的缓冲区状态进行分析，根据目前系统的负载情况，根据一定的策略对缓冲区进行调整。其处理过程如下：
? 首先，周期性采集系统的状态
? 生成或分析建议直方图
? 根据直方图找到合理的缓冲区调整方案
? 根据调整方案自动调整各个缓冲区的大小
使用ASMM也解决了一个以前一直困扰DBA的问题，那就是我们的系统往往是白天在做OLTP操作，夜晚有很多统计分析工作。白天和夜晚需要的内存分配策略是不同的。在ASMM技术出现之前，DBA没有很好的方法来解决这个矛盾，除非DBA能够每天进行参数调整。如果使用ASMM技术，可以通过ASMM技术自身的自动调节功能来动态分配各种内存缓冲区，从而起到DBA很难做到的作用。
ASMM有很多优点，但是ASMM也不是万能的，使用ASMM不当也会带来严重的系统性能问题，如果系统中的内存资源不足，或者系统的负载十分大，那么就需要DBA通过自己的工作手工调整来进行优化。如果内存已经不足，或者出现了明显的由于缓冲区引起的性能问题，那么就尽量不要使用ASMM。

目前ASMM并不能管理所有的SGA对象，随着ASMM技术的进一步发展，ASMM能够管理的SGA对象会越来越多，ASMM的人工智能也会越来越强大。以下缓冲区是可通过ASMM来管理的：
? SHARED POOL
? LARGE POOL
? JAVA POOL
? DB CACHE
要注意的是，10G ASMM只能管理DB CACHE中的DEFAULT池，而不能管理所有的DB CACHE。KEEP池、RECYCLE池和NK缓冲池都需要手工管理。另外LOG BUFFER和STREAM POOL等也需要手工管理。
和ASMM相关的ORACLE参数包括SGA_MAX_SIZE和SGA_TARGET。前者定义了SGA能使用的最大内存大小，SGA_TARGET设置了动态调整内存的各种缓冲池的总的大小。要注意的是SGA_TARGET是一个可以动态调整的参数，它限定了在进行ASMM处理的时候，所有内存缓冲区的总的大小，包含ASMM可以动态自动调整的缓冲池和需要手工配置的缓冲池的总的大小。如果SGA_TARGET设置为3G，DB_KEEP_CACHE_SIZE是1G，那么ASSM管理的缓冲池总的大小不能超过2G。
如果使用ASMM，调整SGA_TARGET是DBA的主要工作。SGA_TARGET可以动态调整。SGA_TARGET的最大值不能超过SGA_MAX_SIZE规定的大小。如果DBA调整SGA_TARGET的值，那么会引起被ASMM管理的缓冲区的变化，而不会引起手工管理的缓冲区的变化。
在使用ASMM的情况下，ASMM自动管理的缓冲池可以设置为0，也就是说不设置任何限制，由ASSM完全管理。如果某个ASMM自动管理的缓冲池设置了非零的值，那么ASMM会保证在任何情况下，这个缓冲池的大小不会小于这个参数设置值。在数据库运行的过程中，DBA可以动态调整ASMM管理的缓冲池的大小，如果设置的新值大于目前缓冲池的大小，并且是合理的，那么该设置会立即生效。如果设置的新值小于目前缓冲池的大小，ASMM会记录下这个设置建议，但是不会立即缩小缓冲池，而是会等待今后别的缓冲池需要扩展的时候才会释放。
对于一个使用ASMM的系统，可以随时改变为关闭ASMM，只要将SGA_TARGET设置为0。如果这个操作发生了，那么所有的ASMM管理的参数都会保留为当前的设置。

ASMM是ORACLE 10g的一项革命性的技术，其意义并不仅仅是简化DBA的管理难度。随着ASMM技术的日渐成熟，ASMM使ORACLE提供了一种对OLTP/OLAP应用自适应的能力，从而解决一直困扰DBA的混合型应用的问题。对于既有OLTP应用，又在部分时间（比如晚上或者月底）带有大量OLAP分析的系统来说，如果能够根据应用的特点，动态自动调整相关缓冲池，那么意义是十分巨大的。此类应用目前十分广泛，在电信、制造业、政府等行业应用里，都或多或少存在类似的问题。
在使用ASMM的情况下，通过SGA_TARGET可以设定SGA缓冲池的最大大小，另外可以通过设定ASMM管理缓冲池的参数来限制某个缓冲池的最小限制，以防止ASMM出现错误的设置，导致缓冲池抖动。在这些机制的保证下，只要DBA能够设置合理的配置，能够保证ASMM提供最佳的管理性能。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/271283/viewspace-998398/，如需转载，请注明出处，否则将追究法律责任。