0

我需要找出会话处于活动状态时等待的总时间。

为此，我使用了如下查询...

SELECT (SUM (wait_time + time_waited) / 1000000)
  FROM v$active_session_history
 WHERE session_id = 614

但是，我觉得我没有得到我想要的使用这个查询。就像，当我第一次运行这个查询时，我得到了 145.980962，@第二次=145.953926，@第三次我得到了 127.706429。

理想情况下，时间应该相同或增加。但是，如您所见，返回的值每次都在减少。

请纠正我做错的地方。

4

2 回答 2

3

它不包含整个历史，v$active_session_history“忘记”旧行。将其视为一圈缓冲区。写入所有缓冲区后，它会从第一个缓冲区重新启动。
要获取某个会话的事件，请查看v$session_event.
要获取活动会话的当前（活动）事件：（v$session_wait在最近的 Oracle 版本中，您也可以在 中找到此信息v$session）
注意： v$session_event 视图不会显示 CPU 时间（这不是事件，但可以在 中看到v$active_session_history）。例如，v$sesstat如果需要，您可以添加它...

于 2013-01-08T11:59:35.180 回答
0

你的大器是你没有理解的性质v$active_session_history：它是一个样本而不是一个日志。也就是说，ASH 中的每条记录都是一个时间点，并不回溯到以前的记录。

别担心，这是一个常见的错误。

这是WAIT_TIME 的一个特殊问题。这是等待特定事件发生的总时间。因此，如果等待事件跨越两个样本，则第一个记录中的WAIT_TIME值为 1（一秒），下一个样本中的值为 2（两秒）。但是，aSUM(WAIT_TIME)总共会产生3，这太多了。当然，这是一个算术进程，所以如果等待事件延伸到十个样本（十秒），SUM(WAIT_TIME)那么总共会产生 55 个样本。

基本上，WAIT_TIME是一个标志 - 如果它是 0，则会话在 CPU 上，如果它大于零，它正在等待。

TIME_WAITED仅在事件停止等待时填充。所以 a SUM(TIME_WAITED) 不会给出夸大的值。事实上恰恰相反：它只会为采样时间正在进行的等待事件填充。因此，在该 SUM 中不会出现的样本间隙之间可能会有很多等待。

这就是为什么 ASH 适合突出重大性能问题而不适合识别背景问题的原因。

那么为什么每次运行查询时总时间都不会增加呢？因为 ASH 是一个循环缓冲区。较旧的记录会老化，以便为新样本让路。AWR 将一定百分比的 ASH 记录存储在磁盘上；它们可以通过DBA_HIST_ACTIVE_SESSION_HIST（默认为十分之一的记录）进行访问。因此，在您运行查询的第二次和第三次之间，ASH 可能会清除一些等待时间较长的样本。您可以通过包含MIN(SAMPLE_TIME)在选择列表中来检查。

最后，请记住 SID 会被重用。识别会话的主键是(SID, Serial#)，您的查询仅按 SID 分组，因此它可能使用来自多个不同会话的数据。

格雷厄姆·伍兹（Graham Woods）对从事 ASH 工作的 Oracle 专家进行了一个有用的演示，名为“Shifting through the ASHes”。尽管听格雷厄姆讲话会更好，但幻灯片本身仍然提供了一些有用的见解。 在这里找到它。

tl;博士

ASH 是样本而不是日志。将其用于计数而不是总和。

“查询这些表的方式有什么问题吗？”

正如我上面所说的，但可能还不够清楚，DBA_HIST_ACTIVE_SESSION_HIST只保存了 ASH 的一小部分记录。因此，SUM()在其列上运行比在实时 ASH 上运行的意义更小。

而V$SESSION_EVENT实际的事件日志。它的等待时间可靠且准确。这就是您支付启用定时统计的开销的原因。话虽如此，V$SESSION_EVENT它只给我们每个会话的聚合值，所以它在诊断中并不是特别有用。

于 2013-01-08T12:30:19.760 回答