Oracle チューニング db file scattered read

Oracle において db file scattered read とは以下を示します。

この待機イベントの発生はある程度仕方ないものです。 理由としては http://www.bishounen.sakura.ne.jp/rails/my_knowledge/show/134 にも書いてあります。

ただ db file sequential read とは異なる点としては、個々のSQL文においてデータ特性などを考え ると → "Full Scans"の方が断然に性能を出す場合があります。その場合に、システム全体としての 性能を評価することを忘れがちなので、本番環境に投入する前に試験を十分に行う必要があります。ゆえに 「個々のSQLの性能が良いからと言っても、システム全体として性能を出さなければチューニングする目的を 達成することができない」ことを忘れずに。

どんな待機イベントですか?

  ディスクからDBBCへ、マルチブロック読取りを行って取得した
  ブロックを読み込む時に発生。一度に読み込める最大のブロック
  数は、初期化パラメータDB_FILE_MULTIBLOCK_READ_COUNTに設定さ
  れている値であるので重要です。

原因は?

  "Full Table Scans"、"Fast Full Index Scans"に伴い発生。

チューニング方法は?

  ・上記発生原因のSQL文を特定して、FULLスキャンが良いのか、
    INDEXスキャンが良いのかを検討する。
  ・初期化パラメータDB_FILE_MULTIBLOCK_READ_COUNTの再設定。
  ・KEEPバッファの使用。効果は期待できるし、DBBCのヒット率も
    向上する。ただし、どのテーブルをKEEPに載せるかは重要。

この待機イベントを減少させるには、当然、個々のSQL文のチューニングが必要ですが、システム全体としての 性能測定をするのも忘れてはいけませんので、以下のチューニングポイントは試験しましょう。

経験上で性能向上した例としては、KEEPバッファのメモリ数を変更すると性能が向上しました。その時 に注意する点は、メモリ数の調整バッファに載せるオブジェクトの調整 を何度も試して最 適な KEEP バッファの利用をすること。

上限(30%)の場合、対策が必要!!

  STATSPACK、AWK などの情報→TOP 5 EVENTS の中で 30% の割合を占めてくると
  対策が必要ですかね。必要としないケースもありますが、指摘されると思います
  ので、チューニングポイントは抑えておきたいです。
  でも、SQL文のチューニング、FileReads が 20ms~30ms と対策が難しい場合、
  最も頻繁にアクセスされるセグメントのデータを減らしたり、そのセグメントを
  他の早いディスクに分けるのが有効です。

ご訪問頂き有難う御座います。 当サイトを効率良く使うためにまずは FrontPage を見て下さい。 検索方法、一覧表示などの各情報を纏めています。
当サイトの説明 → Frontpage