SQLチューニング　2nd Season（第3回）

SQLチューニングはどのように取り組んでいくべきか？（3/3）

いつもSQLチューニングブログをご愛読いただきありがとうございます。

今回は、前回に引き続きまして「 SQLチューニングはどのように取り組んでいくべきか？ 」の3回目としてお送りします。

　1.4 チューニング手順と情報

“SQLのパフォーマンスチューニングを行う際、確認すべきデータ、考慮すべき事項はSQLによって異なります。“

前回までにお伝えしましたが、Table Full Scanという共通の非効率を持つ異なるSQLに対するチューニングの進め方は
同じではありませんでした。
問題の原因を探す大きな枠組みは自体は似てはいるものの、問題のタイプによってSQLが持っている情報を把握する
対象が多様であることは、ここまででご理解いただけたのではないでしょうか？

つまり、どんなに単純なSQLであっても、非効率が発生する原因をきちんと把握し、その原因に合った改善方法を導き出す
ためには、SQLが持つ多くの情報を活用する必要があります。

SQLが持っている情報とは、代表的なものとして下記のようなものがあります。
（更に詳しい内容については、第2章と第3章の方で詳しく説明していきます。）

・　SQLの意味（ 業務的なアプローチ ） 　・　SQLに使われたテーブル及びカラムの統計情報 （ Dictionary View: all_tables, all_tab_columns ） 　・　Where節の条件カラムのインデックス情報 （ Dictionary View: all_indexes, all_ind_columns など ） 　・　Dictionary View中のSQL実行履歴 （ V$SQLAREA, V$SQL_PLAN, DBA_HIST_SQLSTAT など ） 　・　SQL実行履歴（ DBMS_XPLAN、TRACE ）の活用など

このように様々な情報を総合的に分析して得られる結果が、SQLチューニング だと言うことです。
今回のテーマでは、これからSQLチューニングを始ようと考えている読者の皆様に伝えておきたいメッセージがあります。

SQLチューニングとは、SQLが持っている情報を詳細に収集した上で、総合的な思考で分析した結果だと言うことです。

この後の2章と3章では、SQLチューニングが必要なシステムでチューニング対象を選別する際に、活用するデータと
その対象に対して、チューニングを行う過程において、どのような情報を活用すれば「 効果的な改善結果を導き出せるのか？ 」について詳しく説明していきたいと思います。

SQLチューニングブログ　2nd season（第3回）　終

今回のSQLチューニングブログはいかがでしたか？

次回は第2章へ突入していきます。

---

第2章　SQLチューニング対象選定方法　について

---

次回もどうぞお楽しみに
それでは See you next time！

★　日本エクセムのおすすめ　★