I/Oによって引き起こされます。I/O)に関係なく、実行されることがありますが、ハードウェアプラットフォームとDISK_ASYNCH_IOパラメータに影響を受けます。I/Oは、一般的に、ディスクの一時的(temporary)セグメントへのアクセス時に使用されます。join)の際に発生します。Readを実行することができます。readイベントを報告することになります。これについての詳細は、次のBlogポストを参照してください。Replyイベントを待機することが観察されます。read待機は必然的なものです。readイベントの待機時間が過度に高く出た場合は、次のような観点から、チューニングポイントを見つけなければなりません。このイベントの待機回数と待機時間は誤解を招く可能性があります。非同期I/Oが使用されていなかった場合、セッションは、I/Oが完了するまで待機します。read待機イベントを待つことになります。したがって待ち時間はかなり短く表示されます。read要求をした後、PGA内部にキャッシュされたブロックの処理を行います。read待機イベントが発生しています。したがって、読み取り要求の回数は、待機回数と同じではありません。read待機イベントの数値は信頼できないのです。read(lob)待機イベントで別々に区分されます。readオペレーションを実行するSQL文によって発生します。run)を一時テーブルスペースに記録します。一時テーブルスペースのソートランは最終的な結果を作成するために、順次PGAに読まれてマージされます。read待機イベントを待機します。Hintまたはオプティマイザの判断によりMERGE結合を実行するSQL文も、並べ替え操作が必要となります。ヒント(hint)またはオプティマイザの判断によってHASH結合を実行するSQL文は、PGA内で許可することができない大きさのハッシュパーティションを一時テーブルスペースに記録します。TEMPORARY表スペースに記録されたハッシュパーティションは、SQLステートメントの条件に一致するレコードを見つけるために戻ってPGAに読み込まれます。read待機イベントを待機します。read待機イベントを評価しない方が良いです。readを実行しているセッションを見つけることができます。readsの合計で構成されています。readsを発生させるセッションを見つけることに加えて、セッションがデータを読み取る位置(一時テーブルスペース、データファイルなど)、待機を発生させるSQL文を把握しなければなりません。次のクエリでは、これに対する答えを与えることができます。一時テーブルスペースからデータを読み取るセッションは、ソートやハッシュセグメントを読んでいるでしょう。size)がメモリソートを実行するのに十分ではないことを意味します。これは問題にはなりません。すべてのソートがメモリでのみ実行されるのは、現実的に不可能だからです。pass)ソートは可能な限り防止しなければなりません。マルチパスソートは、一時表スペースのかなりのI/Oを誘発し、非常に遅くなるからです。9iの以前のバージョンでは、容易ではありません。10032トレースイベントを設定した後、トレースファイルを確認しなければならないのです。SQL_WORKAREA_ACTIVEビューを照会してみるだけでも、確認が可能となりました。Right」ホワイトペーパーを参照してください。このような場合には、チューニングの目標は、ディスクソート回数を最小限にすることです。SORT_AREA_SIZE(またはPGA_AGGREGATE_TARGET)のサイズを増加することにより、ディスクソートの回数を減らすことができます。これは非常にSORT_AREA_SIZEが小さく設定されている場合を除き、根本的な解決方法とは言えません。アプリケーションでソートが必ず必要かを確認しなければならないのです。アプリケーションは、DISTINCTとUNION関数を濫用して使用する傾向があります。LOOPS結合を使用するようにしなければなりません。オプティマイザドライビングテーブルを正しく選択したかも確認する必要があります。BY句とよく合うように設定しておけばソートを避けることもできます。areaを自動的に割り当てして使うことができるように設定することも検討してのみましょう。統計的に見たときに、自動的にメモリ管理をするようにすると、メモリソートの割合をより高めてくれます。size)が小さく、メモリにハッシュテーブルを収容していない場合となります。解決方法は、既に述べなったものと類似しています。HASH_AREA_SIZEが小さすぎる場合でなければ、HASH_AREA_SIZE(またはPGA_AGGREGATE_TARGET)を調整する前に、まずアプリケーションとSQLステートメントをチューニングする必要があります。SQL文に適しているとスレーブの数が適しているかを確認しなければなりません。クエリスレーブがシステムのCPUとディスク・リソースをすべて使い果たしていないことを確認しなければなりません。SQL文を見つけることは容易ではないことでありません。PX_SESSIONビューが導入されるまでは、さらに大変なことでした。SQL文を見つける方法を、Oracle8.1.5以前のバージョンとそれ以降のバージョンについて、それぞれ説明します。オラクル8.1.5以前のバージョン--Note:下のクエリは、SYSユーザによって実行される並列クエリ文を区別することができません。SYSユーザーは同じAUDSIDを共有するからです。8.1.5以降のバージョンで使用される。read待機イベントの待機パラメータは以下の通りです。待機時間I/O関連のイベントなので、タイムアウトが発生せず、セッションは、I/Oが完了するまで待機します。read待機は必然的なもので、待機自体をチューニングすることは不可能です。Query自体の性能を改善させることが正しいアプローチとなります。Queryを実行することは、むしろ性能を低下させる要因となります。データファイルに直接読み取り操作を実行する前に、読み取りの対象となるオブジェクトのダーティブロックがデータ・ファイルに記録されなければならないというものがあります。チェックポイントが発生するようになるのです。contention待機が発生します。Oは、Oracleで最も重要な資源です。Oracleが提供するすべての機能は、最終的にどのようにすれば、ファイルに対してよりよくデータをread/Writeするかに関するものです。したがって、自然にOracleのパフォーマンスの問題の多くは、I/Oと関連があります。I/OとOracleのパフォーマンスの問題を理解するには、オラクルでのI/O操作は、複数の層(Layer)で構成されているという事実を理解することです。オラクルでのI/O処理層を次のように分けて説明してみることにします。>4の順に従ってください。論理的な面だけでなく、経済的な面でさらに有効となります。それぞれの層に必要な予備知識とメカニズムについて記述します。Layer)アプリケーションを効果的に実装して、不必要なI/Oを最小限に抑える必要があります。非効率的なアプリケーションをそのままにして、システムをチューニングすることはほとんど不可能です。Oracleは、I/Oを効率的に処理する様々なテクニックを提供します。readなどが代表的な例となります。Oracleのバージョンが上がるほど、より効率的に作業を処理することができる強力なSQLの機能が追加されます。Function)が代表的な例ですが、この関数をうまく利用すれば、I/Oを大幅に削減しながら、さまざまな集計機能を実装することができます。これらの最新のSQL文を使用して、I/O負荷を減らすようにしなければなりません。Index)などの機能を適切に使用して、I/Oを効果的に使用することも、アプリケーションで実装するべき機能となります。Layer)バッファキャッシュは、OracleのI/O管理の核心です。頻繁に使用するブロックをメモリにキャッシュすることにより、物理的なI/Oを減らすことができます。Oracleのバージョンが上がるにつれてバッファキャッシュを処理するアルゴリズムが絶えず改善され、加えて、新しい管理方法が提供されています。バッファキャッシュを効果的に使用すると、物理I/Oが減り、自然にI/Oパフォーマンスの問題が解決される場合が多くあります。Oracleが提供する機能には、次のようなものがあります。countベースの効率的なLRUアルゴリズムを提供します。メモリから押し出さないようにオフします。効果的に管理することができます。システムで一般的によく使用されるオブジェクトは、Defaultバッファを使用します。比較的定期的に使用される小さなサイズのオブジェクトは、Keepバッファに常駐させることをお勧めします。無駄にすることを防止することができます。9iのからブロックサイズを2K〜32Kまで使用可能となりました。多い場合)には、大きいサイズのブロックを使用することにより、パフォーマンスの改善効果を得ることができます。5.メモリに上げる必要がない大容量のデータを処理する際は、バッファキャッシュをバイパスする方法を使用することができます。するための同期メカニズムが不要で、その分性能が改善されます。SGAつまり、バッファキャッシュを経由することをさします。I/Oをサポートします。