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

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

在实际中，我们也可能会遇到与ASH有关的问题故障，本文简单介绍一个案例，供将来有需要的朋友待查。 1、问题阐述在巡检过程中，发现一个11gR2库夜间运行告警日志异常。 SQL> select * from v$version; BANNER-----------------------------------------------------Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit ProductionPL/SQL Release 11.2.0.3.0 - ProductionCORE 11.2.0.3.0 Production 告警日志信息： Wed Apr 16 02:54:04 2014Archived 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 2014Active 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 buffer（shared pool）。默认给定的是1048618 bytes，也就是1M。ASH工作采样是以Active Session为中心的。如果系统处理操作过于频繁，活跃用户会话数量很多，这样每次采样的数据量就会超过系统空闲状态。

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

4、解决问题根据Oracle官方推荐的经验做法，我们要调整ash size参数到一个适合大小范围。当前ASH total size是64MB，按照适度宽松的原则，另外加入一半的冗余量，也就是设置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强制刷新在多次出现的时候才尝试解决。但是，这个错误出现前，笔者曾经进行过SGA和PGA大小调整，应对不足情况。而且每天系统作业负载情况相同。所以，如果调整之后出现报错，就会一直存在。这也就是为什么笔者急于开始处理的原因。更多Oracle相关信息见Oracle 专题页面 http://www.linuxidc.com/topicnews.aspx？tid=12本文永久更新链接地址