Oracle チューニング db file scattered read
Oracle において db file scattered read とは以下を示します。
- どんな待機イベントですか?
- 原因は?
- チューニング方法は?
- 上限(30%)の場合、対策が必要!!
この待機イベントの発生はある程度仕方ないものです。 理由としては 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文のチューニングが必要ですが、システム全体としての 性能測定をするのも忘れてはいけませんので、以下のチューニングポイントは試験しましょう。
- 個々のSQL文のチューニング
- システム全体の性能評価
- DB_FILE_MULTIBLOCK_READ_COUNT の変更
- KEEPバッファの使用
経験上で性能向上した例としては、KEEPバッファのメモリ数を変更すると性能が向上しました。その時 に注意する点は、メモリ数の調整 と バッファに載せるオブジェクトの調整 を何度も試して最 適な KEEP バッファの利用をすること。
上限(30%)の場合、対策が必要!!
STATSPACK、AWK などの情報→TOP 5 EVENTS の中で 30% の割合を占めてくると 対策が必要ですかね。必要としないケースもありますが、指摘されると思います ので、チューニングポイントは抑えておきたいです。 でも、SQL文のチューニング、FileReads が 20ms~30ms と対策が難しい場合、 最も頻繁にアクセスされるセグメントのデータを減らしたり、そのセグメントを 他の早いディスクに分けるのが有効です。
ご訪問頂き有難う御座います。
当サイトを効率良く使うためにまずは FrontPage を見て下さい。
検索方法、一覧表示などの各情報を纏めています。
当サイトの説明 → Frontpage