ITPub博客

首页 > 数据库 > Oracle > ASH内存强制Flush日志解决一例

ASH内存强制Flush日志解决一例

Oracle 作者:听海★蓝心梦 时间:2014-11-06 04:57:26 0 删除 编辑

Oracle ASHActive Session History)是作为细粒度的AWR报告,经常在我们进行性能调优过程中被应用到。和所有的监控手段一样,ASH是建立在定时性能数据采样收集,最后集中汇总分析的基础上。ASHAWR相比,采样频率更加密集,数据以活跃会话active session为中心。

在实际中,我们也可能会遇到与ASH有关的问题故障,本文简单介绍一个案例,供将来有需要的朋友待查。

 

1、问题阐述

 

在巡检过程中,发现一个11gR2库夜间运行告警日志异常。

 

SQL> select * from v$version;

 

BANNER

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

Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production

PL/SQL Release 11.2.0.3.0 - Production

CORE 11.2.0.3.0 Production

 

告警日志信息:

 

Wed Apr 16 02:54:04 2014

Archived Log entry 42964 added for thread 1 sequence 26964 ID 0x408fa96f dest 1:

Archived Log entry 42965 added for thread 1 sequence 26964 ID 0x408fa96f dest 5:

Wed Apr 16 02:54:28 2014

Active Session History (ASH) performed an emergency flush. This may mean that ASH is undersized. If emergency flushes are a recurring issue, you may consider increasing ASH size by setting the value of _ASH_SIZE to a sufficiently large value. Currently, ASH size is 67108864 bytes. Both ASH size and the total number of emergency flushes since instance startup can be monitored by running the following query:

 select total_size,awr_flush_emergency_count from v$ash_info;

 

根据提示信息,SQL检查结果如下:

 

 

SQL> select total_size/1024/1024,awr_flush_emergency_count from v$ash_info;

 

TOTAL_SIZE/1024/1024 AWR_FLUSH_EMERGENCY_COUNT

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

                  64                         1

 

2、问题分析

 

从告警日志情况看,应该是Oracle内部自动调节机制的作用。进入11g之后,Oracle alert log的告警提示作用愈加明显。对于一些自动诊断过程中出现的问题,都会作为提醒出现在日志中。比如swap转换,ash变化等。今天的ash emergency flush就是比较常见的一个。

 

笔者管理系统是一个典型的OLAP系统,白天DML操作不多,大都是查询检索和报表类操作。夜间通过一系列作业SQL来进行数据ETL过程。

上面日志片段正是在夜间作业过程中生成,作业过程每两分钟生成日志量约为1G

从分析角度,Oracle在收集ASH过程中,频度是很高的,通常为分钟级别。如果收集之后就立即存储入数据库文件,在性能上损耗是不容易被接受的。一种方法是构建在内存共享存储中的专门buffer。定期或者确定激发条件将数据从内存中写回到数据库中。

从提示信息中看,Oracle在负载比较大的情况下,会出现ASH信息超过系统限制,进行了一次强制的紧急清空动作。Oracle建议,如果反复出现这样的情况,就建议调整_ash_size参数大小。

Oracle内部的确是存在参数_ash_size,作为隐含参数可以使用SQL进行查看。

 

SQL> select

  2    x.ksppinm name,

  3    y.ksppstvl value,

  4    y.ksppstdf isdefault,

  5    decode(bitand(y.ksppstvf,7),1,'MODIFIED',4,'SYSTEM_MOD','FALSE') ismod,

  6    decode(bitand(y.ksppstvf,2),2,'TRUE','FALSE') isadj

  7    from

  8    sys.x$ksppi x,

  9    sys.x$ksppcv y

 10    where

 11    x.inst_id = userenv('Instance') and

 12    y.inst_id = userenv('Instance') and

 13    x.indx = y.indx and

 14      x.ksppinm ='_ash_size'

 15    order by

 16    translate(x.ksppinm, ' _', ' ');

 

NAME       VALUE      ISDEFAULT ISMOD      ISADJ

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

_ash_size  1048618    TRUE      FALSE      FALSE

 

Ash size大小用于指定ash buffershared pool)。默认给定的是1048618 bytes,也就是1MASH工作采样是以Active Session为中心的。如果系统处理操作过于频繁,活跃用户会话数量很多,这样每次采样的数据量就会超过系统空闲状态。

随之而来的就是内存中ash buffer的填满,进而引发数据库强制回写数据,启动DBWR进程读写动作。DBWR在写入的时候,会占用一部分系统资源,从整体看是性能瓶颈点。

 

4、解决问题

 

根据Oracle官方推荐的经验做法,我们要调整ash size参数到一个适合大小范围。当前ASH total size64MB,按照适度宽松的原则,另外加入一半的冗余量,也就是设置96M大小。

 

SQL> alter system set "_ash_size"=100663296;

System altered

 

判断调整情况:

 

SQL> select

  2    x.ksppinm name,

  3    y.ksppstvl value,

  4    y.ksppstdf isdefault,

  5    decode(bitand(y.ksppstvf,7),1,'MODIFIED',4,'SYSTEM_MOD','FALSE') ismod,

  6    decode(bitand(y.ksppstvf,2),2,'TRUE','FALSE') isadj

  7    from

  8    sys.x$ksppi x,

  9    sys.x$ksppcv y

 10    where

 11    x.inst_id = userenv('Instance') and

 12    y.inst_id = userenv('Instance') and

 13    x.indx = y.indx and

 14      x.ksppinm ='_ash_size'

 15    order by

 16    translate(x.ksppinm, ' _', ' ');

 

NAME       VALUE      ISDEFAULT ISMOD      ISADJ

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

_ash_size  100663296  TRUE      SYSTEM_MOD FALSE

 

在第二天夜间作业执行过程中,报警信息没有再出现,故障解决。

 

5、结论

 

这个问题本身不大,而且根据Oracle的提示也比较容易解决问题。应该说,这种提示信息不一定一出现就进行调整,Oracle一般建议ash强制刷新在多次出现的时候才尝试解决。但是,这个错误出现前,笔者曾经进行过SGAPGA大小调整,应对不足情况。而且每天系统作业负载情况相同。所以,如果调整之后出现报错,就会一直存在。这也就是为什么笔者急于开始处理的原因。

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

下一篇: 没有了~
请登录后发表评论 登录
全部评论

注册时间:2009-02-18

  • 博文量
    256
  • 访问量
    1199953