上智大学のG-SPLASH

コメント

コメントを投稿

このブログの人気の投稿

ResultSet.next()の高速化

defaultRowPrefetch?のサイズを変更することにより、格段にパフォーマンスが上がるそうです。大量のデータをDBから取得する際に有効と思われます。 以下原文 以下の記述でみごと解決致しました。 java.util.Properties info = new java.util.Properties(); info.put("user", "scott"); info.put("password", "tiger"); info.put("defaultRowPrefetch", "100"); Connection conn=DriverManager.getConnection("jdbc:oracle:thin:@ホスト名:1521:テーブル名", info); プリフェッチのサイズはDefaultで10だそうで、 とりあえず100にしただけで、1万件あたり約3.5分が わずか3秒になってしまいました。 本当にどうもありがとうございました。
Read more »

雁尾千恵（３７）

イメージ
雁尾千恵（３７）が自殺したかどうかは知らんよ。 てか、雁尾千恵ってどんな人かも知らん。 前々から気になってたんだけど、これって本当？ヤラセ？ 本当にいるの？てか、実名入りで全国区で放送って、大分勇気いるよね？ コラージュ？
Read more »

Pro*c的にはUPDATEとかDELETE0件はエラー

Pro*C的には（というか、Oracle的？）には0件DELETEやUPDATEはOracleエラーだそうです。 「ora-1403」が返ってきてアプリ落ちました。 んで、DELETEとUPDATEのエラーハンドリングで1403を捕まえて無視するように修正予定。 てか、JDBCだと落ちなかった気がするけど、きっとJDBCが無視してくれてるんだよね、と信じてます。 > 1403は正の値なので例外にはなりませんね。例外は負の値の場合です。 Pro*C的には正の値こそが例外なんですよ。そして、負の値はエラー。 > 確実なのは件数取得でしょうかね。 これは好きな方法ではありません。 SELECT count(*)実行後、INSERTを実行するまでのわずかなタイミングで、他のトランザクションに先を越される可能性がゼロではないですから。そうすると、結局INSERTでORA-1が発生する可能性を考慮しなくてはならず、そんだったら最初っから何も考えずにINSERTすればいいじゃん、となります。 また、件数で判定するとしたら、SELECT count(*)などせずに、まずUPDATEを実行し、その更新レコード数を取得するほうが、手順が少なく済む＝割り込まれる可能性が低くなります。 なので、自分的にはINSERT→UPDATEか、UPDATE→INSERTのどちらかなのですが、どっちを選ぶかは「INSERTとUPDATEのどちらが成功する可能性が高いか」で決めます。これは業務に依存するはなしです。
Read more »