11g中的"_memory_imm_mode_without_autosga"参数

在oracle 11g之前的版本中,当SGA_TARGET参数被设置为0时,则意味着自动内存调整特性被关闭了.但在11g数据库中,我们可能还是会看到最初设定的shared_pool_size，db_cache_size等参数的大小发生了变化，即便是oracle的自动内存特性已经被关闭了. 调查该现象的原因可发现这是由11g中新增的隐含参数”_memory_imm_mode_without_autosga”来控制的.

这实际上是11g的一个new feature,是用来规避ORA-4031错误的，当数据库系统由于shared pool(large pool..)中的内存被耗尽而将产生ORA-4031错误时,即使没有使用自动内存管理的特性, 数据库也会通过缩小buffer cache的内存,然后扩展shared pool内存的大小,从而避免发生ORA-4031错误. 当将参数”_memory_imm_mode_without_autosga”设置为FALSE时,可以关闭该特性,但数据库仍然会像以前一样受到ORA-4031错误的威胁. 注意,从实际使用中的观察结果看来,这种内存调整是不可逆的,就是说当shared pool存在大量空闲内存时并不会释放上次从buffer cache'借用'的内存.

个人经验: 这种方式虽然可以规避ora-04031错误,但这种解决方案是治标不治本的,解决ora-04031错误的根本手段还是找出引起这种内存消耗的根本原因,从而有针对性的解决. 此外，放任这种自动内存调整特性，可能会带来一些意想不到的结果，比如某些池被扩展得过大。所以个人还是比较倾向于关闭该新特性。

以下语句可用于帮助诊断是否发生了自动内存调整:

select COMPONENT,CURRENT_SIZE/1024/1024,MIN_SIZE/1024/1024,MAX_SIZE/1024/1024,LAST_OPER_TYPE from v$memory_dynamic_components where LAST_OPER_TYPE in ('GROW','SHRINK');

COMPONENT                      CURRENT_SIZE/1024/1024 MIN_SIZE/1024/1024 MAX_SIZE/1024/1024 LAST_OPER_TYP

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

shared pool                                      6528               6144               6528 GROW

DEFAULT buffer cache                            13952              13952              14336 SHRINK

而以下语句可以显示历次resize操作更详细的细节，如时间，大小等:

SELECT component,oper_type,initial_size/1024/1024 init_MB,target_size/1024/1024 target_MB,final_size/1024/1024 final_MB,status, start_time, end_time

FROM V$SGA_RESIZE_OPS

where PARAMETER in ('db_cache_size','shared_pool_size') and OPER_TYPE in ('GROW','SHRINK')

order by PARAMETER,START_TIME;

COMPONENT                      OPER_TYPE        INIT_MB  TARGET_MB   FINAL_MB STATUS    START_TIME        END_TIME

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

DEFAULT buffer cache           SHRINK             14336      14272      14272 COMPLETE  20140331 04:44:39 20140331 04:44:39

DEFAULT buffer cache           SHRINK             14272      14208      14208 COMPLETE  20140403 13:27:31 20140403 13:27:31

DEFAULT buffer cache           SHRINK             14208      14144      14144 COMPLETE  20140409 06:35:29 20140409 06:35:29

DEFAULT buffer cache           SHRINK             14144      14080      14080 COMPLETE  20140409 06:43:43 20140409 06:43:43

DEFAULT buffer cache           SHRINK             14080      14016      14016 COMPLETE  20140409 06:51:44 20140409 06:51:44

DEFAULT buffer cache           SHRINK             14016      13952      13952 COMPLETE  20140409 06:53:34 20140409 06:53:34

shared pool                    GROW                6144       6208       6208 COMPLETE  20140331 04:44:39 20140331 04:44:39

shared pool                    GROW                6208       6272       6272 COMPLETE  20140403 13:27:31 20140403 13:27:31

shared pool                    GROW                6272       6336       6336 COMPLETE  20140409 06:35:29 20140409 06:35:29

shared pool                    GROW                6336       6400       6400 COMPLETE  20140409 06:43:43 20140409 06:43:43

shared pool                    GROW                6400       6464       6464 COMPLETE  20140409 06:51:44 20140409 06:51:44

shared pool                    GROW                6464       6528       6528 COMPLETE  20140409 06:53:34 20140409 06:53:34

12 rows selected.

其实这里的时间点是重要的信息，可帮助我们找到什么时间发生了内存紧张的状况，从而找出惹祸的应用或语句。

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

转载于:http://blog.itpub.net/27243841/viewspace-1147107/