
Oracle SQLチューニング Season2(第9回)第2章 SQLチューニング対象選定方法(6/8)
SQLチューニング対象選定方法 の第6回目は(Case別)SQLチューニング対象選定方法の3回目 です。
「Case3. Literal SQL関連の性能改善対象選定」について解説していきます。
それでは早速スタートしましょう!!
2.3.3 Case3. Literal SQL関連の性能改善対象選定
■ Literal SQL関連の性能改善対象選定
I/OやCPU基準などでTop SQLを抽出する方法はCase1で紹介しました。
しかし、全ての環境で共通的に使えるわけではありません。
プログラムの特性上、Literal SQLが多く使われる環境であればそうなります。
Literal SQLが多い環境では、SQLをそれぞれ別のSQLとして規定すると、正常な結果を抽出することができません。
例えば、SELECT * FROM EMP WHERE EMPNO = 1234; と SELECT * FROM EMP WHERE EMPNO=1235;
この二つのSQLが実行される場合、これらを別々に規定せず、一つのSQLで判断するようにスクリプトを実行しなければ、意味のあるデータを抽出することができません。
[ Literal SQL抽出スクリプト ]
■ 活用例
特定のDBサーバーの性能改善作業のために、Case 1(CPU_RATIO基準)で紹介したスクリプトを実行してみたところ、下記の[表2-5]のような結果が抽出されました。
上記結果を見てみると、Top SQL ListのCPU_RATIO、つまりCPU使用率が全体的に低く、実行回数も少ないことを確認することができます。また、SQL Textが互いに似ていることが確認できます。
このような結果は、Literal SQLが頻繁に実行される環境においては多く発生する抽出結果です。
つまり、一般的なTop SQLを抽出するスクリプトを実行することに意味がありません。
[表2-6]は、条件の定数値だけが異なるSQLを1つのSQLとして規定して、性能関連データをSummaryした抽出結果です。
上の表にある結果を見てみると、上位3つのSQLがCPU使用率の大部分を占めることが分かります。
このようにLiteral SQLが多く実行されるシステムでは、Literal SQLに対する別の処理を行い、対象抽出スクリプトを実行することで、正確な対象を照会できるようになります。
その結果、様々な形のSQLが実行されたような誤解をされる余地を未然に防ぐことが可能です。
次回ブログテーマ
SQLチューニングブログ 2nd Season(第10回)
「 Case.4 パッチプログラム関連性能改善対象の選定 」について