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

[Nari]

久保さん

お世話になっております。成田です。
ご確認ありがとうございます。

頂いた件についてですが、以下ご参照いただけますか。
環境など漏れていた点もあり申し訳ありませんが、
その点加味しても状況は同様です。
--------------------------------
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
>
-------------- next part --------------
HTML$B$NE:IU%U%!%$%k$rJ]4I$7$^$7$?(B...
URL: <http://ml.seasar.org/archives/seasar-user/attachments/20150730/5ff32f08/attachment.html>