ストアドよりインデックスのほうが速いよ
なんかね、データベースからデータを取得して VB で簡単な加工して、
書き戻すっていう更新処理があったのよ。当然、C/S 間のピンポン多発で
非常に遅いでやんす。で、「バッチ更新はストアドで書き直したらどうですか？」って
上司に言ったわけです。勇気をふりしぼって。
そしたら「ストアドよりインデックスのほうが速いよ」って。(ﾟДﾟ)ﾊｧ?
「クエリ単体の実行時間は 50ms 以下なので遅いのは呼び出しのオーバーヘッドが…」
「データベースが遅いのはね。インデックスなんだよ。たとえば、君の言う
50ms がインデックスを工夫することで 20ms になったら倍以上に速くなるんだよ。」
「いや、50ms が 20ms になっても体感できないと思うんですが…」
「そんなことやってみなくちゃ分からないだろ！！！ やりもしないで何を
言ってるんだよ。インデックスは奥が深いんだよ」
「いまでも主キー指定での取得になっていて…」
「もういいよ。オレがインデックス張ってやるから、まあ見てから言えよ。な？」 もっと分かりやすく文章かけよ
何がいいたいのかﾜｶﾝﾈ なんだか言っていることが面白いよね。
本当雑談だよ。
入社１年目の初心者でしょ。
そのあとの話の展開がどうなったのか教えてちょ。
>>1にはそのピンポン多発で非常に遅いアプリをどうにかできるだけの
VBやネットワーク、OS辺りの幅広い知識を身につける必要があるという事を
認識してほしい。 >>1
逆にストアドプロシージャでは解決する見込みはないと思うけど、解決すると
判断したその根拠は何だろう。
詳細が分からないから断言は難しいけど、やっぱりインデックスが重要だと
思うなぁ。経験的に。 …まあ見てから言えよ。な？
>>1の上司は熊先生に似たナイスガイ(ｳﾗﾔﾏｽｨ こんな感じか？ たとえば、半角全角混在の文字項目を全角に統一する。
(1) レコードセットを取得する。
(2) VBの関数を使って、1レコードを全角に変換して、1レコード分の update 発行。
このようなユーザーの意思を必要としない処理はストアドにして一括更新したほうがいいね。
(2) を何万回も繰り返すのはアホ。 >>7
プロシジャで処理することと
インデックスを張ることは
背反しません。
>経験的に。
無知なまま経験を積んでも実になりませんよ。 >1
ミドルウェアの記述がないので、Java環境での話をすると
以前調べた時、NWとミドルを含めたオーバーヘッドは1,2msだった。
数万件単位で大量件数を処理するならSP化は有効だけど
オンライン系で遅いなら他にボトルネックがあると思われる。
もしかして、毎回コネクション張りにいっているという
オチじゃないだろうな・・
ちなみに、更新系はC/S環境でもSPに匹敵する性能がでるよ。
参照系は、SPには勝てんが。。 質問：
３層c/sでアプリサーバーとDBサーバーが同じノード上にある場合はストアド使わなくても
パフォーマンス出るんでしょうか？ >>13
ストアドの方が僅かにでも速くなることが多い >>2-15
まぁそんなにムキるな。どーせ釣りだろ(ｗ どうしようって言うくらい馬鹿ばかりだなこのスレ。
>>5-7あたりがネタじゃなくて真面目に言ってるとしたら、日本のIT技術者が
素人ばかりというのもあながち間違ってない。
>>1の文章が理解できません・・・
どれが1の発言で、どれが上司の発言なんでしょうか？
>17
たぶん正解だな。
ただ、バカだと思うなら、貴方なりの回答を
聞かせて欲しいものだ。 >12
＞もしかして、毎回コネクション張りにいっているという
＞オチじゃないだろうな・・
そんな気がす・・・ 何回もＳＱＬを発行してない？最近みたプログラムで、カーソルのル
ープ使ってその中でさらに問い合わせを発行して、何万回もＳＱＬを
発行するようなプログラムを見た。
結局、テーブルを結合して一回で問い合わせが完了するようにＳＱＬ
を書き直したら、嘘みたいに早くなったよ。工夫してみれば？ >>23
なんで？1の書き込みには詳細が書いてないから、
22の意見が出てもおかしくないような気が。 結合するより、何回もSQL発行した場合も早いこともあるわけで 一概には言えないと？>>23 >>25
結合するだけで出来るような問い合わせが
自力ループより遅くなるとは考えにくいが。
-- 副問い合わせを含む問い合わせが
-- 自力ループより遅くなる事はある 今更ながら、1の書き込みを読み直してみるとｗ
問題点を通信のオーバーヘッドではないか？と考えているので
>>22さんの意見は、良いところをついているのではないかな。
昔の話だけど実際にそのようなケースを生産性・品質向上
取り組みの副作用として見たことがあるよ。
その時は共通チームが業務共通系の処理を共通関数として
提供してしまった?ため、それに関わるようなマスタテーブルは
そんな処理になってしまった。
最近はマシンも速いから一見遅くはないけど、負荷の高い処理って
なかなか問題が表面化しないで、地雷みたいに埋まってるんだよねぇ。。 >>27
問題とするところがまったく違うんじゃないか？
>>1 の上司が莫迦だって話だろう？ｽﾚﾀｲからしても。 >>28
たしかに問題とする次元が違ってると思う。
｜非常に遅いでやんす。で、「バッチ更新はストアドで書き直したらどうですか？」って
｜上司に言ったわけです。勇気をふりしぼって。
インデックス…問い合わせ効率を向上させるためのもの（ツメ見出し）
ストアド…SQL文をプリコンパイル済みにして通常のSQLが問い合わせ前に行う
プリコンパイル作業等に掛かる時間的ロスを軽減する
でなかったか？
バッチ処理するのにインデックスあったら効率悪いので
インデックスをdrop
↓
バッチ
↓
インデックスを(再びCreate)
↓
（シェアードテーブル化できないならSELECT文でキャッシュに）
だろう…
もっと詳しい人どうぞ。（ｗ 文面から察するに、SELECTして加工してUPDATEを繰り返してるんでしょ。
加工する内容次第だけど、インデックスよりはストアドじゃないかな。
でも、何もいじらずサーバのメモリ追加した方が楽だったり。 クエリ単体で50ms以下で遅いってことは、
無駄にSQL何回も発行してるのが原因なので
ストアドとかインデックスより、まず処理を見直すべき。
単純なＳＱＬをそのままストアド化しても意味無いよ。
あとインデックスはストアドに対しても有効だよ。
ストアドの実行計画みたことある？ （DB使うのにVB使うのやめれ）
＆
（今の時代アプリにオプソでも良いからDB必ず使え）
∴VB捨てれ
話はそれからだ また、VB も使えない厨が来たのか ?
まず、「（DB使うのにVB使うのやめれ） 」の具体的理由を書いてみそ。 ストアドよりインデックスのほうがてっとり早いのは常識。
議論の余地なし。 VBアプリでメモリ多く使うと落ちる。
画面のコンポーネントべたべた貼る程度でｷｮﾄﾞる。 まとめて大量のレコードを更新するような処理はテーブルロックがかけられるなら
いいのですが、通常運用中に実行しなければいけないときはどうしてますか？
where無しなどの大域処理をしてしまうと１命令を１トランザクションで実行しよう
とするから、ロックは広い範囲にかかりまくるし、オラクルだとロールバックセ
グメントに書き出しまくる。そのせいか処理が妙に重たい。
ストアドでカーソル使ってwhere current ofで処理しても、ループで内でupdateや
insert命令を実行してもロックやRBSがらみのリソースを消費してる感じです。
仕方がないのでクライアント側に一旦対象のレコードのキーをすべて書き出して、
それをキーにして数十件ずつコミットしながら更新かけてゆく方法をとったら
俄然処理が速くなりました。
こういうケースでは一般的にはどうするのがいいのでしょうか？ ＞仕方がないのでクライアント側に一旦対象のレコードのキーをすべて書き出して、
これをDB内で済ませろ >29
プリコンパイル(静的SQL)とストアドプロシジャは全く別のものだよ。 >>38
tempテーブルが使えるならそうするんだけど残念ながらOracle8なので使えません。
ログ運用してるんで通常テーブルをワークには使いたくないのです。
>>39
別の概念ではあるがプリコンパイルされないストアドって見たことはないですね。 コンパイルといっても構文解析フェーズを済ましておく程度だけどね。
最初の実行時にコンパイルするタイプのを見かけますな。
>>37 はストアドが必ずしも役に立つわけでない例を挙げてみてるんだろうな。
OracleのPL/SQLだと普通の手続き型言語に似てるからとっつきは良いけど
使い方は要注意だ。非効率な変な書き方もできてしまうからな。 >>36
OS かお前のマシンがしょぼいんじゃねーか ?
あるいは、バグバグしてるコンポーネント使いまくりとかな。 そもそもバッチ更新なのにコンポーネントは全く関係なし。
アプリに負担をかけることすら間違い。
それとクライアントに一端処理を移すとのことだけれども
ストアドやインデックス云々より、DBの構造を見直した
方が早いよ。 ストアドよりインデックスのほうがてっとり早いのは常識。
議論の余地なし。
ボトルネックを調べてみるのにまず手っ取り早い索引から調べるというのは
同意だが、実際の対策としてストアドとインデックスを比べるのは意味はない。
まったく別物だからなぁ。
要領を得ないことをいう部下を信用しないのは上司の基本だと思うな（笑） >>1を叩くのは2ﾁｬﾝﾈﾗの基本だと思うな（笑） ←笑って付けるだけでキモヲタ風味になる。 >>46-47
ｵﾏｲﾗ、論点がずれてる。
>>48
正解
>>1の場合であればストアドのようなサーバサイドの処理にした方がパフォーマンスが上がると思う。
さらに、可能であれば、『UPDATE ･･･ SELECT』 文にした方がベターだな
>>51
論点がずれてる。
上司が言ったのは、すばやく目標を達成するにはって話だ。
よって、インデックスで良いんだよ。
それを>>1が高速化技法の話に摩り替えた。
よく読め。 >>52
>よく読め。
>>1
>「いまでも主キー指定での取得になっていて…」
莫迦麦価 >>53
お前こそよく読め。
>「いまでも主キー指定での取得になっていて…」
何で主キー指定して取得してるのにストアドなんだよ？
意味無いだろ。
その点を上司がたしなめたんだろ。
きちんとインデックス張ってまともなクエリ書けと言う意味だろ。
お前はストアドなどとの給う前にやることがあるだろ？と言われたわけだ。 なんつーか、やれやれですな。
>>54
>何で主キー指定して取得してるのにストアドなんだよ？
>意味無いだろ。
ストアドプロシジャの利点は、RDB サーバの _プロセス内で
処理が閉じている_ 点にある。その為、>>1 の指摘する
>C/S 間のピンポン多発で非常に遅いでやんす。
が解消される事が期待できる。
一方、主キーには _既にインデックスは作成されている為_、
二重にインデックスを張る行為には _全く意味がない_。 >>55
同意。やれやれだよ。
>>54あたり本気なのかネタなのかすら判別がつかん。
何でこんな基礎的な話で議論になるのか…。
主キー指定して取得するからピンポンが発生するんだろ。
なぜ、主キー指定して取得してるのに、ピンポンを発生させているのか考えれば、
わかる話だろう。
まともなSQL書けばすむ話だ。
ストアド以前の話だな。
よってインデックスが正しい。 >>57
( ﾟДﾟ)ﾎﾟｶｰﾝ
考えれば分かる話だろう。
じゃなくて、そこんとこ詳細に説明してみ。
どんな珍説なのか是非聞いてみたい。 「>>57 の考え、休むに似たり」
>よってインデックスが正しい。
>>55
>二重にインデックスを張る行為には _全く意味がない_。 >>61
m9（＾Д＾）ﾌﾟｷﾞｬｰ ぜんぜん意味わかってねー。 ＞いまでも主キー指定での取得になっていて…
これと似た台詞を聞いたことがあるけど、念のため調べてみたら
primary key (項目A, 項目B)の構成のテーブルで
項目Bだけで検索してたというのがあったよ。
大昔のRDBのなかには
a) where 項目A = ? and 項目B = ?
b) where 項目B = ? and 項目A = ?
で索引を使ったり使わなかったりしたのもあったけど最近のは大丈夫ですよね？ >>57
想像するに…
・一行ずつ取得ではなく、複数行持ってきてUPDATEはループで回せ。
・UPDATE一発でやれ
のどちらかを言いたいのだと思うけど、それじゃ出来ない処理なんて
いくらでもある。そう言うときの為にストアドがある。
そもそも
「ストアドが存在するDBMSにもかかわらずクライアントでバッチ更新」
なんて仕様が出てくる時点で間違い。
>>63
> 最近のは大丈夫ですよね？
そうでもないよ。 >>64
物事には順序がある。
一行ずつ取得してる新人に、いきなりストアドでやれとは言わない。
ストアドなどという前にやることがあるだろう。 >>65
VBでバッチ処理が書けてストアドだと書けないなんて事があるか
どう考えてもストアドの方が簡単だろう。
単なる怠慢。 ストアドでバッチ処理を書き直したまではいいのだけれど、
数件おきにコミットさせるとカーソルがクローズしてエラーになってしまう。
１件分の処理の間に子レコードの処理も入るのでトランザクションは使いた
いのだが全部処理するには総数が大きい。さてどうするべ、週末なのに・・・ >>67
Oracle で、FOR UPDATE 付きの問い合わせをしてるなら
それは仕様。ROWID 使え。
Oracle じゃないなら知らん。
つか、ｽﾚ違い。 >>67
コミット後にカーソルをオープンしたままにする方法はないの?
大抵のDBMSならできるはずだけど。 >>57でキーボードに茶を吹いたよ。 どうしてくれる。
>>64はきっと釈迦のような慈悲の心を持っているんだろうな。 >>70
DB2とかのやり方をまねしちゃだめ。
カーソルループ中にCOMMITする発想はあんましよくない。
途中でこけたら元に戻せなくなる。
そういう場合はロールバックセグメントを大きくとっておくのがOracleのやりかた。
>>74
そうか？ケースバイケースだろ。
カーソルループの中で一部のデータのみコミットされると整合性がとれ
なくなるなケースはおっしゃる通りだが。
カーソルループの中で一部のデータのみコミットされても整合性がとれ
るケースだってないか。
その場合は、カーソルループの中でコミットしたほうがロックの期間
が短くなるし、いいと思うけど。
ロックの期間を短くしたほうがいいっていうのは、どんなDBでも同じ
じゃねーか。 >>77
カーソルループでの更新が途中でこけると、どこまでやったかがわかんないから最初からやり直すことになると思うけど。
このとき、途中までCOMMITしてたらそこまでの更新をもう1回やることになる。
それでも整合性がとれるようなケースってあんましなさそうな気がするけど...
>>78
その通り。
>>77のケースはやろうとすれば出来るだろうけど、
管理が非常に難しくなるし、
どこまでコミットしたかの情報も一々記録しないといけないからパフォーマンスも悪くなる。
そのあたり、セーブポイントでどうにかできないのでしょうか。 そもそもセーブポイントって、どういうものか理解しているのか？
>>78,79
カーソルループの中で整合性が取れるケースって、珍しくはないよ。
いくつか思いつくけどね。
例えば、受注テーブルを基に、物流システムへ渡す出荷指示データ
を作成するバッチ処理とか。
受注テーブルの出荷指示フラグと出荷日を基にカーソルループでまわす
場合。で、ループの中では、受注テーブルの出荷指示フラグを更新し、在庫
テーブル更新、出荷指示テーブル作成とかやってる場合、処理する受注伝票
単位で整合性が取れてれば問題ないというケース。
>管理が非常に難しくなるし、
どこまでコミットしたかの情報も一々記録しないといけないからパフォーマンスも悪くなる。
正直、意味が良くわからん。多分、管理が非常にむずかしくなるってのは、
どこまでコミットしたかを把握したいという意味なんだろうけど。
すでにコミットしたデータは、整合性が取れてるわけだから、基本的には気に
する必要はない。プログラムの不具合で、コミットしたデータの信頼性が損なわれている
場合でも、テーブルに更新時のタイムスタンプと最終更新PGMのIDでも持たせて
おけば、調査できるだろ。
基本的にはバグなんだから、それよりロックの期間が長くなるというデメリット
のほうが俺はいやだね。
>>82
彼らの言っているのは
> ループの中では、受注テーブルの出荷指示フラグを更新し、在庫
> テーブル更新、出荷指示テーブル作成とかやってる場合
この「ループの中」の途中でコミットしてしまうと言うケースを想定して
話をしているんだよ。
「カーソルループ」と言う言葉に捕らわれすぎで話の本質が分かってない。 >>83
そうなのか？だとすると確かにレアケースだが。
67の質問ってそういう意味じゃねーと思うがな。実際、DB2,MSSQL,
Oracleもデフォルトじゃコミットしたら、カーソルクローズしちゃう
しな。(SQL92の仕様だからだろうけど。）
69の回答も俺とおんなじ理解だろ。
話の本質が分かってないのは、お前のほうじゃねーかって気がするがな。 >>84
67に対しては69でFA出てる。
そこから先の話はトランザクション内でのコミットの是非についてだろ。 >>85
>そこから先の話はトランザクション内でのコミットの是非についてだろ。
そんなのまずいに決まってんじゃん。トランザクションの1つの要件は、
整合性を確保できる最小単位であることだ。（原子性、一貫性）
俺が77で言っているのは、カーソルループ1回単位が１トランザクション
の場合と、カーソルループ全体が１トランザクションの場合の話。
>>67に対しては70でFA出てる
やっぱり話の本質が分かってないのは、お前のほうだと思うがな。俺は、
70に対する返答(74)に対して、77で返答してんだから。
どこから、トランザクション内でのコミットの是非についてになったん
だ。 >>87
言ってる意味がさっぱりわからん
とりあえず落ち着け >>88
二段落目読んでも解らないとなるとヤバイ。 そもそも同列に語ることがおかしいってスレでいいんだよな。
・ストアド化による性能向上
ミドルウェア及び通信等のコスト減を目的
・インデックスをきちんとすること
データに対するアクセス経路の最適化を目的 >>90
>>67 以降、違う話に花が咲いています。 >>90
>>91の言うように、話題が変わってます。
カーソルループで大量更新をする場合の話。
>>87,88
想定している状況がそれぞれ違ってるみたいだから
ちょっとこじれかけてるけど、めずらしくまともな議論
に育ちそうだからマターリいこーぜー。
すごい遅レスだが。
>そんなのまずいに決まってんじゃん。トランザクションの1つの要件は、
>整合性を確保できる最小単位であることだ。（原子性、一貫性）
これは、トランザクションは整合性を確保する最小単位だから、
トランザクション内部でのコミットは有り得ないということが
言いたかった。
OracleのSPはネーティブコードではなくインタプリタのようです、
ＤＢの問い合わせではなくロジックをしこたま実行するプログラムを作ったの
ですが予想の百倍ぐらい時間がかかりました。
SPそれ自身の実行速度はVBとたいして変わらない印象です、
サーバに中途半端なCPUを使うとPCでVBのほうが早い可能性も
ありです。 >>94
たいていの処理系ではStored ProcedureはP-Codeのような中間言語方式だから
Oracleもそうじゃないかな。一般的にサーバーサイドでCPUを多く使う処理は
避けたほうがいいから問題ないように思う。複雑な処理をしたいならOracle内臓の
JServer VMでJava stored procedureを使うという手もある。こちらはJITでコンパ
イルされるから２回目以降の処理は速い。 >>94
>OracleのSPはネーティブコードではなくインタプリタのようです
んな事ぁちょっと考えれば解（ｒｙ >>94-96
PL/SQLはネイティブコンパイルもできる >>97
そういえばそんなのがありましたね。Cコンパイラが別に必要だったり、
設定がめんどかったり、SQLなどのDBアクセス部分には効果がなかったり
で結局使いませんでした。
＞ＤＢの問い合わせではなくロジックをしこたま実行するプログラムを作ったの
こういうのには効果がありそうです。 ここが一番ヘビーユーザーが多いみたいだね
教えて欲しいのだが、行レベルロックに対応しているDBはオラクル
以外にありますか？ 
