ITPub博客

首页 > 数据库 > Oracle > 11g中的"_memory_imm_mode_without_autosga"参数

11g中的"_memory_imm_mode_without_autosga"参数

原创 Oracle 作者:talio 时间:2014-04-22 17:05:45 0 删除 编辑

在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/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2013-05-14

  • 博文量
    17
  • 访问量
    273229