- PR -

遅いSQLのチューニングについて

1
投稿者投稿内容
TAKE
会議室デビュー日: 2004/11/15
投稿数: 4
投稿日時: 2004-11-15 17:47
SQLのチューニングについて教えて下さい。

現在、Oracle8iで下記のようなSQLを処理しています。

　　SELECT
　　　A,
　　　B,
　　　C,
　　　D,
　　　E,
　　　F,
　　　SUM(G),
　　　MAX(H),
　　　MAX(I)
　　FROM TBL
　　WHERE
　　　　　A=P1
　　AND　B=P2
　　GROUP BY
　　　　　A,
　　　　　B,
　　　　　C,
　　　　　D,
　　　　　E,
　　　　　F;

INDEXをはったりしていますが
データ量が多いせいか
処理に時間がかかってしまいます。

SQLチューニングで処理速度をあげたいと思っているのですが
何か良い方法があれば教えて下さい。

宜しくお願い致します。
いーた
大ベテラン
会議室デビュー日: 2004/07/12
投稿数: 154
お住まい・勤務地: 東京
投稿日時: 2004-11-15 18:07
・レコード総件数と検索結果件数
・現時点でどれ位の処理時間になってしまっているのか
・テーブルの主キーの有無（有るならどれが主キーなのか）
・INDEXを作成したカラム
を教えて下さい。

あと、SQLトレースは取得されましたか？
アクセスパスがわかりますので、取得してみてはいかがでしょうか。
uk
ぬし
会議室デビュー日: 2003/05/20
投稿数: 1155
お住まい・勤務地: 東京都
投稿日時: 2004-11-15 18:11
まず、これだけ見るとAとBに対して複合インデックスが張ってあれば通常は十分だと思います。
ですが、条件にひっかかる件数が多い場合にはC,D,E,Fまで含めてインデックスを張る必要が
あるかもしれません。

とはいうものの、あてずっぽうに対策を考えるのは得策ではありません。まず、実行プランを
検証する必要があるでしょう。また、コストベースの場合は当然ANALYZEをかけている必要が
ありますが、それは大丈夫でしょうか。
TAKE
会議室デビュー日: 2004/11/15
投稿数: 4
投稿日時: 2004-11-15 19:19
返信ありがとうございます。

総件数は　　約 2600万件です。
検索結果の件数は　多い時で　約 250万件です。
処理時間は　30分くらいです。
しかしオラクルの処理が重なると、倍くらいになることもあります。

テーブルの定義はだいたい
CREATE TABLE TBL
（　A,
　　E,
　　aa,
　　B,
　　F,
　　C,
　　D,
　　bb,
　　G,
　　H,
　　I )

このような感じで、
主キーは
（A,
　B,
　C,
　D,
　bb,
　F　）
です。
なぜこのようなカラムの順番で作成したのかは
当初から携わってないので
わかっていません。


作成したINDEXは
（A,
　B,
　C　）
です。
これは、主キーと同じ順番ですが
その他の処理のwhere条件で（A,B,C）を
使用しており、
こちらのINDEXで処理されれば
処理されるINDEXのバイト数が減って
早くなるかと思い作成しました。

しかし、実行計画をみると主キーで処理されています。

トレースも取得しましたが、
見方がよくわかってない部分も多々あると思いますが
特に気になる点はありませんでした。
ちなみにこんな感じです。
　Execution Plan
　---------------------------------------------------
　　SELECT STATEMENT GOAL: CHOOSE
　　　　　SORT (GROUP BY)
　　　　　　TABLE ACCESS GOAL: ANALYZED (BY INDEX ROWID) OF
　　　　　　　　'TBL'
　　　　　　INDEX (RANGE SCAN) OF '主キー' (UNIQUE)


ANALYZEについては、
週に1回、EXECUTE DBMS_STATS.GATHER_SCHEMA_STATS(ユーザー名)　を実行しています。


GROUP BY　で指定したカラムでINDEXを作成した方が
よいのでしょうか？
あんとれ
ぬし
会議室デビュー日: 2004/01/14
投稿数: 556
投稿日時: 2004-11-15 20:02
これだけのデータをソートするとなるとそれなりの領域が必要となるかと思いますが、
ソート領域には十分なメモリが割り当てられていますか？

あと、GROUP BY でソート処理が行われている時点で、
現在設定されているインデックスは WHERE 句による絞り込みにしか
使われていないようですね。

ところで、A 列と B 列はわざわざ取得する必要があるのでしょうか？
SELECT 句で指定する列数が増えただけで遅くなる場合もあるようですので。
TAKE
会議室デビュー日: 2004/11/15
投稿数: 4
投稿日時: 2004-11-15 20:35
ソート領域には大きく割りたてたつもりですが
まだ小さいでしょうか？
sort_area_size = 4096000

A 列と B 列についてですが
カーソル文で取得して
ループ処理を行っているので
その方が処理がわかりやすいかと思いました。

しかし、処理の遅さを考えると
わざわざ取得する必要がないと思います。
ご指摘ありがとうございました。

GROUP BY でソート処理が行われている時点で、
WHERE 句による絞り込みにしかないということは
やはりGROUP BY　で指定したカラムでINDEXを作成すべきでしょうか？

データ量が多いだけに
カラムの多いINDEXを作成して
INSERT処理に影響がでるのではないかと
少し不安です。






ひでさん
会議室デビュー日: 2004/11/17
投稿数: 1
投稿日時: 2004-11-17 15:07
G,H,Iも含めてINDEXを作成して試してもらえますか？
SUMやMAX等で使用するカラムもINDEXにしておくとテーブルアクセスではなくINDEXから取ってくるので、いくらか違うかと思います。
ただ、INSERTやUPDATE時への処理速度の影響がどの程度かちょっと分かりませんが(^^;
TAKE
会議室デビュー日: 2004/11/15
投稿数: 4
投稿日時: 2004-11-24 21:45
返信が遅くなってすいません。

G,H,Iも含めてINDEXを作成してみました。

統計情報で確認したところ
作成したINDEXを使用して
コストの値は減少したのですが
「consistentgets」が増えて
少し遅くなってしまいました。

私の作成したINDEXが間違っているのかもしれませんが
処理が遅くなってしまったので
INDEXの使用はやめようと思います。

アドバイス、ありがとうございました。
1

スキルアップ／キャリアアップ（JOB@IT）