8

Oracleでクエリを実行していますが、ハングしている場合とハングしていない場合があります。現在、約10時間実行されていますが、ロードしているデータの量に基づいて、不合理ではない可能性があります。

私はgv$sessionでセッションを見ていて、その情報を変換して実際にアクティビティが発生しているかどうかを確認する方法があるのか​​、それともクエリがロックを待っているかハングしているのか疑問に思っていました。

このビューのドキュメントはここですでに読んでいます。私は主に、Oracleでこれらのタイプの問題をデバッグした経験のある人からのヒントを探しています。

ありがとう!

4

3 に答える 3

9

gv$sessionの列にはevent、セッションが現在待機している待機イベントが表示されます。セッションが別のセッションによって保持されているある種のロックを待機している場合、は次のeventように通知します(たとえば、別のセッションによって保持されている行をロックするためにキューに入れられている場合は、「enq:TX-行ロックの競合」になります)そしてblocking_instanceblocking_sessionロックの所有者のインスタンスとセッションIDが入力されます。あなたも見ることができますseconds_in_wait(もしwait_time=0)セッションが現在の待機イベントで費やした秒数を判別します。少なくとも、セッションが現在「スタック」しているかどうかはわかりますが、クエリが本当に終了するかどうかはわかりません。悪い計画がある場合は、「良い」状態になっている可能性があります。セッションが何かを実行しているが、クエリが実際には終了しないことを示すディスクI/Oの待機などの待機イベント。

于 2012-04-27T14:56:27.717 に答える
6

いくつかのさらなる調査とOllieのコメントに基づいて、問題のデバッグに役立つ次のクエリを思いつきました。

select s.sid, 
       s.username,
       s.machine,
       s.osuser, 
       cpu_time,
       (elapsed_time/1000000)/60 as minutes,
       sql_text
from gv$sqlarea a, gv$session s
where s.sql_id = a.sql_id
and s.machine like '####';


select lo.*, 
       a.sql_text
from gv$sqlarea a, gv$session_longops lo
where lo.sql_id = a.sql_id
and lo.sid = ####
order by lo.start_time;
于 2012-04-27T14:46:26.923 に答える
0

これは、現在実行中のセッションを確認するのに役立ちます

select a.SID, a.SERIAL#, c.OBJECT_NAME 
from v$session a, v$locked_object b, user_objects c
where a.SID=b.SESSION_ID and b.OBJECT_ID=c.OBJECT_ID
于 2013-12-13T05:54:06.403 に答える