2016-08-19 17 views
5

私はSHA512アルゴリズムを使用してハッシュしようとしているプレーンテキストのすべてのユーザーパスワードを持つ100万行を超えるユーザーテーブル(Oracle 11g DB) (ハッシュと塩)。私のJavaクラスは、ユーザーテーブルからすべてのレコードを読み取り、ハッシュしてユーザーテーブルに更新することから始まります。私は準備された文が、私は自動に設定している JDBCを使用してOracleの100万行を選択して更新するパフォーマンスが低い

  • setFetchSize(1000))は
  • プロパティをfalseにコミット1000にフェッチサイズを設定している
    • 私はを選択 の両方のために準備されたステートメントを使用しています
    • UPDATEは照会します一括更新を行うにはバッチ法を使用して
    try { 
        ps = con.prepareStatement("update user set password=? where ID=?"); 
        psSel = con.prepareStatement("select ID, password from user"); 
        psSel.setFetchSize(1000); 
        rs = psSel.executeQuery(); 
        String hashPassword = null; 
        while (rs.next()) { 
         long id = rs.getLong(1); 
         String pwd = rs.getString(2); 
         hashPassword = <<CALL TO PASSWORD HASHING UTIL>>; 
         ps.setString(1, hashPassword); 
         ps.setLong(2, id); 
         ps.addBatch(); 
    
         //Every 5000 records update and commit 
         if(++count % batchSize == 0) { 
          ps.executeBatch(); 
          con.commit(); 
         } 
    
        } 
        ps.executeBatch(); 
        con.commit(); 
    } catch (SQLException e) { 
        e.printStackTrace(); 
    } 
    

    100,000レコードを更新するには、上記の方法は8分近くかかると私はかなり高いと感じています。使用

    データベース: Oracle 11gの

    Javaバージョン: 1.6

    環境:のWindows 7

    私は私が何かをしないのですかどうかわからないです。そのようなバルク負荷を処理するための最善の方法をアドバイスまたは推奨できますか?

    UPDATE

    私は、一時テーブルにおける第二を見ていた - USER私は前に作成され、ID欄に追加何主キー制約はありませんでした見ることができました。私は先に進み、IDカラムのPK制約を追加し、私のユーティリティを再実行しました。今度は36秒を処理して100000行と処理しました。

    私もUSER_TMP2がPK制約なしに別の一時テーブルを作成し、私のユーティリティを実行し、それがユーザーテーブルのビューを作成し、フェッチ10万

  • +3

    8分**ハッシュ** DB 100万レコードの更新が高く見えない –

    +7

    データベース側でハッシュ関数をレプリケートできますか?もしそうならば、Javaとの間でネットワーク上のすべてのデータを移動する必要はありません。ここでボトルネックがどこにあるのかははっきりしない。 –

    +1

    'DBMS_CRYPTO'で' HASH_SH512'を使わないのはなぜですか? – ppeterka

    答えて

    -1

    ため8分いつものようにを取った二重確認しますそのテーブルのデータこれにより、クエリの実行時間が最適化されます。あなたの場合に役立つかもしれません。

    +0

    ビューを作成することによってクエリの実行が最適化されることはありません –

    1

    私は前に作成した一時テーブルをもう一度見て、IDカラムにプライマリキーの制約が追加されていないことが分かりました。私は先に進み、IDカラムのPK制約を追加し、私のユーティリティを再実行しました。これで、100,000行を処理するのに36秒かかりました。

    私もPK制約なしに別の一時テーブルのUSER_TMP2を作成し、私のユーティリティを実行し、それが物語10万

    道徳のためにいつものように8分を取ってください2倍にするには、次のまず最初に、パフォーマンスの低下を調べるときを実行するには、簡単な検査か、クエリー–の実行計画を見て不要なテーブルスキャンを大量に実行していないことを確認することによって、関連するテーブルの索引付け–を調べます。

    関連する問題