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

2015年 7月 30日 (木) 22:12:47 JST

久保(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
>