[Seasar-user:22079] Re: 実行環境によるSQL処理の差異について

2015年 7月 31日 (金) 09:54:40 JST

久保さん

成田です。

考察ありがとうございます。
ご指摘の通り、１については遅いものではありません。
１で絞り込んだものに対する２のSQLが遅い、が
課題となっています。

なおINSERTコストの考慮も確認しておりますが
通常のSELECTでも遅い状況です。（2について）

頂いた観点踏まえまして、SQLの改善、または
プロシージャなどによる対応の方針で
進める形にしようかと思います。
色々とご意見いただきありがとうございました。

一旦こちらをもってクローズいただければと思います。
※面白い結果がわかれば共有できればと思います。


以上、よろしくお願いいたします。
--

2015年7月30日 22:12 kubo <dbflute ＠ gmail.com>:

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