DB2 SQLチューニングでデータ量削減を試す方法

2013/03/17 23:44

このQ&Aのポイント

DB2のSQLチューニングでデータ量削減が課題となっています。現在の処理ではCPU負荷が高く、SQLエラーが発生しています。DISTINCTを使用して複数テーブルを結合しているため、データ量が増えていると考えられます。データ量削減のために、SQLの改善方法を試していますが、いまひとつ効果がありませんでした。主に以下の方法を試していますが、改善されていません。
1. DISTINCTをやめて単純なSELECTのみとして、まとめはJavaロジックで実施する方法。しかし、SQLの重さが解消されていません。
2. 結合条件をサブクエリに変えて実施する方法。しかし、むしろ遅くなり、結果が返ってこなくなってしまいました。

DB2 SQLチューニングについて

いつもお世話になっております。 DB2のSQLチューニングで改善案が浮かばずどなたかお知恵を拝借したい次第です。現状は複数テーブルをJOINで結合したものを DISTINCTでまとめています。ですが、あまりにもデータ量が多くCPUに負荷がかかり、 SQLエラーを起こしてしまいます。もはやレスポンス改善以外の道がないのですが、以下は試しても改善されませんでした。・DITINCTをやめて単純なSELECTのみとして、　まとめはJavaロジックで実施　SQLは重いまま。・結合条件をサブクエリに変えて実施　余計に遅くなり、返ってこなくなった。上記を施す前のSQLは以下です。テーブルは4つ（A1, A2, A3, A4） SELECT DISTINCT A1.AAA A1.BBB A1.CCC A2.DDD A2.EEE A2.FFF A2.GGG A3.HHH A3.JJJ A3.KKK A3.LLL A3.MMM A3.NNN A3.OOO A4.PPP A4.QQQ A4.RRR A4.XXX A4.YYY A4.ZZZ FROM DB.A1TBL A1 INNER JOIN DB.A2TBL A2 ON SUBSTR(A2.START_DATE,1,6) <= パラメータ1(YYYYMM形式) AND A2.END_DATE > CONCAT(パラメータ1(YYYYMM形式), '01') AND A1.NUMBER = A2.NUMBER AND A1.MACHIN_ID = A2.MACHIN_ID AND A1.TYPE = A2.TYPE AND A2.DELETE_DATE > CURRENT TIMESTAMP INNER JOIN DB.A3TBL A3 ON SUBSTR(A3.START_DATE,1,6) <= パラメータ1(YYYYMM形式) AND A2.END_DATE > CONCAT(パラメータ1(YYYYMM形式), '01') AND A2.NUMBER = A3.NUMBER AND A2.MACHIN_ID = A3.MACHIN_ID AND A2.TYPE = A3.TYPE AND A2.COLOR = A3.COLOR AND A3.DELETE_DATE > CURRENT TIMESTAMP LEFT OUTER JOIN DB.A4TBL A4 ON STANDARD_MM = パラメータ1(YYYYMM形式) AND A3.END_DATE > CONCAT(パラメータ1(YYYYMM形式), '01') AND A3.NUMBER = A4.NUMBER AND A3.MACHIN_ID = A4.MACHIN_ID AND A3.IN_PLACE_CD = A4.IN_PLACE_CD AND A3.OUT_PLACE_CD = A4.OUT_PLACE_CD AND A3.TYPE = A4.TYPE AND A3.COLOR = A4.COLOR AND A4.DELETE_DATE > CURRENT TIMESTAMP WHERE A1.NUMBER = パラメータ0 AND SUBSTR(A1.START_DATE,1,6) <= パラメータ1(YYYYMM形式) AND A1.END_DATE > CONCAT(パラメータ1(YYYYMM形式), '01') AND A3.KBN LIKE '%' AND A2.ITEM_CD LIKE '%' AND A1.TYPE LIKE '%' AND A2.MACHIN_ID LIKE '%' AND A1.DELETE_DATE > CURRENT TIMESTAMP FOR FETCH ONLY 以上です。何卒宜しくお願い致します。

axelchk
お礼率85% (18/21)

その他(データベース)
回答数1
ありがとう数4

みんなの回答 （1）
専門家の回答

質問者が選んだベストアンサー

ベストアンサー

root139
ベストアンサー率60% (488/809)

2013/03/18 01:28 回答No.1

DB2が手元に無いので一般論的な事を・・・。まず、SQLのチューニングをする場合、何はともあれ EXPLAIN は取りましょう。 http://www.atmarkit.co.jp/fdb/rensai/db2bestprac06/db2bestprac06_3.html EXPLAIN の結果を見て、時間が掛かっていそうな箇所を重点的に改善するのが良いでしょう。なお、DB2で出来るかどうかは分かりませんが、EXPLAINにて各ステップの実際の実行時間が取れる機能があるなら、それを見るのが一番です。 SQLを修正する方向性としては、下記の様な点が挙げられるでしょう。 a. 大きなテーブルのシーケンシャルスキャンが起こらないように b. JOINは極力絞り込んでから c. ディスクソートが起きないように aを実現するためには結合や絞込みで極力INDEXを使うように書くことがポイントになるでしょう。この質問のSQLについては、パッと見、A2TBL, A3TBL, A4TBL の NUMBER, MACHIN_ID, TYPE 辺りにインデックスを貼っておくと効果が有るかも知れません。下記のページも参考になると思います。 http://www.geocities.jp/mickindex/database/db_optimize.html http://itpro.nikkeibp.co.jp/article/COLUMN/20070919/282395 http://itpro.nikkeibp.co.jp/article/COLUMN/20071012/284416 それから、～～～ LIKE '%' は無意味な気がするのですが・・・。もしかして IS NOT NULL の代わりですか？