いつもお世話になっております。
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
;
いつもお世話になっております。
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
;
あいまい検索(部分一致)検索をする際に、あいまい検索だとインデックスも効かないので、インデックスを張ってパフォーマンス向上という訳にもいかず、パフォーマンスが非常に悪くて困っています。
状況としては、WEBアプリケーションで、検索画面から検索条件を入力し、「Find」ボタンを押下するとJavaでSQLを発行し、Oracleへ接続するという仕組みのシステムです。
下記のようなケースで、後者のSQLに変更するとガツンとパフォーマンスが向上したのですが、偶然でしょうか?
【もともとのSQL】
select name
,age
,sex
,blood_type
,address
from TABLE1
where age >= 20
and age < 30
and blood_type = 'A'
and name like '%山%'
and address like '%中央区%'
/
【パフォーマンスが向上したSQL】
select * from
(select name
,age
,sex
,blood_type
,address
from TABLE1
where age >= 20
and age < 30
and blood_type = 'A'
)
where name like '%山%'
and address like '%中央区%'
/
というふうに、あいまい検索部分を別出ししました。
WHERE句の条件をANDでたくさんつなげる際に、2度の問い合わせにはなりますが、一度あいまい検索以外の条件で絞り込んで、それから再度その結果に対してあいまい検索を実施した方が早いのではないかと思ってやったところ実際に早くなったのですが、これは偶然でしょうか?
件数が増えると逆に遅くなるとかだと、逆効果なので、理論的にはどうなのか、ご存知の方がいらっしゃったら教えてください。
また、実際にはテーブルではなく、VIEWに対しての検索で実施しました。
よろしくお願い致します。
