sql >> データベース >  >> RDS >> Oracle

誰もが知っておくべきOracle待機イベント

    誰もが知っておくべき一般的なOracle待機イベントの一部を次に示します。

    イベントを待つ
    次のクエリで、どのイベントセッションが待機しているかを確認できます

    select event from V$session_wait where sid=&1

    いくつかの一般的なOracle待機イベントについて説明しようとしています。原因と解決策があります

    エンキュー

    プロセスは、Oracleエンキュー（v $ lockに表示されるロック）を待機しています。これは通常、あるユーザーが別のユーザーによって現在更新されているテーブルの行を更新しようとしているときに発生します。ブロッカーは、次のクエリを使用して見つけることができます

    select * from dba_waiters

    ライブラリキャッシュピン
    プロセスは、検査のためにライブラリキャッシュのメモリにオブジェクトを固定し、他のプロセスが同時にオブジェクトを更新できないようにします。これは、PL/SQLオブジェクトまたはビューをコンパイルまたは解析しているときに発生します。この待機イベントを回避するために、使用頻度の高い時間にPL/SQLオブジェクトまたはOracleビューをコンパイルしないでください

    ライブラリキャッシュロードロック
    プロセスは、オブジェクトまたはオブジェクトの一部をライブラリキャッシュにロードする機会を待っています。 （一度に1つのプロセスのみがオブジェクトまたはオブジェクトの一部をロードできます。）

    ラッチフリー
    プロセスは、別のプロセスによって保持されているラッチを待機しています。 （この待機イベントは、ラッチの待機中に回転しているプロセスには適用されません。プロセスが回転しているときは待機していません。）ラッチは、共有データ構造、オブジェクト、
    ラッチは、メモリ内のデータ構造を変更するのにかかる時間など、非常に短い期間保持されるように設計されたロックです。これらは、データベースブロックバッファキャッシュや共有プールのライブラリキャッシュなど、特定のメモリ構造を保護するために使用されます。

    Oracle Latchesは通常、「待機」モードで内部的に要求されます。これは、ラッチが使用できない場合、要求しているセッションが短時間スリープし、後で操作を再試行することを意味します。他のラッチは、「即時」モードで要求される場合があります。これは、概念がSELECT FOR UPDATE NO-WAITに似ています。つまり、プロセスは、空きの可能性がある同等の兄弟ラッチを取得しようとするなど、他のことを実行します。座ってこのラッチが利用可能になるのを待つのではなく。多くのリクエストが同時にラッチを待機している可能性があるため、一部のプロセスが他のプロセスよりも長く待機している場合があります。

    必要に応じて、抽選の運に基づいて、ラッチがかなりランダムに割り当てられます。リリースされた直後にラッチを要求するセッションは、それを取得します。ラッチウェイターの列はなく、ウェイターの群れが絶えず再試行しているだけです。

    バッファビジー待機
    プロセスは、現在メモリにないデータブロックにアクセスしようとしていますが、別のプロセスがブロックをメモリに読み込むためのI/O要求をすでに発行しています。 （プロセスは、他のプロセスがブロックをメモリに取り込むのを完了するのを待っています。）ホットブロックは、ビューV $ BH

    を使用して見つけることができます

    dbファイルの分散読み取り
    プロセスは、一連の連続するブロックをデータファイルからバッファキャッシュに読み込むためのI / O要求を発行し、操作が完了するのを待機しています。これは通常、全表スキャンまたは全索引スキャン中に発生します。

    クエリが全表スキャンを使用する必要があるかどうかを確認する必要があります。 Oracleオプティマイザの統計が最新であることを確認してください。パーティションプルーニングを使用して、アクセスするブロックの数を減らします

    しばらく正常に実行されていたクエリが、dbファイルの分散読み取りイベントで突然多くの時間を計測し、コードが変更されていない場合は、1つ以上のインデックスが削除されたかどうかを確認する必要があります。使用できなくなります。

    dbファイルの順次読み取り
    プロセスは、データファイルからバッファキャッシュに1つのブロックを読み取るためのI / O要求を発行し、操作が完了するのを待機しています。これは通常、必要なデータブロックがまだメモリにない場合に、インデックスルックアップまたはROWIDによるOracleテーブルからのフェッチ中に発生します。この待機イベントの紛らわしい名前に惑わされないでください！

    適切なインデックスが使用されているかどうかを確認する必要があります。インデックスが間違っていると、クエリのパフォーマンスが低下する可能性があります。オプティマイザの統計が最新であることを確認してください。

    dbファイルの並列読み取り
    プロセスは、データファイルからメモリにブロックを読み取るために複数のI / O要求を並行して発行し、すべての要求が完了するのを待っています。ドキュメントには、この待機イベントはリカバリ中にのみ発生すると記載されていますが、実際には、プロセスが多数の単一ブロックI / O要求をまとめてバッチ処理し、それらを並行して発行する通常のアクティビティ中にも発生します。 （名前にもかかわらず、並列クエリまたは並列DML中にこの待機イベントは表示されません。そのような場合、名前にPXが含まれる待機イベントが代わりに発生します。）

    dbファイルの並列書き込み
    プロセス（通常はDBWR）は、バッファキャッシュからディスクにダーティブロックを書き込むために複数のI / O要求を並行して発行し、すべての要求が完了するのを待っています。

    ダイレクトパス読み取り、ダイレクトパス書き込み
    プロセスは、バッファキャッシュをバイパスする非同期I / O要求を発行し、それらが完了するのを待機しています。これらの待機イベントには通常、並べ替えセグメントが含まれます。

    ORDER BY、GROUP BY、UNION、DISTINCT、ROLLUPなどのソートを必要とする関数を含むSQLステートメントは、入力サイズがPGAのワークエリアよりも大きい場合、一時テーブルスペースにソート実行を書き込みます

    オプティマイザーの統計情報がデータに対応しており、クエリが適切な駆動テーブルを使用していることを確認してください。完全にソートされないように、複合インデックスの列をORDERBY句に一致するように再配置できるかどうかを確認してください。

    適切な値PGA_AGGREGATE_TARGETが設定されていることを確認してください。可能であれば、UNIONの代わりにUNIONALLを使用してください。

    共有プールラッチ

    共有プールラッチは、共有プール内のメモリを割り当てたり解放したりするときに重要な操作を保護するために使用されます。共有プールとライブラリキャッシュラッチの競合は、主に激しいハード解析が原因です。ハード解析は、新しいカーソルと、期限切れになって再実行する必要があるカーソルに適用されます。
    新しいSQLステートメントの解析のコストは、CPU要件と、ライブラリキャッシュと共有プールの回数の両方の点で高くつきます。ラッチを取得して解放する必要がある場合があります。

    リテラルSQLを削除すると、共有プールラッチを回避するのにも役立ちます

    制御ファイルの順次読み取り
    プロセスは、ブロックが制御ファイルから読み取られるのを待っています。これは一般的に発生します

    • 制御ファイルのバックアップを作成する
    • 制御ファイルからの（インスタンス間での）情報の共有
    • 制御ファイルから他のブロックを読み取る
    • ヘッダーブロックの読み取り

    これが主要な待機イベントである場合は、制御ファイルの場所をより高速なディスクの場所に変更する必要があることを意味します

    制御ファイルの並列書き込み
    プロセスは、すべての制御ファイルにブロックを書き込むために複数のI / O要求を並行して発行し、すべての書き込みが完了するのを待っています。

    ログバッファスペース
    プロセスは、ログバッファでスペースが使用可能になるのを待機しています（スペースは、LGWRがログバッファの現在の内容をディスクに書き込んだ後でのみ使用可能になります）。これは通常、アプリケーションがLGWRが書き込むよりも速くREDOを生成する場合に発生します。ディスクに。

    これは、REDOログが配置されているディスクへのI/Oが遅い場合にも発生する可能性があります

    データベース内にログバッファスペースの待機がないようにする必要があります。ログバッファが小さい場合はログバッファを大きくするか、ログファイルをストライプディスクなどのより高速なディスクに移動することを検討してください。

    Select event, total_waits, total_timeouts, time_waited, average_wait
from v$system_event
where event = 'log buffer space';
Select sid, event, seconds_in_wait, state
from v$session_wait
where event = 'log buffer space';
Select name, value
from v$sysstat
where name in ('redo log space requests');

    pct_buff_alloc_retriesは、ゼロまたは0.01未満（<1％）である必要があります。それが大きい場合は、ログバッファを大きくすることを検討してください。それよりも大きい場合は、ログファイルをストライプディスクなどのより高速なディスクに移動することを検討してください。

    Select v1.value as redo_buff_alloc_retries, v2.value as redo_entries,
trunc(v1.value/v2.value,4) as pct_buff_alloc_retries
from v$sysstat v1, v$sysstat v2
where v1.name = 'redo buffer allocation retries'
and v2.name = 'redo entries';

    ログファイルの順次読み取り
    プロセスは、ブロックがオンラインREDOログからメモリに読み込まれるのを待機しています。これは主に、インスタンスの起動時、およびARCHプロセスがいっぱいになったオンラインREDOログをアーカイブするときに発生します。

    ログファイルの並列書き込み
    プロセスは、1つのグループ内のすべてのオンラインREDOログメンバーにブロックが書き込まれるのを待っています。 LGWRは通常、この待機イベントを確認する唯一のプロセスです。すべてのブロックがすべてのメンバーに書き込まれるまで待機します。

    ログファイルの同期
    プロセスは、LGWRがログバッファのディスクへのフラッシュを終了するのを待っています。これは、ユーザーがトランザクションをコミットしたときに発生します。 （トランザクションを回復するためのすべてのREDOがディスクに正常に書き込まれるまで、トランザクションはコミットされたとは見なされません。）

    LGWRプロセスが遅いと、ログファイルの同期待機が発生し、コミットまたはロールバック中に待機時間が発生する可能性があります。ログファイルの並列書き込みとログファイルの同期待機イベントは相互に関連しているため、同時に処理する必要があります。

    REDOログを高性能ディスク（ソリッドステートディスク）に割り当てる必要があります。また、アプリケーションのコミットを減らすことで、LGWRの負荷を減らすように努める必要があります。

    手動のホットバックアップピースは、多くのやり直しを生成することでシステムにストレスをもたらす可能性もあるため、ピーク時にそれを回避してください

    LGWRがCPUリソースを不足している場合があります。サーバーが非常にビジー状態の場合、LGWRはCPUも不足する可能性があります。これにより、LGWRからの応答が遅くなり、「ログファイルの同期」待機が増加します。結局のところ、これらのシステムコールとI/OコールはCPUを使用する必要があります。この場合、「ログファイルの同期」は二次的な症状であり、CPU使用率が高い根本的な原因を解決すると、「ログファイルの同期」の待機時間が短縮されます。

    メモリ不足の問題により、LGWRもページアウトされる可能性があります。これにより、LGWRからの応答も遅くなる可能性があります。

    セグメント拡張を元に戻す

    セッションは、元に戻るセグメントが拡張または縮小されるのを待っています。

    書き込み完了待機

    セッションは、要求されたバッファーがディスクに書き込まれるのを待っています。書き込み中はバッファを使用できません。

    ラッチ：キャッシュバッファチェーン

    キャッシュバッファチェーンラッチは、バッファキャッシュ内のバッファリストを保護するために使用されます。これらのラッチは、バッファキャッシュを検索、追加、またはバッファキャッシュから削除するときに使用されます。

    バッファキャッシュ内のブロックは、ハッシュテーブルにぶら下がっているリンクリスト（キャッシュバッファチェーン）に配置されます。ブロックが配置されるハッシュチェーンは、ブロックのDBAとCLASSに基づいています。各ハッシュチェーンは、単一の子ラッチによって保護されています。プロセスは、関連するラッチを取得して、ハッシュチェーンをスキャンしてバッファを探し、リンクリストがプロセスの下で変更されないようにする必要があります。

    このラッチでの競合は、通常、大きな競合状態にあるブロック（ホットブロックと呼ばれる）があることを意味します。

    頻繁にアクセスされるバッファチェーン、つまりブロックの競合を特定するには、V $ LATCH_CHILDRENビューを使用して、キャッシュバッファチェーンのラッチのラッチ統計を確認します。他の子ラッチと比較して、より多くのGETS、MISSES、およびSLEEPSを持つ特定のキャッシュバッファーチェーンの子ラッチがある場合、これは子ラッチの競合です。

    このラッチには、ADDR列で識別されるメモリアドレスがあります。

    SELECT
addr,
sleeps
FROM
v$latch_children c,
v$latchname n
WHERE
n.name='cache buffers chains' and
c.latch#=n.latch# and
sleeps > 100
ORDER BY sleeps
/

    V $ BHビューに結合されたADDR列の値を使用して、このラッチによって保護されているブロックを識別します。たとえば、競合の激しいラッチのアドレス（V $ LATCH_CHILDREN.ADDR）が与えられると、これはファイルとブロック番号を照会します。

    SELECT file#, dbablk, class, state, TCH
FROM X$BH
WHERE HLADDR='address of latch';

    X $ BH.TCHは、バッファーのタッチカウントです。 X $ BH.TCHの値が高い場合は、ホットブロックを示しています。

    多くのブロックは、各ラッチによって保護されています。これらのバッファの1つは、おそらくホットブロックになります。 TCH値が高いブロックは、潜在的なホットブロックです。このクエリを何度も実行し、出力に一貫して表示されるブロックを特定します。

    ホットブロックを特定したら、ファイル番号とブロック番号を使用してDBA_EXTENTSにクエリを実行し、セグメントを特定します。

    待機イベントに関する重要な情報

    v $ session_waitビューには、アクティブなセッションが現在待機している待機イベントに関する情報が表示されます。以下はこのビューの説明であり、いくつかの非常に便利な列、特に待機イベントに関連付けられたオブジェクトへのP1およびP2参照が含まれています。

    desc v$session_wait

Name Null? Type
--------------------------- -------- ------------
SID NUMBER
SEQ# NUMBER
EVENT VARCHAR2(64)
P1TEXT VARCHAR2(64)
P1 NUMBER
P1RAW RAW(4)
P2TEXT VARCHAR2(64)
P2 NUMBER
P2RAW RAW(4)
P3TEXT VARCHAR2(64)
P3 NUMBER
P3RAW RAW(4)
WAIT_CLASS_ID NUMBER
WAIT_CLASS# NUMBER
WAIT_CLASS VARCHAR2(64)
WAIT_TIME NUMBER
SECONDS_IN_WAIT NUMBER
STATE VARCHAR2(19)

    v $ session_waitを使用すると、そのパラメーターに対応する説明テキスト列を使用して、各待機イベントパラメーターを簡単に解釈できます。また、待機クラスの列が追加され、さまざまな待機イベントをネットワーク、アプリケーション、アイドル、同時実行などの関連する処理領域にグループ化できるようになりました。
    これらの列も10g以降のv$sessionテーブルに追加されました。 。したがって、v$sessionを使用してすべての詳細を見つけることができます

    各待機イベントには、イベントに関する追加情報を提供する他のパラメータが含まれています。
    待機イベントとそのパラメータに関する情報を見つける方法 

    The meaning of each wait event corresponds know by querying the V$EVENT_NAME p1, p2, p3 of
col name format a25;
col p1 format a10;
col p2 format a10;
col p3 format a10;
SELECT NAME, PARAMETER1 P1, PARAMETER2 P2, PARAMETER3 P3
FROM V$EVENT_NAME
WHERE NAME = '&event_name';

    たとえば、私たちが取ったとしましょう

    event_name入力値：dbファイル分散読み取り
    元の値3：WHERE NAME =‘＆event_name A’
    新しい値3：WHERE NAME=‘dbファイル分散読み取り’

    名前P1P2P3

    dbファイル分散読み取りファイル＃ブロック＃ブロック

    ファイル番号：データファイル番号
    ブロック番号：開始ブロック番号
    ブロック：データブロックの番号を読み取る

    ここで、上記の情報がさまざまなものをキャプチャするのにどのように役立つかを見てみましょう。
    特定のセッションがバッファビジー待機イベントを待機しているとすると、この待機イベントの原因となっているデータベースオブジェクトを簡単に特定できます。

    select username, event, p1, p2 from  v$session_wait  where sid = 4563;

    SID 4563の特定のセッションに対するこのクエリの出力は、次のようになります。

    USERNAME    EVENT            SID P1 P2
---------- ----------------- --- -- ---
APPS         buffer busy waits 4563  11  545

    列P1およびP2により、DBAは、この待機イベントの原因となったファイル番号とブロック番号を判別できます。以下のクエリは、上記のP2の値であるデータブロック155を所有するオブジェクト名を取得します。

    SQL> select segment_name,segment_type
from dba_extents
where file_id = 11
and 45 between block_id and block_id + blocks – 1;

    Oracle Databaseの待機イベントを分析および修正する機能は、どのチューニングプロジェクトでも重要です。データベース内のアクティビティの大部分はデータの読み取りに関係しているため、このタイプの調整はパフォーマンスに大きなプラスの影響を与える可能性があります。

    注：待機分析を行うときは、すべてのOracleデータベースで待機イベントが発生すること、および待機の存在が必ずしも問題を示しているとは限らないことを覚えておくことが重要です。実際、適切に調整されたすべてのデータベースには、いくつかのボトルネックがあります。

    10046イベントを使用して、セッションの待機イベントをトレースすることもできます

    また読む
    Oracleのドキュメント
    v$ active_session_history
    Oracleでの計画の説明


    1. カーソルを使用したAndroidのSQliteクエリ

    2. ローカルSQLServerデータベースのセットアップ

    3. ODP.NETマネージド-要求された.NetFrameworkデータプロバイダーが見つかりません

    4. OLE DBソースコンポーネントのストアドプロシージャパラメータに値を渡すにはどうすればよいですか？