dba_hist_active_sess_history:这个视图是用来生成 ASH report 的, 但是 ASH report 并没有充分的利用这个视图的强
大之处,我们通过分析这个视图的详细数据,往往可以找到问题发生的原因.
可以从宏观和微观两个维度来分析这个视图(用 11gR2 的 dba_hist_active_sess_history
做例子):
比如
宏观:
a) 可以按照一段时间内(发生问题的时间段)这些 session 等待的非空闲等待事件
的类型做分类和求和,就可以知道哪种等待事件最严重
b) 可以按照一段时间内(发生问题的时间段)等待最严重事件的这些 session 所执行的 SQL_ID 来汇总求和,可以知道哪个 SQL 跟这个问题相关
微观:
a). 对于某一条 dba_hist_active_sess_history 的记录,我们可以知道这个 session 的
SESSION_STATE 是 ON CPU 还是 WAITING, 如果是 ON CPU,那么这个 session 的 event 就
无 意 义 了 ; 如果是 WAITING, 可 以 进 一 步 看 它 的 等 待 事 件 和
BLOCKING_SESSION_STATUS, 如 果 它 是 被 另 一 个 session 阻 塞 , 那 么
BLOCKING_SESSION_STATUS 这一列就会显示为 VALID 或 GLOBAL. 然后再检查
BLOCKING_INST_ID 和 BLOCKING_SESSION 找到阻塞这个 session 的是哪里实例上的哪
个 session
b). 按照 SAMPLE_TIME 排序,我们可以找到问题发生的具体的时间点 (还是比较精确
的)
c). 对某个 session, dba_hist_active_sess_history 还能揭示更多有用的信息, 比如这个
session 当前执行的 SQL 语句的类型(SQL_OPCODE, SQL_OPNAME), 这个 session 是否在
PARSE(IN_PARSE, IN_HARD_PARSE 等 ), 它是什么客户端 (PROGRAM, MODULE,
ACTION, CLIENT_ID, MACHINE), 它使用的 PGA(PGA_ALLOCATED), 它使用的 temp 空
间大小(TEMP_SPACE_ALLOCATED)等等
善于使用 dba_hist_active_sess_history 能极大地帮助我们分析问题.但是也要注意
dba_hist_active_sess_history 不是万能的: 如果最终阻塞别人的 session 当时并不是 active 的
或者它并没有被 ASH 记录到 dba_hist_active_sess_history 中, 我们还是不能知道它当时处于
一种什么状况.
结语: 总之, 分析类似的问题就是充分挖掘已有的 trace/日志的过程, 但是因为缺少足
够的诊断日志/信息,很多时候还是无法找到问题发生的原因. 如果我们确实有需要找到 root
cause, 那么在发生问题时就需要收集到足够多的信息. 比如hanganalyze, systemstate dump等

DBA_HIST_ACTIVE_SESS_HISTORY视图详细信息：