oracle ash（active session history）是作为细粒度的awr报告，经常在我们进行性能调优过程中被应用到。和所有的监控手段一样，a
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 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 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、结论