参加時にSQLクエリがハングアップ

Question

各年 - 週 - 鉱山 - 製品のいくつかの統計情報のレポートを作成するSQLクエリを作成しました。

これは1つのことを除いて、正確に動作します。trn.wid-dateは、使用する正しい日付ではありません。

私はtd.datetime-act-comp-dumpを使用する必要があります。 trn.wid-dateをtd.datetime-act-comp-dumpに置き換えると、エラーは発生しませんが、無期限にハングアップするようです。私は昨日それをやり直しました。そしてORA-01652はTEMPの表領域で128を拡張することができませんでしたが、それ以来このエラーは見られませんでした。

私は成功し

select to_char(trn.wid_date, 'IYYY') as dump_year, 
     to_char(trn.wid_date-7/24, 'IW') as dump_week, 
     SUBSTR(trn.train_control_id,1,2) as Mine, 
     vcon.product_type_code as Product, 
     COUNT(DISTINCT trn.train_control_id) as Trains, 
     COUNT(1) as Wagons, 
     MIN(trn.wid_date) as Min_WID_Hrs, 
     MAX(trn.wid_date) as Max_WID_Hrs, 
     MIN(td.datetime_act_comp_dump) as Min_Fin_Dump, 
     MAX(td.datetime_act_comp_dump) as Max_Fin_Dump,   
     ROUND(SUM(con.weight_total-con.empty_weight_total),0) as Tot_Tonnes,  
     ROUND(AVG(con.weight_total-con.empty_weight_total),2) as Avg_Tonnes, 
     ROUND(MIN(con.weight_total-con.empty_weight_total),2) as Minimum, 
     ROUND(PERCENTILE_DISC(0.99) WITHIN GROUP (ORDER BY (con.weight_total-con.empty_weight_total) DESC),2) as "1st",  

from widsys.consist con 
     INNER JOIN widsys.train trn 
     USING (train_record_id) 
     INNER JOIN tpps.train_details td 
     ON trn.train_tpps_id||trn.mine_code = td.train_id||td.mine_code 
     INNER JOIN widsys.v_consist_ore_detail vcon 
     USING (consist_id) 

where trn.direction = 'N' 
     and to_char(trn.wid_date, 'IYYY') = 2009 
     and to_char(trn.wid_date-7/24, 'IW') = 25 

group by to_char(trn.wid_date, 'IYYY'), 
     to_char(trn.wid_date-7/24, 'IW'), 
     SUBSTR(trn.train_control_id,1,2), 
     vcon.product_type_code 

order by to_char(trn.wid_date-7/24, 'IW') DESC 

だけでは、以下のクエリでMAX（td.datetime-ACT-COMP-ダンプ）を返すことができるよということを考慮することを引き起こしている可能性があります理解していません上記のクエリから、私はvconとして、trn.wid_dateをtd.datetime-act-comp-dumpと置き換えることを試みました。その効果はYear-Week-Mine Year-Week-Mine-Productではなく、でしか報告されないということです。

この新しいクエリは、実際にはハングするのではなく実行されますが、いくつかの奇妙な結果が返され、Productで問題が発生しないため十分ではありません。

select to_char(td.datetime_act_comp_dump, 'IYYY') as dump_year, 
     to_char(td.datetime_act_comp_dump-7/24, 'IW') as dump_week, 
     SUBSTR(trn.train_control_id,1,2) as Mine, 
     --vcon.product_type_code as Product, 
     COUNT(DISTINCT trn.train_control_id) as Trains, 
     COUNT(1) as Wagons, 
     MIN(trn.wid_date) as Min_WID_Hrs, 
     MAX(trn.wid_date) as Max_WID_Hrs, 
     MIN(td.datetime_act_comp_dump) as Min_Fin_Dump, 
     MAX(td.datetime_act_comp_dump) as Max_Fin_Dump,   
     ROUND(SUM(con.weight_total-con.empty_weight_total),0) as Tot_Tonnes,  
     ROUND(AVG(con.weight_total-con.empty_weight_total),2) as Avg_Tonnes, 
     ROUND(MIN(con.weight_total-con.empty_weight_total),2) as Minimum, 
     ROUND(PERCENTILE_DISC(0.99) WITHIN GROUP (ORDER BY (con.weight_total-con.empty_weight_total) DESC),2) as "1st"  

from widsys.consist con 
     INNER JOIN widsys.train trn 
     USING (train_record_id) 
     INNER JOIN tpps.train_details td 
     ON trn.train_tpps_id||trn.mine_code = td.train_id||td.mine_code 
     --INNER JOIN widsys.v_consist_ore_detail vcon 
     --USING (consist_id) 

where trn.direction = 'N' 
     and to_char(td.datetime_act_comp_dump, 'IYYY') = 2009 
     and to_char(td.datetime_act_comp_dump-7/24, 'IW') = 25 

group by to_char(td.datetime_act_comp_dump, 'IYYY'), 
     to_char(td.datetime_act_comp_dump-7/24, 'IW'), 
     SUBSTR(trn.train_control_id,1,2) 
     --vcon.product_type_code 

order by to_char(td.datetime_act_comp_dump-7/24, 'IW') DESC 

何がうまくいかない可能性についてアドバイスしますか？

乾杯、

トミー

Answer 1

widsysテーブルのサブクエリとtppsテーブルのサブクエリを作成することで、muuuuuuuchをより高速に実行できるようになりました。次に、連結する代わりに2つの列に対して暗黙的な内部結合を行います。

SELECT blah FROM (widsys subquery) w, (tpps subquery) t WHERE w.mine_code = t.mine_code and w.train_id = t.train_tpps_id 

Answer 2

私はより多くの情報がtrain_detailsのdatetime_act_comp_dump列がインデックス化されていないとwid_dateがあるということであるなしに考えることができる唯一のこと。これは、何かがインデックスに登録されていないか、またはtrainとtrain_detailsテーブルが劇的に異なるサイズであり、あなたの参加が爆発的になっている、かなり正常なパフォーマンス問題のようです。

どのDBを使用しているのかよく分かりませんが、クエリ実行プランプロファイラの実行方法を理解し、2つの実行計画の違いを確認することができます。私は、その答えが何か構造的なものになるか、または結合ステートメントの連結がDB固有の問題を引き起こしていると思われます。