SELECT実行結果のレスポンス改善について

質問

いつもお世話になっております。
Oracle9i＋XP（CPU=PentiumCore2Duo,メモリ=2MB）の環境にて、以下のようなSELECT文なのですが、実行結果が出るまでに約４５分もかかってしまいます。
何が悪いのか切り分けるために、以下の副問い合わせのみを切り取ってSQLPLUSで実行してみると15件ずつが約10秒おきに返ってくるという現象が確認できたため、おそらくこの副問い合わせではないかと思っております。
データ件数としては、ZAIテーブルが約6万件、MEISAIテーブルが約12万件、VIEW_ROOM_CALENDERビューが約6千件で、それ以外はしれとります。
一応すべてのテーブルのキーにはインデックスがはられているようです。
色々と調べてautotraceにて実行計画などを見てみましたが正直よくわかりませんでした。
テーブル構造やリレーション、カラム数、レコード長など情報が少なく大変申し訳ないのですが必要であれば提示させていただきますので、SQL文がおかしいとか、ネック部分の調べ方とか、なにかヒントのようなものでも結構ですので、どなたかご教授いただけませんでしょうか？
宜しくお願い致します。

select
D.KANJYA_NO || ',' ||
D.NAME || ',' ||
A.BYOU_NAME || ',' ||
count(COL_PT) || ',' ||
count(COL_OT) || ',' ||
count(COL_ST)
from
(
-- 副問い合わせ
select
B.KANJYA_NO as KAN_NO,
B.KAIKEI_DATE,
G.BYOUTOU_NAME as BYOU_NAME,
(case when C.MASTER_CODE in ('01017' , '01022' , '01025') then B.TOTAL_KAISUU else NULL end) as COL_PT,
(case when C.MASTER_CODE in ('01019' , '01021' , '01023') then B.TOTAL_KAISUU else NULL end) as COL_OT,
(case when C.MASTER_CODE in ('01016' , '01020' , '01024') then B.TOTAL_KAISUU else NULL end) as COL_ST
from
ZAI&1 B
inner join
MEISAI&1 C
on
C.NYUUGAI = B.NYUUGAI
and C.KANJYA_NO = B.KANJYA_NO
and C.ZAI_NO = B.ZAI_NO
and C.KAIKEI_DATE = B.KAIKEI_DATE
and B.KAIKEI_DATE Like '&1' || '%'
and B.NYUUGAI = 2
and B.KANJYA_NO not like '*%'
and C.MASTER_CODE in ('01017','01022','01025','01019','01021','01023','01016','01020','01024')
inner join
NYUUIN_ROOM E
on
C.KANJYA_NO = E.KANJYA_NO
inner join
VIEW_ROOM_CALENDER H
on
E.KANJYA_NO = H.KANJYA_NO
and C.KAIKEI_DATE = H.YYYYMMDD
and lpad(E.ROOM_NO,'10','0') = TO_NUMBER(H.ROOM_NO)
inner join
ROOM_TABLE F
on
E.ROOM_CODE = F.ROOM_CODE
inner join
BYT_TABLE G
on
G.BYOUTOU_CODE = F.BYOUTOU_CODE
) A
inner join
KANJYA D
on
A.KAN_NO = D.KANJYA_NO
group by
D.KANJYA_NO,
D.NAME,
D.BIRTH,
A.BYOUTOU_NAME
;

回答No.3

cyanberry

お礼の回答です。

＞他の代替処置が思いつかないので、ご教授いただくことはできますでしょうか？

前述した通り、仕様がわからないのでアドバイスの仕様がありません。
強いて言うなら以下の点で気になります。

・B.KAIKEI_DATEは"DATE型"か"DATETIME型"ではないのですか？LIKEではなく等号、不等号で条件指定できそうな気がするのですが。
・「lpad(E.ROOM_NO,'10','0') = TO_NUMBER(H.ROOM_NO)」ですが、lpadかTO_NUMBERかどちらかは必要ないように思えるのですが、どうなんでしょうか？

「VIEW_ROOM_CALENDER」がおそらくビューだとは思うのですが、何をやっているのか分からないので何とも言えませんが、ここがネックになっているかも知れませんので、単体で使用した時のレスポンスを調べておいたほうが良いかと思います。

他の方がおっしゃられているように、explainで調べるか、クエリーを少しずつ切りだして実行して、何が原因かを調べるのが先決かと思います。

ちなみにindexを新たに張ることに関しては触れていませんでしたが、それはできない感じなのでしょうか？

お礼

ご回答ありがとうございます！
>・B.KAIKEI_DATEは"DATE型"か"DATETIME型"ではないのですか？LIKEではなく等号、不等号で条件指定できそうな気がするのですが。
残念ながらKAIKEI_DATEはvarchar2なのです。

>・「lpad(E.ROOM_NO,'10','0') = TO_NUMBER(H.ROOM_NO)」ですが、lpadかTO_NUMBERかどちらかは必要ないように思えるのですが、どうなんでしょうか？

現状では必要ですが、あまり関数は使わない方がよいみたいなので無くせるようにビューの構造を見直してみる価値はありそうですね。

>「VIEW_ROOM_CALENDER」がおそらくビューだとは思うのですが、何をやっているのか分からないので何とも言えませんが、ここがネックになっているかも知れませんので、単体で使用した時のレスポンスを調べておいたほうが良いかと思います。

ここがやはりネックになっていたようです。ビュー作成自体は早いのですが、結合にTABLE ACCESS FULLが頻発しておりました。ビューにインデックスははれないようなので、マテリアライズド・ビューとかにした方がよいのでしょうか？良くわかっていないのですが・・

>ちなみにindexを新たに張ることに関しては触れていませんでしたが、それはできない感じなのでしょうか？

基本的にパッケージなので、勝手にテーブルにインデックスをはってよいかどうかはわからないのです。