<div dir="ltr">久保さん<div><br></div><div>成田です。</div><div><br></div><div>考察ありがとうございます。</div><div>ご指摘の通り、１については遅いものではありません。</div><div>１で絞り込んだものに対する２のSQLが遅い、が</div><div>課題となっています。</div><div><br></div><div>なおINSERTコストの考慮も確認しておりますが</div><div>通常のSELECTでも遅い状況です。（2について）</div><div><br></div><div>頂いた観点踏まえまして、SQLの改善、または</div><div>プロシージャなどによる対応の方針で</div><div>進める形にしようかと思います。</div><div>色々とご意見いただきありがとうございました。</div><div><br></div><div>一旦こちらをもってクローズいただければと思います。</div><div>※面白い結果がわかれば共有できればと思います。</div><div><br></div><div><br></div><div class="gmail_extra">以上、よろしくお願いいたします。</div><div class="gmail_extra">--</div><div><br></div><div class="gmail_extra"><div class="gmail_quote">2015年7月30日 22:12 kubo <span dir="ltr"><<a href="mailto:dbflute@gmail.com" target="_blank">dbflute@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">久保(jflute)です<br> <br> なるほど、シングルDBとRACで違くて、<br> 待てば帰ってくるということで、<br> 処理は進んでて単に時間がかかっていることですね。<br> <span class=""><br> >　a：10秒以内に返ってくる条件、<br> >　b：10分で返ってくる条件、<br> >　c：30分以上返ってこない条件が確認できました。<br> </span>> …<br> > > 処理遅延時間に関しては、実行時の条件句によって変わります。<br> <br> 条件というのは、マテリアライズドビューの検索のことでしょうか？<br> <span class="">２．INSERT TEMP_TABLE2 SELECT * FROM TEMP_TABLE1<br> </span>が遅いという話だったので、<br> １のビューの条件はあまり関係ないのかなと思ったのですが、<br> １も遅いのでしょうか？<br> (２は一時テーブルから一時テーブルのSQLなので、<br> マテビューの条件が影響すると考えにくいかなと思いまして)<br> <br> もし、１も遅い (or １の方が遅い) のであれば、<br> 単純に SELECT * FROM MV_USER するだけで遅いのかどうか、<br> 試したいところですね。<br> <br> >　どちらの環境においても、アプリからの実行と<br> >　クライアントツールからの実行で、<br> >　大きく処理時間が違いました。<br> <br> こちら方向性での検証は、お約束の検証方法なのですが、<br> フレームワークのDataSourceを使って、<br> JDBCベタに実行してみるといいかと思います。<br> 外だしSQLの execute() メソッドも、<br> (execute()メソッドを使われていますよね？)<br> 単純にPreparedStatementのexecute()を呼んでいるだけなので、<br> そこで差が出るとか考えにくいですが、<br> 原因ポイントの切り分けのために。<br> <br> > 大幅に改修することは直近は難しいため、<br> > 影響の少ない改修方法を探しております。<br> <br> 原因追及が長引いたら回避策として、<br> プロシージャを作ってアプリからはそれを実行するだけってのも<br> アリかもしれません。それで速くなるかわかりませんが…<br> (逆にそれでも遅いとなれば、アプリからのDB接続セッションに<br> 何かしらクライアントツールからの接続と違う点があるのかも)<br> <div class="HOEnZb"><div class="h5"><br> <br> <br> 2015-07-30 21:15 GMT+09:00 Nari <<a href="mailto:trickster.m.3@gmail.com">trickster.m.3@gmail.com</a>>:<br> > 久保さん<br> ><br> > お世話になっております。成田です。<br> > ご確認ありがとうございます。<br> ><br> > 頂いた件についてですが、以下ご参照いただけますか。<br> > 環境など漏れていた点もあり申し訳ありませんが、<br> > その点加味しても状況は同様です。<br> > --------------------------------<br> > o そのSQLはDBFluteの外だしSQLを使って実行している？<br> > →使っています<br> ><br> >　 o 30分待てば終わる？ (or 永遠に終わりそうにない？)<br> > →スペックにより差異はありますが<br> >　環境によっては終わりそうにないとしています。<br> >　 (長時間化する)<br> ><br> >　パフォーマンスの悪い環境(シングルDB)では、<br> >　 a：10秒以内に返ってくる条件、<br> >　 b：10分で返ってくる条件、<br> >　 c：30分以上返ってこない条件が確認できました。<br> ><br> >　パフォーマンスのよい環境(RAC)では、<br> >　上記と同じ条件、SQLの場合でそれぞれ、<br> >　 a：2秒で返ってくる、<br> >　 b：20秒で返ってくる、<br> >　 c：2分30秒で返ってくることが確認されました。<br> ><br> >　 o 何度実行しても必ず遅い？<br> > →遅い<br> ><br> >　 o どの環境でも再現する？<br> > →パフォーマンスがよい環境では、<br> >　 20秒でレスポンスが返ってくることが確認されました。<br> >　ただし、クライアントツールでは同様のDBに対して、<br> >　該当のSQLでデータを抽出するまで、<br> >　 2秒で取得できることが確認されました。<br> >　どちらの環境においても、アプリからの実行と<br> >　クライアントツールからの実行で、<br> >　大きく処理時間が違いました。<br> ><br> >>処理が遅いのか、ロック待ちしているのか、<br> >>で全然解決方法が違うと思うので、<br> >>とりあえずこのへんの情報を整理できるといいかと。<br> > ロック待ちはない認識です。<br> > 単純にSQL発行を単独実施しているため。<br> > OracleのV$LOCK内には、常に実行しているSQLが1つだけ、<br> > 滞納していることを確認しております。<br> > 処理遅延時間に関しては、実行時の条件句によって変わります。<br> ><br> >>あと、１と２でトランザクションを分けるとどうなるか？<br> >>とかの検証にしてみたいところですね。<br> > １と２のトランザクションですが、一時テーブルを使っているため、<br> > 分割をすることができません。<br> > 大幅に改修することは直近は難しいため、<br> > 影響の少ない改修方法を探しております。<br> ><br> ><br> > 以上、よろしくお願いいたします。<br> > --<br> ><br> > 2015年7月30日 15:51 kubo <<a href="mailto:dbflute@gmail.com">dbflute@gmail.com</a>>:<br> >><br> >> 久保(jflute)です<br> >><br> >> 成田さん、こんにちは<br> >><br> >> 色々と登場人物が多いので、<br> >> まずはちょっと状況の整理からできればと。<br> >><br> >> > ２．INSERT TEMP_TABLE2 SELECT * FROM TEMP_TABLE1 ;(※)<br> >> >　　　 (処理件数123391件)<br> >><br> >> このSQLを、アプリケーションの中から、<br> >> 実行したら30分かかったということでしょうか？<br> >>　 o そのSQLはDBFluteの外だしSQLを使って実行している？<br> >>　 o 30分待てば終わる？ (or 永遠に終わりそうにない？)<br> >>　 o 何度実行しても必ず遅い？<br> >>　 o どの環境でも再現する？<br> >><br> >> 処理が遅いのか、ロック待ちしているのか、<br> >> で全然解決方法が違うと思うので、<br> >> とりあえずこのへんの情報を整理できるといいかと。<br> >><br> >> あと、１と２でトランザクションを分けるとどうなるか？<br> >> とかの検証にしてみたいところですね。<br> >><br> >><br> >> 2015-07-30 15:00 GMT+09:00 Nari <<a href="mailto:trickster.m.3@gmail.com">trickster.m.3@gmail.com</a>>:<br> >> > お世話になります。成田と申します。<br> >> ><br> >> > 以前はOracleのLikeSearchの件でお世話になりました。<br> >> ><br> >> > 今回、dbfluteを利用しているアプリにて<br> >> > 気になる事象がありましたので<br> >> > 何か知見ありましたらご教授いただけますと幸いです。<br> >> > ------------------------------------------------------------------------<br> >> > ■環境<br> >> >　 java:jdk1.7.0_51<br> >> >　 tomcat:7.0<br> >> >　 framework:Spring Framework 3.2.8.RELEASE<br> >> >　 DB:Oracle Database 11g Release 11.2.0.3.0 - 64bit Production<br> >> >　 O/Rマッパー:dbflute<br> >> >　 jdbc：ojdbc7-12.1.0.1.0.jar<br> >> ><br> >> > ■概要<br> >> >　 Webアプリケーション上の一部の処理で、<br> >> >　パフォーマンスが極端に悪い事象が確認されました。<br> >> >　該当の処理は、1度のSQLで実行すると非常に動作が遅いため、<br> >> >　一時テーブルを利用し、<br> >> >　いくつかの処理に分解して実行しています。<br> >> ><br> >> > ■事象<br> >> >　同一Transaction内で、OracleのGLOBAL TEMPORARY TABLEを利用し、<br> >> >　以下のような処理をしております。<br> >> ><br> >> > ------------------------------------------------<br> >> >　１．INSERT TEMP_TABLE1 SELECT * FROM MV_USER ;(※)<br> >> >　　　 (処理件数143170件)<br> >> ><br> >> >　２．INSERT TEMP_TABLE2 SELECT * FROM TEMP_TABLE1 ;(※)<br> >> >　　　 (処理件数123391件)<br> >> >　・・・・・・<br> >> ><br> >> >　 ※各テーブル名は以下の表またはビューとなります。<br> >> >　　 TEMP_TABLE1:GLOBAL TEMPORARY TABLE<br> >> >　　 TEMP_TABLE2:GLOBAL TEMPORARY TABLE<br> >> >　　 MV_USER:MATERIALIZED VIEW<br> >> > ------------------------------------------------<br> >> ><br> >> >　上記の場合、アプリケーションから２のSQLを実行した所、<br> >> >　パフォーマンスが悪くDBに滞納が確認されました。<br> >> >　 sys権限でV$LOCK内のロック時間を確認すると<br> >> >　 30分以上、滞納していることが確認できました。<br> >> ><br> >> >　一方、同様のSQLをOracleのクライアントツール(Osqledit：odbc)を<br> >> >　用いて実行すると、約2秒ほどで１、２のSQLを実施できました。<br> >> ><br> >> > ■補足<br> >> >　 jdbc、odbcによる影響もあるかとしツールでの差異を確認しましたが<br> >> >　 SQLDeveloper(jdbc)でも処理が早いことを確認しております。<br> >> ><br> >> > 本件の原因、理由が特定できていないため、<br> >> > 過去の事例や、どういった原因が考えられるか<br> >> > アドバイスを頂けますでしょうか。<br> >> ><br> >> ><br> >> > 以上、よろしくお願いいたします。<br> >> > --<br> >> ><br> >> > _______________________________________________<br> >> > Seasar-user mailing list<br> >> > <a href="mailto:Seasar-user@ml.seasar.org">Seasar-user@ml.seasar.org</a><br> >> > <a href="https://ml.seasar.org/mailman/listinfo/seasar-user" rel="noreferrer" target="_blank">https://ml.seasar.org/mailman/listinfo/seasar-user</a><br> >> ><br> >> _______________________________________________<br> >> Seasar-user mailing list<br> >> <a href="mailto:Seasar-user@ml.seasar.org">Seasar-user@ml.seasar.org</a><br> >> <a href="https://ml.seasar.org/mailman/listinfo/seasar-user" rel="noreferrer" target="_blank">https://ml.seasar.org/mailman/listinfo/seasar-user</a><br> ><br> ><br> ><br> > _______________________________________________<br> > Seasar-user mailing list<br> > <a href="mailto:Seasar-user@ml.seasar.org">Seasar-user@ml.seasar.org</a><br> > <a href="https://ml.seasar.org/mailman/listinfo/seasar-user" rel="noreferrer" target="_blank">https://ml.seasar.org/mailman/listinfo/seasar-user</a><br> ><br> _______________________________________________<br> Seasar-user mailing list<br> <a href="mailto:Seasar-user@ml.seasar.org">Seasar-user@ml.seasar.org</a><br> <a href="https://ml.seasar.org/mailman/listinfo/seasar-user" rel="noreferrer" target="_blank">https://ml.seasar.org/mailman/listinfo/seasar-user</a><br> </div></div></blockquote></div><br></div></div>