1.1.1.1 使用活动会话历史
活动会话历史基于采样。因此要执行明智的分析，需要大量的采样。考虑到测试案例1只执行了十几秒，使用活动会话历史并不能分析出准确的信息。本节的目的是向你展示查询的类型，你或许想要识别哪个SQL语句被解析以及它花费的时间。
在活动会话历史中，in_parse和in_hard_parse标志告诉你取样时会话是否在解析SQL语句。基于这些标志，可以针对某一会话写出类似下面的查询，来评估DB
time和解析SQL语句花费的时间(请注意，这两个数字的单位都是秒):
select count(*) AS db_time,
count(nullif(in_parse, 'N')) AS parse_time,
count(nullif(in_hard_parse, 'N')) AS hard_parse_time
FROM v$active_session_history
WHERE session_id = 68
AND session_aserial# = 23;
如果发现解析有问题(比如，根据上一个数据，80%的时间用于解析),你不仅需要知道具体解析的SQL语句，还要知道每条语句花费的时间。不幸的是，活动会话历史其中一个局限性就是并不能直接看到SQL文本。要获取语句文本，需要基于SQLID来去查询另一个视图。例如，可以将v$active_session_history联接到v$sqlarea。
不幸的是，游标保存在库缓存中的时间很短，尤其是因为快速解析而导致繁忙的数据库实例经历性能问题时。结果，你或许无法获取足够的信息。要想略微提高获取更多信息的可能性，可以使用v$sqlstats来代替v$qlarea。实际上，前者有更大的保留期。例如，下面的查询能够取回与解析相关的四个采样中仅有的两条SQL语句(请记住，测试案例1执行了10000条SQL语句):
select a.sql_id, s.sql_text, count(*) AS
parse_time
FROM v$active_session_history a, v$sqlstats s
WHERE a.sql_id = s.sql_id(+)
AND a.session_id = 68
AND a.session_serial# = 23
AND a.in_parse = 'Y'
GROUP BY a.sql_id, s.sql_text
ORDER BY count(*) DESC;
1.1.1.1 总结问题
通过活动会话历史执行的分析对本例来说并不是特别有帮助。这是因为对单个会话在十几秒内进行采样只能得到几个样本。然而，TKPROF和TVD$XTAT执行的分析，清晰地展示了数据库引擎单独解析的处理信息。但是，在数据库端，解析只占了全部响应时间的39%(5.705/14.494)。
这代表排除它大于一半响应时间的可能。分析也 显示了如下的10000条SQL语句只解析并执行一次：
select pad FROM t WHERE val=0;
由于使用的文字不断变化，在库缓存中的共享游标无法重用。换句话说，每个解析都是硬解析。图12-1 图示了这个处理。
注意 图12-1显示的处理稍后会被当作测试案例1。
毫无疑问，这样的处理是低效的。请参考12.2节，找寻对应的解决方案。
