Oracle チューニング db file sequential read

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

この待機イベントはある程度 → ある程度はどのくらい? → と素直に思いますが、 下の方に目安を書いておきましたので下記を順番に読んで下さい。この待機イベントはある程度発生しても仕方ありません。

理由としては、日々の生活の中でデータが蓄積するものでテーブルのデータ量も当然増加していきます。 それに伴い、この待機イベントも徐々に発生していくものなのです。

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

  インデックスを介してアクセスされる(インデックス/データ)ブロック
  などの単一ブロック読取りの時に発生。また、制御ファイルの再構築、
  データベース・ファイルヘッダーのダンプ、およびデータベース・ファ
  イルヘッダーの取得時に発生。

  db file scattered read とは異なり、読み込み時には 1ブロックずつ 読み
  込みます。

発生するタイミングは?

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

チューニング方法は?

  ・物理読取りを実行しているSQL文の特定。INDEXの有効性などを検討。
  ・FILEの分散。読み込みブロック数、読み込みブロック時間などに着目。
  ・DBBCのサイズを増やす、またはKEEPバッファの使用。効果は期待できるし、
    DBBCのヒット率も向上する。ただし、どのテーブルをKEEPに指定するか重要。

でも急激に変化する場合は、注意が必要です。 データベース知識として当たり前のことですが、他のエンジニアには当たり前ではないかもしれません。 事前に知らせてくれれば対処できるのに、いきなり本番環境投入なんてする人もいますので注意が必要です。 下に行くほどひどいケースです。

遅い遅いとよくフロントのエンジニアから言われますが、データベースがボトルネックとなっていない ケースが良くあります。特に、急激にシステムが遅くなった場合などは人的操作が怪しいもの。しかし 、徐々に増加するケースは仕方ないものでチューニングする必要があります。

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

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

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