Oracle チューニング db file sequential read
Oracle において db file sequential read とは以下を示します。
- どんな待機イベントですか?
- 発生するタイミングは?
- チューニング方法は?
- 上限(30%)の場合、対策が必要!!
この待機イベントはある程度 → ある程度はどのくらい? → と素直に思いますが、 下の方に目安を書いておきましたので下記を順番に読んで下さい。この待機イベントはある程度発生しても仕方ありません。
理由としては、日々の生活の中でデータが蓄積するものでテーブルのデータ量も当然増加していきます。 それに伴い、この待機イベントも徐々に発生していくものなのです。
どんな待機イベントですか?
インデックスを介してアクセスされる(インデックス/データ)ブロック などの単一ブロック読取りの時に発生。また、制御ファイルの再構築、 データベース・ファイルヘッダーのダンプ、およびデータベース・ファ イルヘッダーの取得時に発生。 db file scattered read とは異なり、読み込み時には 1ブロックずつ 読み 込みます。
発生するタイミングは?
"Full Table Scans"、"Fast Full Index Scans"、"Index Scans" に伴って発生。
チューニング方法は?
・物理読取りを実行しているSQL文の特定。INDEXの有効性などを検討。 ・FILEの分散。読み込みブロック数、読み込みブロック時間などに着目。 ・DBBCのサイズを増やす、またはKEEPバッファの使用。効果は期待できるし、 DBBCのヒット率も向上する。ただし、どのテーブルをKEEPに指定するか重要。
でも急激に変化する場合は、注意が必要です。 データベース知識として当たり前のことですが、他のエンジニアには当たり前ではないかもしれません。 事前に知らせてくれれば対処できるのに、いきなり本番環境投入なんてする人もいますので注意が必要です。 下に行くほどひどいケースです。
- インデックスの変更/削除
- 大量データの投入後の実行
- 定期的に Analyze していない
- インデックスの作成を忘れている
- インデックスは作成しているが適切なカラムに付与していない
- 使用していないインデックスがテーブルに付与されている
遅い遅いとよくフロントのエンジニアから言われますが、データベースがボトルネックとなっていない ケースが良くあります。特に、急激にシステムが遅くなった場合などは人的操作が怪しいもの。しかし 、徐々に増加するケースは仕方ないものでチューニングする必要があります。
上限(30%)の場合、対策が必要!!
STATSPACK、AWK などの情報→TOP 5 EVENTS の中で 30% の割合を占めてくると 対策が必要ですかね。必要としないケースもありますが、指摘されると思います ので、チューニングポイントは抑えておきたいです。 でも、SQL文のチューニング、FileReads が 20ms~30ms と対策が難しい場合、 最も頻繁にアクセスされるセグメントのデータを減らしたり、そのセグメントを 他の早いディスクに分けるのが有効です。
ご訪問頂き有難う御座います。
当サイトを効率良く使うためにまずは FrontPage を見て下さい。
検索方法、一覧表示などの各情報を纏めています。
当サイトの説明 → Frontpage