0

セッションがアクティブなときにセッションが待機している合計時間を調べる必要があります。

このために、以下のようなクエリを使用しました...

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

しかし、このクエリを使用して望んでいたものが得られていないと感じています。同様に、このクエリを初めて実行したときは 145.980962、2 回目は 145.953926、3 回目は 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 特有の問題です。これは、そのイベントの特定の発生を待機した合計時間です。そのため、待機イベントが 2 つのサンプルにまたがる場合、最初のレコードでWAIT_TIMEは 1 (1 秒) になり、次のサンプルでは 2 (2 秒) になります。ただし、aSUM(WAIT_TIME)は合計3を生成しますが、これは多すぎます。もちろん、これは算術的な進歩であるため、待機イベントが 10 サンプル (10 秒) に及ぶ場合、SUM(WAIT_TIME)合計は 55 になります。

基本的にWAIT_TIMEはフラグです。0 の場合はセッションがオン CPU であり、0 より大きい場合は待機中です。

TIME_WAITEDイベントが待機を停止した場合にのみ設定されます。したがって、SUM(TIME_WAITED) は膨張した値を与えません。実際にはその逆です。サンプル時間に進行中の待機イベントに対してのみ入力されます。そのため、その SUM には表示されないサンプルの隙間に入る待機が多数存在する可能性があります。

これが、ASH が大きなパフォーマンスの問題を強調するのに適していて、バックグラウンドの問題を特定するのに適していない理由です。

では、クエリを実行するたびに合計時間が増加しないのはなぜでしょうか? ASH は循環バッファであるためです。古いレコードは、新しいサンプルに道を譲るために古くなっています。AWR は、ASH レコードの一部をディスクに保存します。からアクセスできますDBA_HIST_ACTIVE_SESSION_HIST(デフォルトは 10 分の 1 レコードです)。したがって、クエリを実行した 2 回目と 3 回目の間に、待ち時間の長いサンプルが ASH によって削除された可能性があります。MIN(SAMPLE_TIME)選択リストに含めることで確認できます。

最後に、SID は再利用されることに注意してください。セッションを識別するための主キーは です(SID, Serial#)。クエリは SID によってのみグループ化されるため、複数の異なるセッションからのデータを使用する場合があります。

「Shifting through the ASHes」と呼ばれる ASH に取り組んだオラクルの達人である Graham Woods による有益なプレゼンテーションがあります。Graham の講演を聞くほうがよいかもしれませんが、スライドだけでもいくつかの有用な洞察が得られます。 ここで見つけてください。

tl;dr

ASH はログではなくサンプルです。SUM ではなく COUNT に使用します。

「これらのテーブルをクエリする方法に問題はありますか?」

上で述べたように、おそらく十分に明確にしておらずDBA_HIST_ACTIVE_SESSION_HIST、ASH のレコードの一部しか保持していません。SUM()そのため、ライブ ASH よりもその列で実行することはさらに意味がありません。

一方V$SESSION_EVENT、イベントの実際のログです。その待ち時間は信頼でき、正確です。そのため、時限統計を有効にするオーバーヘッドが発生します。そうは言っても、V$SESSION_EVENTセッションごとの集計値しか得られないため、診断には特に役立ちません。

于 2013-01-08T12:30:19.760 に答える