[itpub.net] STATSPACK の詳細な解釈 (1)

 前述のように、見落としがちな点がいくつかあります。レポートを読むときは、まず、このレポートに対応するデータベースのバージョン、クラスタの方法、およびその期間の 3 つの内容に注意を払う必要があります。報告。特に時間帯には注意が必要で、時間帯のない statspck は意味がなく、間違った結果を出すこともあります。

の STATSPACK レポート

1.レポートのヘッダー情報

/*レポート ヘッダー情報、データベース インスタンス関連情報 (データベース名、ID、バージョン番号、ホスト名、およびその他の情報を含む)。

   さらに、重要なポイントは、レポート生成の時間範囲 (ここでは 14 分) と同時実行数 (ここでは 272) に注意する必要があります。

DB 名 DB ID インスタンス インスタンス番号 リリース クラスタ ホスト

------------ ----------- ------------ -------- ------- ---- ---------- ------------

ORA92 1924035339 ora92 1 9.2.0.6.0   いいえ      jsdxh_db02

              Snap Id Snap Time セッション Curs/Sess コメント

            --------- ------------------ -------- --------- ------ -------------

開始スナップ: 13 14-Jul-07 00:18:52      274  55,345.0

  終了スナップ: 14 14-Jul-07 00:32:55 272 55,823.8

   経過時間:               14.05 (分)

キャッシュ サイズ (終了)

~~~~~~~~~~~~~~~~~

               バッファキャッシュ: 5,120M 標準ブロックサイズ: 8K

           共有プール サイズ: 400M ログ バッファ: 2,048K

2.インスタンスロードファイル情報

ロード プロファイル

~~~~~~~~~~~~ トランザクションごとの秒あたり

                                   --------------- ---------------

                  やり直しサイズ: 422,086.46 4,706.23

              論理読み取り: 23,200.54 258.68

              ブロック変更: 3,080.59 34.35

             物理読み取り: 31.46 0.35

            物理書き込み: 104.38 1.16

                 ユーザー コール: 409.32 4.56

                     解析: 227.20 2.53

                ハード解析: 7.22 0.08

                      並べ替え: 213.87 2.38

                     ログオン: 0.85 0.01

                   実行: 1,191.32 13.28

               トランザクション: 89.69

/* Load Profile の意味を以下に詳しく説明します

REDO サイズ: 1 秒あたりに生成されるログのサイズ (バイト単位)。データ変更の頻度と、データベース タスクが重いかどうかを示すことができます。

論理読み取り: 1 秒あたりに生成される論理読み取りブロックの数に等しい。論理読み取り = 一貫性のある取得 + DB ブロックの取得

ブロックの変更: 1 秒あたりのブロック変更の数、データベース トランザクションによって変更されたブロックの数。

物理読み取り:データベースが 1 秒あたりにディスクから読み取るブロックの平均数。

Physical writes:平均每秒数据库写磁盘的block数。

User calls:每秒用户调用次数。

Parses:每秒解析次数，包括fast parse，soft parse和hard parse三种数量的综合。 软解析每秒超过300次意味着你的"应用程序"效率不高，调整session_cursor_cache。在这里，fast parse指的是直接在PGA中命中的情况（设置了session_cached_cursors=n）；soft parse是指在shared pool中命中的情形；hard parse则是指都不命中的情况。

Hard parses:每秒产生的硬解析次数, 每秒超过100次，就可能说明你绑定使用的不好，也可能是共享池设置不合理。这时候可以启用参数cursor_sharing=similar|force，该参数默认值为exact。但该参数设置为similar时，存在bug，可能导致执行计划的不优。

Sorts:每秒产生的排序次数。

Logons:每秒登陆的次数。

Executes:每秒执行次数。

Transactions:每秒产生的事务数，反映数据库任务繁重与否。

  % Blocks changed per Read:   13.28    Recursive Call %:     80.21

 Rollback per transaction %:    0.03       Rows per Sort:      2.84

/* Load Profile 续

1. % Blocks changed per Read：在每一次逻辑读中更改的块的百分比。
2. Rollback per transaction %:看回滚率是不是很高，因为回滚很耗资源 ,如果回滚率过高,可能说明你的数据库经历了太多的无效操作 ,过多的回滚可能还会带来Undo Block的竞争 该参数计算公式如下: Round(User rollbacks / (user commits + user rollbacks) ,4)* 100% 。
3. Recursive Call %:递归调用的百分比，如果有很多PL/SQL，那么这个值就会比较高。
4. Rows per Sort:平均每次排序操作的行数。

3、实例有效性信息

Instance Efficiency Percentages (Target 100%)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

            Buffer Nowait %:   99.98       Redo NoWait %:    100.00

            Buffer  Hit   %:   99.87    In-memory Sort %:    100.00

            Library Hit   %:   99.67        Soft Parse %:     96.82

         Execute to Parse %:   80.93         Latch Hit %:     96.10

Parse CPU to Parse Elapsd %:    6.93     % Non-Parse CPU:     99.88

/*インスタンスの有効性は、この部分の値が 100 に近いほど良いです。サブ項目の詳細は次のとおりです。

1. Buffer Nowait % : バッファ内の Buffer の未待機率を取得します。通常、Buffer Nowait の値は 99% より大きくする必要があります。そうしないと、競合が発生する可能性があり、後の待機イベントでさらに確認できます。
2. Redo NoWait % : Redo バッファー内のバッファー領域を取得する待機していない比率。REDO バッファが 1M に達すると、REDO ログ ファイルに書き込む必要があるため、通常、REDO バッファが 1M を超えるように設定されている場合、バッファ領域の割り当てを待機することはほとんどありません。現在、やり直しバッファは通常 2M に設定されていますが、これはメモリの総量に対して大きすぎる値であってはなりません。
3. Buffer Hit % : データ バッファー内のデータ ブロックのヒット率で、通常は 95% を超えています。それ以外の場合、95% 未満の場合は重要なパラメーターを調整する必要があり、90% 未満の場合は db_cache_size を増やす必要がある場合があります。ヒット率が高いからといって、システムのパフォーマンスが最適であるとは限りません.たとえば、多数の非選択インデックスが頻繁にアクセスされると、ヒット率が高いと錯覚します(多数のdbファイルA 比較的低いヒット率は、一般にシステムのパフォーマンスに影響を与えるため、調整する必要があります。ヒット率の突然の変化は、多くの場合、悪いメッセージです。ヒット率が急上昇した場合は上位バッファ取得SQLを確認し、論理リードが多く発生している文やインデクスを確認し、ヒット率が急減した場合は上位物理リードSQLを確認し、論理リードが多発している文を確認することができます。主にそうでないものを中心に、多数の物理読み取りを生成する インデックスが使用されるか、インデックスが削除されます。
4. In-memory Sort % : メモリ内のソート率。95%未満の場合は、初期化パラメータPGA_AGGREGATE_TARGETまたはSORT_AREA_SIZEを適切に増やすことで解決できます。これら2つのパラメータ設定の範囲が異なることに注意してください。SORT_AREA_SIZEはセッションごとに設定され、PGA_AGGREGATE_TARGETはすべてのセッションに設定されます。
5. ライブラリ ヒット % : 共有領域での STATEMENT のヒット率は、通常 95% 以上に維持する必要があります。それ以外の場合は、共有プールを増やす、バインド変数を使用する、cursor_sharing およびその他のパラメータを変更するなどを検討する必要があります。
6. Soft Parse % : 共有領域の sql のヒット率が 95% 未満の場合はバインドを考慮する必要がありますが、80% 未満の場合は、SQL は基本的に再利用されていないと考えられます。
7. Execute to Parse % : ステートメントが実行および解析された回数の尺度。計算式は次のとおりです: 実行して解析する = 100 * (1 - 解析/実行)。この例では、ほぼ 5 回の実行ごとに解析が必要です。したがって、システムが解析 > 実行の場合、比率は 0 未満になる可能性があります。通常、値が <0 の場合は、共有プールの設定またはステートメントの効率に問題があり、結果として解析が繰り返されること、再解析が深刻である可能性、またはスナップショットに関連している可能性があることを示します。これは通常、データベースのパフォーマンスに問題があることを示します。
8. Latch Hit % : >99% であることを確認してください。そうしないと、重大なパフォーマンスの問題が発生します。この値に問題がある場合は、後の待機時間とラッチ分析を使用して、問題を見つけて解決できます。
9. Parse CPU to Parse Elapsd %：计算公式为：Parse CPU to Parse Elapsd %= 100*(parse time cpu / parse time elapsed)。即：解析实际运行时间/(解析实际运行时间+解析中等待资源时间)。如果该比率为100%，意味着CPU等待时间为0，没有任何等待。
10. % Non-Parse CPU：计算公式为：% Non-Parse CPU =round(100*1-PARSE_CPU/TOT_CPU),2)。如果这个值比较小，表示解析消耗的CPU时间过多。与PARSE_CPU相比，如果TOT_CPU很高，这个比值将接近100%，这是很好的，说明计算机执行的大部分工作是执行查询的工作，而不是分析查询的工作。

Shared Pool Statistics        Begin   End

                               ------  ------

             Memory Usage %:   32.87   33.12

    % SQL with executions>1:   80.00   82.69

  % Memory for SQL w/exec>1:   77.62   80.70

1. Memory Usage %：正在使用的共享池的百分率。这个数字应该长时间稳定在75%～90%。如果这个百分比太低，表明共享池设置过大，带来额外的管理上的负担，从而在某些条件下会导致性能的下降。如果这个百分率太高，会使共享池外部的组件老化，如果SQL语句被再次执行，这将使得SQL语句被硬解析。在一个大小合适的系统中，共享池的使用率将处于75%到略低于90%的范围内。
2. % SQL with executions>1 : これは、共有プールで複数回実行された SQL ステートメントの数の測定値です。サイクルで実行される傾向があるシステムでは、この数を慎重に検討する必要があります。このループ システムでは、1 日のある時間帯に別の時間帯に異なる SQL ステートメントのセットが実行されます。共有プールには、監視期間中に実行されなかった一連の SQL ステートメントがあります。これは、それらを実行するためのステートメントが監視期間中に実行されなかったためです。この数値が 100% に近づくのは、システムが同じ一連の SQL ステートメントを連続して実行する場合のみです。ここでは、この共有プール内の SQL ステートメントのほぼ 80% が、14 分間の監視ウィンドウの間に複数回実行されたことが示されています。ステートメントの残りの 20% はおそらく既にそこにあり、システムはそれらを実行しません。
3. % Memory for SQL w/exec>1 : これは、使用頻度の低い SQL ステートメントと比較して、頻繁に使用される SQL ステートメントによって消費されるメモリ量の尺度です。この数値は、不規則にメモリを消費する特定のクエリ タスクがない限り、通常、1 を超える実行で % SQL に非常に近くなります。安定した状態では、全体として、共有プールの約 75% から 85% が使用されていることがわかります。Statspack レポートの時間枠がすべての期間をカバーするのに十分な大きさである場合、複数回実行された SQL ステートメントの割合は 100% に近くなります。これは、観測間の期間によって影響を受ける統計です。観察間隔が長くなるにつれて増加することが予想されます。

要約: ORACLE インスタンスの有効性の統計から、一般的な印象を得ることができますが、これからデータ操作のパフォーマンスを判断することはできません。現在のパフォーマンスの問題を判断するには、主に次の待機イベントを確認して確認します。このように 2 つの部分の内容を理解することができます. ヒット統計は、一部のシステムが生成するパフォーマンスの問題を発見および予測するのに役立ち、予防策を講じることができます. 待機イベントは、現在のデータベースに解決が必要なパフォーマンスの問題があることを示しているため、死んだ羊を修復する性質のものです。

次に、待機イベントの確認を開始します。

4.TOP5などの待ち合わせイベント情報

/* oracle待機イベントは、oracle の実行ステータスを測定するための重要な基礎および指標です。待機イベントは、アイドル待機イベントと非アイドル待機イベントの 2 つのカテゴリに分けられます。TIMED_STATISTICS = TRUE の場合、待機イベントは待ち時間; 数量別に並べ替えます。statspack の実行中にセッションで TIMED_STATISTICS = TRUE を設定する必要があります。そうしないと、統計データが歪んでしまいます。アイドル待機イベントは、オラクルが何らかの作業を待機していることです。データベースを診断および最適化する場合、イベントのこの部分にあまり注意を払う必要はありません。非アイドル待機イベントは、特にオラクル アクティビティ用です。 , データベースタスクまたはアプリケーションの実行中に発生する待機. イベントの待機は、データベースをチューニングするときに焦点を当てるべきものです.

    一般的な待機イベントの説明は次のとおりです。

1. db ファイルの分散読み取り
   このイベントは、通常、全テーブル スキャンまたは高速全インデックス スキャンに関連しています。テーブル全体のスキャンはメモリ内で実行されるため、通常はパフォーマンスの考慮事項に基づいて、十分な長さの連続メモリ領域を割り当てることができない場合があるため、データ ブロックはキャッシュ内のバッファに分散 (分散) されます。待機が大きすぎる場合は、インデックスが不足しているか、適切なインデックスがない可能性があります (optimizer_index_cost_adj を調整できます)。全表スキャンの実行は索引スキャンよりも効率的であるため、この状況も正常な場合があります。システムにこれらの待機がある場合は、全表スキャンが必要かどうかを確認して調整する必要があります。フル テーブル スキャンは、LRU (Least Recent Used、Least Recent Available) リストのコールド エンドに配置されるため、頻繁にアクセスされる小さなデータ テーブルの場合は、読み取りの繰り返しを避けるためにメモリにキャッシュすることを選択できます。この待機イベントが重要な場合、v$session_longops 動的パフォーマンス ビューと組み合わせて診断できます。これは長時間実行 (実行時間が 6 秒を超える) 実行中のものを記録し、それらの多くはフル テーブル スキャン操作である可能性があります (いずれにせよ、情報のこの部分は注目に値します)。
   パラメータ OPTIMIZER_INDEX_COST_ADJ=n について: このパラメータはパーセンテージ値です。デフォルト値は 100 で、FULL SCAN COST/INDEX SCAN COST として理解できます。n%* INDEX SCAN COST<FULL SCAN COSTの場合、Oracleは索引の使用を選択します。特定の設定では、特定のステートメントに従って値を調整できます。ステートメントでインデックスを使用したいが、実際にはフル テーブル スキャンを実行する場合、より適切な値を設定するために、2 つのケースで実行プランの異なる COST を比較できます。
2. db file sequential read : このイベントは、1 つのデータ ブロックで多数の待機が発生していることを示します。これは通常、テーブル間の不適切な結合順序 (駆動行ソースを正しく選択しなかった)、または非選択的インデックスの使用が原因です。この待機を statspack レポートに関する他の既知の問題 (非効率的な sql など) と関連付けて調整し、インデックス スキャンが必要であることを確認し、複数テーブル結合の結合順序を確認します。
3. バッファ ビジー待機: この待機は、バッファが非共有の方法でバッファに読み込まれているとき、または読み込まれているときに発生します。値は 1% を超えてはなりません。待機の問題がある場合は、バッファ待機統計セクション (または V$WAITSTAT) をチェックして、待機が発生する場所を特定できます。
   1. 待機がセグメント ヘッダー (Segment Header) にある場合。この状況は、セグメント内の空きリスト (freelist) ブロックが比較的小さいことを示しています。空きリスト (Oracle8i DMT の場合は freelist) を追加するか、空きリスト グループを追加することを検討できます (多くの場合、この調整は即座に行われます (alter table tablename strorage (freelists 2))。8.1.6 より前では、この freelists パラメータを動的に変更することはできません。 ; 8.1.6 以降のバージョンでは、フィーリストを動的に変更するには、少なくとも 8.1.6 に COMPATIBLE を設定する必要があります)。また、PCTUSEDと PCTFREEの間の距離( PCTUSED-to-pctfree ギャップ)を増やすこともできます。実際には、PCTUSED の値を減らすことを意味し、ブロックができるだけ早くフリーリスト リストに戻って再利用されるようにします。Automatic Segment Space Management (ASSM) をサポートしている場合は、ASSM モードも使用できます。これは、ORALCE 920 以降のバージョンの新機能です。
   2. この待機が元に戻すヘッダーにある場合は、ロールバック セグメント (ロールバック セグメント) を増やすことでバッファの問題を解決できます。
   3. 待機が元に戻すブロックにある場合は、送信の頻度を増やしてブロックをできるだけ早く再利用できるようにする必要があります。より大きなロールバック セグメントを使用し、一貫した読み取りによって選択されたテーブル内のデータの密度を減らします。DB_CACHE_SIZE を増やします。 .
   4. 待ちがデータブロックにある場合は、ホットブロックが発生していることを示しており、以下の解決策が考えられます。 pctfree の値を使用してデータ分散を拡張し、競合を減らして、この「ホット」データ ブロックを回避します。②データブロックのサイズも小さくできるので、データブロック内のデータ行数が減り、データブロックの発熱が減り、競合が減る ③ホットブロックで動作するSQL文をチェックし、文を最適化する. ④ホットブロックの initrans 値を大きくする。ただし、inittrans の値を高く設定しすぎないように注意してください。通常は 5 で十分です。トランザクションを追加するということは、ITL トランザクション スロットを追加することを意味し、各 ITL トランザクション スロットはデータ ブロックで 24 バイトを占有するためです。デフォルトでは、各データ ブロックまたはインデックス ブロックに 2 つの ITL スロットがあります. initrans を増やすときは、データ ブロックが配置されているテーブルの PCTFREE 値を増やすことを検討してください。 ITL スロットの数、最大は指定された maxtrans に達します。
   5. 待機がインデックス ブロック内にある場合は、インデックスの再構築、インデックスの分割、または逆キー インデックスの使用を検討する必要があります。データ ブロックに関連するバッファリングされたビジー待機を防ぐために、より小さいブロックも使用できます。または、より大きな PCTFREE を設定して、データの物理的な分散を拡大し、レコード間のホット スポットの競合を減らすことができます。DML (挿入/更新/削除) を実行すると、Oracle はデータ ブロックに情報を書き込みます. 複数のトランザクションが同時にアクセスするデータ テーブルの場合、ITL の競合と待機が発生する可能性があります. この待機を減らすために、initrans を増やして複数のITL スロット。Oracle9i では、ASSM の新機能を使用できます。Oracle はビットマップを使用して領域の使用を管理し、競合を減らします。
4. ラッチ フリー: ラッチ ミス率が 0.5% を超える場合、この問題を調整する必要があります。後で DB の Latch アクティビティ セクションで詳しく説明します。
5. エンキューキューは、一部の共有リソースを保護し、同時 DML 操作を防止するロックです。キューは FIFO 方式を採用していますが、ラッチは使用される FIFO メカニズムではないことに注意してください。より一般的なキューには、ST キュー、HW キュー、および TX4 キューの 3 つのタイプがあります。
   ST エンキュー待機は、主にディクショナリ管理表領域での領域管理および割当て中に生成されます。解決策: 1) ディクショナリ管理表領域をローカル管理モードに変更します。2) パーティションを事前に割り当てるか、問題のディクショナリ管理表領域の次のエクステントをより大きく設定します。
   HW Enqueue は、セグメント HWM に使用されます。このような待ちが発生した場合は、エテントを手動で割り当てることで解決できます。
   TX4 エンキュー待機は、最も一般的な待機状況です。通常、このタイプの待機の原因となる状況は 3 つあります。1) 一意のインデックス内にインデックスが重複している。解決策: コミットまたはロールバックしてキューを解放します。2) 同じビットマップ インデックス フラグメント (ビットマップ インデックス フラグメント) に対する複数の更新があります。これは、ビットマップ インデックス フラグメントに複数の ROWID が含まれる可能性があるためです。そのため、複数のユーザーが更新すると、1 人のユーザーがセグメントをロックし、待機が発生する可能性があります。解決策は上記と同じです。3) 複数のユーザーが同時にデータ・ブロックを更新します。もちろん、これらのDML操作は、このデータ・ブロックの異なる行をターゲットにする場合があります。この時点で空きITLスロットがない場合、ブロックレベルのロックが生成されます。解決策: テーブルの initrans 値を増やしてより多くの ITL スロットを作成するか、テーブルの pctfree 値を増やして、オラクルが必要に応じて pctfree スペースにより多くの ITL スロットを作成できるようにするか、より小さいブロック サイズを使用して、各ブロックが含まれる行が少なくなり、競合の可能性を減らすことができます。
6. Free Buffer：这个等待事件表明系统正在等待内存中的可用空间，这说明当前Buffer 中已经没有Free 的内存空间。如果应用设计良好，SQL 书写规范，充分绑定变量，那这种等待可能说明Buffer Cache 设置的偏小，你可能需要增大DB_CACHE_SIZE。该等待也可能说明DBWR 的写出速度不够，或者磁盘存在严重的竞争，可以需要考虑增加检查点、使用更多的DBWR 进程，或者增加物理磁盘的数量,分散负载，平衡IO。
7. Log file single write：该事件仅与写日志文件头块相关，通常发生在增加新的组成员和增进序列号时。头块写单个进行，因为头块的部分信息是文件号，每个文件不同。更新日志文件头这个操作在后台完成，一般很少出现等待，无需太多关注。
8. log file parallel write：从log buffer 写redo 记录到redo log 文件，主要指常规写操作(相对于log file sync)。如果你的Log group 存在多个组成员，当flush log buffer 时，写操作是并行的，这时候此等待事件可能出现。尽管这个写操作并行处理，直到所有I/O 操作完成该写操作才会完成(如果你的磁盘支持异步IO或者使用IO SLAVE，那么即使只有一个redo log file member,也有可能出现此等待)。这个参数和log file sync 时间相比较可以用来衡量log file 的写入成本。通常称为同步成本率。改善这个等待的方法是将redo logs放到I/O快的盘中，尽量不使用raid5，确保表空间不是处在热备模式下，确保redo log和data的数据文件位于不同的磁盘中。
9. log file sync : ユーザーがデータを送信またはロールバックすると、LGWR はセッションの REDO レコードをログ バッファからログ ファイルに書き込みます。ユーザーのプロセスは、書き込み作業が完了するまで待機する必要があります。送信するたびに発生します。この待機イベントがデータベースのパフォーマンスに影響を与える場合は、アプリケーションの送信頻度を変更する必要があります。この待機イベントを減らすには、一度により多くのレコードを送信するか、REDO ログ REDO にアクセスする必要があります。 LOG ファイルのさまざまな物理ディスクでの I/O パフォーマンスを向上させます。
10. ログ バッファ スペース: ログ バッファの書き込み速度は、LGWR 書き込み REDOFILE 速度よりも高速です。ログ ファイルのサイズを大きくしたり、ログ バッファのサイズを大きくしたり、より高速なディスクを使用してデータを書き込んだりできます。
11. logfile スイッチ: 通常、アーカイブの速度が十分でないためです。すべてのコミット要求が「ログ ファイルの切り替え」の完了を待つ必要があることを示します。ログ ファイルの切り替えには、主に次の 2 つのサブイベントが含まれます。
    ログ ファイルの切り替え (アーカイブが必要) この待機イベントが発生するのは、通常、ログ グループ サイクルがいっぱいになった後に最初のログ アーカイブが完了していないためであり、この待機が発生します。この待機は、io に問題があることを示している可能性があります。解決策: ① ログ ファイルの増加とログ グループの追加を検討する; ② アーカイブ ファイルを高速ディスクに移動する; ③ log_archive_max_processes を調整する。
    ログ ファイルの切り替え (未完了のチェッ​​クポイント) ログ グループが書き込まれるときに、データベースが最初のログ ファイルに記録されたダーティ ブロックの書き込みを完了していない場合 (たとえば、最初のチェック ポイントが完了していない場合)、LGWR は最初のログ ファイルの書き込みを試みます。 、待機イベントが発生します。通常、この待機イベントは、DBWR の書き込みが遅すぎるか、IO に問題があることを示しています。この問題を解決するには、DBWR を追加するか、ログ グループまたはログ ファイルのサイズを増やすか、チェックポイントの頻度を増やすことを検討する必要があります。
12. DB File Parallel Write : DBWR によってファイルが並列に書き込まれるときに発生します。解決策: IO パフォーマンスを改善します。
13. DB File Single Write : ファイル ヘッダーまたは他の単一ブロックが書き込まれるときに発生し、すべての I/O 呼び出しが完了するまで待機します。解決策: IO パフォーマンスを改善します。
14. DB FILE 分散読み取り: 初期化パラメーター db_file_multiblock_read_count に従って複数のブロックを読み取るためにセグメント全体をスキャンするときに発生します。データ。待機時間は、すべての I/O 呼び出しが完了するまでの時間です。解決策: IO パフォーマンスを改善します。
15. DB FILE Sequential Read : 現在のフォアグラウンド プロセスが、インデックス ルックアップやその他の非フル セグメント スキャンを含むデータ ファイルに対して通常の読み取りを実行し、データ ファイル ブロックの破棄を待機しているときに発生します。待機時間は、すべての I/O 呼び出しが完了するまでの時間です。解決策: IO パフォーマンスを改善します。
16. ダイレクト パス読み取り: 一般に、ダイレクト パス読み取りとは、データ ブロックを PGA に直接読み取ることを指します。通常、並べ替え、並列クエリ、および先読み操作に使用されます。この待機は、I/O が原因である可能性があります。非同期 I/O パターンを使用するか、並べ替えをディスクに制限すると、ここでの待機時間が短縮される場合があります。
17. direct path write : Direct path write この待機は、未処理の非同期 I/O がすべてディスクに書き込まれたという確認をシステムが待機しているときに発生します。この書き込み待機では、I/O 操作が最も頻繁に行われるデータ ファイルを見つけ (並べ替え操作が多すぎる場合は、一時ファイルである可能性があります)、負荷を分散し、書き込み操作を高速化する必要があります。システム内のディスク ソートが多すぎると、一時テーブル スペースで頻繁な操作が発生します. この場合、Local を使用してテーブル スペースを管理し、それを複数の小さなファイルに分割し、別のディスクに書き込むか、または生デバイス。
18. control file parallel write : このイベントは、サーバー プロセスがすべての制御ファイルを更新するときに発生する可能性があります。待ち時間が短い場合は、無視できます。待ち時間が長い場合は、制御ファイルを格納する物理ディスクのI/Oにボトルネックがないか確認してください。
    複数の制御ファイルは同一のコピーであり、セキュリティを強化するためにミラーリングに使用されます。ビジネス システムでは、複数の制御ファイルを異なるディスクに格納する必要があります。通常、3 つあれば十分ですが、物理ハード ディスクが 2 つしかない場合は、2 つの制御ファイルでもかまいません。複数の制御ファイルを同じディスクに格納するのは現実的ではありません。この待ち時間を短縮するには、以下の方法が考えられます。 ①制御ファイルの数を減らす（安全性確保前提）。② システムがサポートしている場合は、非同期 IO を使用します。③IO負荷の軽い物理ディスクに制御ファイルを転送する。
19. 制御ファイルの順次読み取り
    制御ファイルの単一書き込み: これら 2 つのイベントは、制御ファイルの順次読み取り/制御ファイルの単一書き込みから単一制御ファイルへの I/O に問題がある場合に発生します。待機が顕著である場合は、個々の制御ファイルをチェックして、ストレージの場所で I/O ボトルネックがないか確認してください。

一般的な IDLE 待機イベントの例:

ディスパッチャータイマー                  

ロック要素のクリーンアップ              

ヌルイベント                         

並列クエリのデキュー待ち       

並列クエリのアイドル待機 - スレーブ 

パイプゲット                          

PL/SQL ロック タイマー                 

pmon タイマー - pmon                  

rdbms ipc メッセージ                 

スレーブ待機                         

smon timer                        

SQL*Net break/reset to client     

SQL*Net message from client       

SQL*Net message to client         

SQL*Net more data to client       

virtual circuit status            

client message                     

SQL*Net message from client  

下面是关于这里的常见的等待事件和解决方法的一个快速预览

等待事件	一般解决方法
Sequential Read	调整相关的索引和选择合适的驱动行源
Scattered Read	表明出现很多全表扫描。优化code，cache小表到内存中。
Free Buffer	增大DB_CACHE_SIZE，增大checkpoint的频率，优化代码
Buffer Busy Segment header	增加freelist或者freelistgroups
Buffer Busy Data block	隔离热块；使用反转索引；使用更小的块；增大表的initrans
Buffer Busy Undo header	增加回滚段的数量或者大小
Buffer Busy Undo block	Commit more；增加回滚段的数量或者大小
Latch Free	检查具体的等待latch类型，解决方法参考后面介绍
Enqueue–ST	使用本地管理的表空间或者增加预分配的盘区大小
Enqueue–HW	在HWM之上预先分配盘区
Enqueue–TX4	在表或者索引上增大initrans的值或者使用更小的块
Log Buffer Space	增大LOG_BUFFER，改善I/O
Log File Switch	增加或者增大日志文件
Log file sync	サブミットの頻度を減らす、より高速な I/O を使用する、未加工の機器を使用する
書き込み完了待ち	DBWR を増やし、CKPT の頻度を増やします。

トップ 5 時限イベント

~~~~~~~~~~~~~~~~~~ %合計

イベント待機時間 (秒) Ela Time

-------------------------------------------- ------ ------ ----------- --------

CPU 時間 361 54.14

ログ ファイルの同期 74,324 101 15.22

エンキュー 729 88 13.28

db ファイルのシーケンシャル読み取り 7,303 65 9.76

dblink からの SQL*Net メッセージ 482 20 3.05

DB の待機イベント: ORA92 インスタンス: ora92 スナップ: 13 -14

-> s - 秒

-> cs - センチ秒 - 100 分の 1 秒

-> ms - ミリ秒 - 1000 分の 1 秒

-> us - マイクロ秒 - 1000000 秒

-> 待機時間 desc 順、waits desc (アイドル イベントが最後)

                                                                   平均

                                                     合計待機待機待機

イベント待機タイムアウト 時間 (秒) (ミリ秒) /txn

---------------------------- ---------------- ---------- ---------- ------ --------

ログ ファイルの同期 74,324 0 101 1 1.0

エンキュー 729 0 88 121 0.0

db ファイルの順次読み取り 7,303 0 65 9 0.1

dblink からの SQL*Net メッセージ 482 0 20 42 0.0

db ファイルの並列書き込み 725 0 14 19 0.0

db ファイルの分散読み取り 2,415 0 6 3 0.0

プロセス起動 8 0 4 440 0.0

ラッチフリー 1,307 1,300 2 1 0.0

ログ ファイルの並列書き込み 67,042 0 2 0 0.9

制御ファイルの順次読み取り 269 0 1 3 0.0

シングルタスク メッセージ 24 0 1 33 0.0

制御ファイル並列書き込み 325 0 1 2 0.0

バッファビジー待機 3,368 0 1 0 0.0

ログファイル切替完了 19 0 0 20 0.0

ダイレクト パス読み取り 288 0 0 0 0.0

LGWR が REDO コピーを待機 1,032 0 0 0 0.0

クライアントへの SQL*Net 追加データ 1,390 0 0 0 0.0

kksfbc 子の完了 1 1 0 10 0.0

ログ ファイルの順次読み取り 2 0 0 5 0.0

ダイレクト パス書き込み 128 0 0 0 0.0

ライブラリ キャッシュ ピン 14 0 0 0 0.0

dblin からの SQL*Net 追加データ 4 0 0 0 0.0

ログ ファイル シングル書き込み 2 0 0 1 0.0

dblink への SQL*Net メッセージ 482 0 0 0 0.0

バッファデッドロック 30 30 0 0 0.0

クライアントからの SQL*Net メッセージ 436,773 0 143,221 328 5.8

jobq スレーブ待機 2,688 1,664 6,688 2488 0.0

起床時間マネージャー 27 27 791 29297 0.0

クライアントへの SQL*Net メッセージ 436,772 0 0 0 5.8

DB のバックグラウンド待機イベント: ORA92 インスタンス: ora92 スナップ: 13 -14

-> 待機時間 desc 順、waits desc (アイドル イベントが最後)

                                                                   平均

                                                     合計待機待機待機

イベント待機タイムアウト 時間 (秒) (ミリ秒) /txn

---------------------------- ---------------- ---------- ---------- ------ --------

db ファイルの並列書き込み 725 0 14 19 0.0

ログ ファイルの並列書き込み 67,044 0 2 0 0.9

制御ファイルの順次読み取り 186 0 1 4 0.0

制御ファイル並列書き込み 325 0 1 2 0.0

db ファイルの分散読み取り 38 0 0 7 0.0

ダイレクト パス読み取り 288 0 0 0 0.0

LGWR が REDO コピーを待機 1,032 0 0 0 0.0

db ファイルの順次読み取り 3 0 0 6 0.0

ログ ファイルの順次読み取り 2 0 0 5 0.0

ダイレクト パス書き込み 128 0 0 0 0.0

ログ ファイル シングル書き込み 2 0 0 1 0.0

rdbms ipc メッセージ 63,167 1,061 4,970 79 0.8

smon タイマー 3 3 879 ###### 0.0

pmon タイマー 292 292 823 2819 0.0