web-dev-qa-db-ja.com

OracleDBでの非常に長いV_ $ SYSTEM_EVENT待機時間

一般的なパフォーマンスの問題が発生しているOracleDBのトラブルシューティングに取り組んでいます。次のクエリを実行しました。

SELECT event AS "Event|Name",
       total_waits "Total|Waits",
       round(time_waited / 100, 0) "Seconds|Waiting",
       total_timeouts "Total|Timeouts",
       average_wait / 100 "Average|Wait|(in secs)"
  FROM sys.v_$system_event e
  ORDER BY time_waited DESC;

最初の数行は次のように返されました。数百万秒の待機時間！ （比較すると、他のDBは上位のイベントの待機時間が10秒未満です。）これらのイベントは何をし、何がこれらの膨大な待機時間を引き起こす可能性がありますか？ DBは30日間稼働しているため、その期間にわたって集計が行われています。

Event Name                                 Waits    Seconds Timeouts  Avg Wait
----------------------                 ---------   -------- --------  --------
SQL*Net message from client            488397968   32050594        0    0.0656
rdbms ipc message                       91335556    2455744  9529486    0.0269
DIAG idle wait                           5214769     347077  5214769    0.0666
Streams AQ: qmn coordinator idle wait     186521     173696    93278    0.9312
Streams AQ: qmn slave idle wait            95359     173692       51    1.8215
Space Manager: slave idle wait            523165     173647   521016    0.3319
pmon timer                                968303     173630   870108    0.1793
fbar timer                                  8770     173403     8713   19.7723
smon timer                                 14103     173278     7006   12.2866
log file sync                           57967889      90402   649458    0.0016
og file parallel write                  86618366      39509        0    0.0005
db file sequential read                244286101      11171        0         0
control file parallel write              1274395       3949        0    0.0031
db file scattered read                 157316868       1635        0         0
db file parallel read                   11948170       1190        0    0.0001
performanceoracle
2
jeffspost

「SQLクライアントからのネットメッセージ」は、データベースがクライアントから何かをするように求められるのを待つために費やした時間です（これは、SQLデータベースによって処理されるネットリクエスト）。 AskTom イベントに関する詳細情報があります。平均的な待機時間もそれほど長くないように見えるので、サーバーに大量の小さなリクエストを送信するアプリをお持ちですか？これは30日間で多くの待機になります（1日あたり平均1600万）。

Rdbms ipcメッセージの場合、これは （Oracle 10g Reference） ：を意味します。

「バックグラウンドプロセス（LGWR、DBWR、LMS0）は、このイベントを使用して、アイドル状態であり、フォアグラウンドプロセスがIPCメッセージを送信して何らかの作業を行うのを待っていることを示します。」

これは通常、チューニングの観点からはイベントではありません。 （バーレソン）

3
DCookie

v $ system_eventだけから選択することは限られた用途です。ビューには、データベースが最後に開始されてからの合計待機時間とすべての待機イベントのカウントが含まれます。データベースが最後に開始されたのは1年前か数分前かもしれませんが、どちらの方法でも、私は通常、sqlステートメント、バッチジョブ、またはエンドユーザーで現在何が起こっているかだけに関心があります。エンドユーザーは非アイドル非バックグラウンド待機を待機しますが、v $ system_eventには、50を超えるアイドルイベントを含むすべてのイベントが含まれ、データベースを処理するバックグラウンド、非ユーザープロセスを待機します。このクエリを実行するのではなく、AWRレポートまたはstatspackレポートを実行するか、EnterpriseManagerのパフォーマンスまたはトップアクティビティ画面を確認してみてください。データベースで現在何が起こっているかを確認する簡単な方法は、次のselectステートメントを実行することです。

select  nvl(s.username,s.program) username
,   s.sid sid
,   s.serial# serial
,   s.sql_hash_value sql_hash_value
,   substr(decode(w.wait_time, 0, w.event, 'ON CPU'),1,15) event
,   w.p1 p1
,   w.p2 p2
,   w.p3 p3
from    v$session s
,   v$session_wait w
where   w.sid=s.sid
and s.status='ACTIVE'
and s.type='USER';

これにより、誰が待機していて、誰がCPUをオンまたは要求しているかがわかります。クエリを何度も実行することで、システムにどのようなボトルネックがあるかを把握できます。 Oracleの10g以降のビューv $ active_session_historyには、1秒に1回サンプリングされたこの情報が含まれています。 v $ system_eventよりもはるかに強力なデータですが、データをマイニングするのは難しい場合があります。データをマイニングするには、Enterprise Managerの上部アクティビティ画面を使用できますが、OEMがない場合は、クールな無料ツールがあります

http://timurakhmadeev.wordpress.com/2010/02/18/ash-viewer/

0
Kyle Hailey