3

DBMS_SCHEDULER によって実行される PL/SQL ブロックがあります。先週から開始されており、今頃には完了しているはずですが、まだ完了していません。問題を特定しようとしていますが、これをデバッグし続ける方法についてアドバイスが必要です。ここに事実があります。

1) オラクル 11g

2) PL/SQL コードがログ テーブルに出力され、問題が発生している一般的な領域を取得できます。これがハングを発見した方法です。どこで詰まっているのか、行番号がわかりません。方法がわかりません。

3) V$SESSION_LONGOPS テーブルは、ユーザー/スキーマがまだ実行中であることを示していますが、日付はすべて過去数日です。それ以来、それは動揺していません。

4) V$SESSION_LONGOPS の OPNAME は、一連の異なるテーブルの「テーブルのインデックス統計の収集」と「テーブル スキャン」に分割されます (最初のテーブルは 8、2 番目のテーブルは 8)。彼らは幅広いテーブルに見えます。各行で、SOFAR と TOTAL の値は互いに等しくなります。「Gather...」行はすべてゼロですが、「Table Scan」行はゼロではありませんが等しいです。

5) V$SESSION に対してクエリを実行すると、私のジョブは ACTIVE になります。

6) 処理中のテーブルにロックがありますが、自分のスキーマで他のセッションが再生されていません。

7) CPU 使用率がかなり低い。

実行中のPL/SQLブロックをさらに詳しく調べることはできますか? 渡された生のブロックを示す V$SQL で完全な SQL を見つけることができます。呼び出されたコンパイル済みのカスタム プロシージャ (行番号など) を詳しく調べたいと思います。

ロックに関しては、私のテーブルに割り当てられた V$LOCKED_OBJECTS にロックが表示されます。ロックでブロックされているプロセスを表示するテーブルはありますか? デッドロックがあれば見つけたい。

どんな提案でも大歓迎です、

mj

4

2 に答える 2

6

独自のインストルメンテーションを構築するか、デバッグまたはプロファイリングを有効にしない限り、現在実行中の行番号を見つける方法はありません。これは制限のように思えますが、すべての行番号を追跡することによるパフォーマンスへの影響を想像してみてください。

ほとんどの実行時間の長いジョブは、PL/SQL ではなく SQL で待機しています。(そうでない場合は、別の問題があります。) SQL ステートメントを追跡する方法は多数あります。V$SESSION_LONGOPS は便利ですが、通常はもっと良い方法があります。おそらく最善の方法は、Oracle Enterprise Manager がある場合はそれを使用することです。ターゲットに移動し、[パフォーマンス] -> [トップ アクティビティ] に移動すると、過去 1 時間のシステム アクティビティと SQL ステートメントのグラフが表示されます。

例 (OEM コンセプト ガイドから): ここに画像の説明を入力

OEM がインストールされていない場合、またはアクセスできない場合は、SQL を追跡する方法が他にもいくつかあります。まず、関連する SQL ステートメントを特定します。これにより、現在何が実行されているか、実行されている時間がわかります。

select elapsed_time/1000000 seconds, gv$sql.*
from gv$sql
where users_executing > 0
order by 1 desc;

運が良ければ、時間がかかるのは 1 つの SQL ステートメントだけです。一連の小さな SQL ステートメントがある場合は、where users_executing > 0述語を除外して、アプリケーションに関連する最もコストのかかるステートメントを見つける必要がある場合があります。

一般に、SQL ステートメントは、次の 3 つの主な理由で遅くなったり停止したりします。

  1. リソースを待機しています。select * from dba_resumable; おそらく、クエリが一時テーブルスペースを占有しすぎており、DBA がさらに追加するのを待っている可能性があります 。または、並列キューイングが有効になっていて、さらなる並列セッションを待っている可能性があります。(それが DBA_RESUMABLE に表示されるかどうかはわかりません。)
  2. ロックを待っています。select * from gv$session where final_blocking_session is not null; そこにある行に問題がある可能性があることを 確認してください。通常、オブジェクト レベルでロックを追跡することは望ましくありません。何があなたをブロックしているのかではなく、誰があなたをブロックしているのかを見つける方がはるかに簡単です。行またはテーブルがロックされている場合、セッションは行またはオブジェクトではなくトランザクションを待機します。デッドロックは、2 つのセッションが異なる順序で同じリソースを必要とする場合にのみ発生し、それが発生した場合はエラー メッセージが表示されることに注意してください。
  3. SQL の実行を待機しています。 これは明らかに最も難しい問題です。今何をすべきかについての簡単なチェックリストはありません。通常、計画と各ステップの所要時間を示すアクティブなレポートを生成することから始めます select dbms_sqltune.report_sql_monitor(sql_id => 'your sql id', type=>'active') from dual;。このレポートは PL/SQL ブロックに対しても機能しますが、各 SQL にかかる時間を示すだけです。次に、それをより良く実行する方法を理解するのはあなた次第です。
于 2013-11-11T19:23:37.473 に答える