Słaba wydajność SELECT i aktualizacji miliona wierszy w Oracle za pośrednictwem JDBC

Question

Mam tabelę użytkownika (Oracle 11g DB) z ponad 1 milionem wierszy, który ma wszystkie hasła użytkownika w postaci zwykłego tekstu, który próbuję za pomocą algorytmu SHA512 hash (hash i sól). Na początek moja klasa Java czyta wszystkie rekordy z tabeli użytkowników, miesza i aktualizuje z powrotem do tabeli użytkownika.

• używam przygotowaną instrukcję dla obu SELECT i UPDATE odpytuje
• Mam ustawiony przygotowana instrukcja pobrać wielkości do 1000 (setFetchSize(1000))
• mam ustawić auto popełnić właściwość false
• Stosując metodę wsadowy zrobić luzem Aktualizacja

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(); 
} 

Aby zaktualizować 100 000 rekordów, powyższa metoda zajmuje blisko 8 minut, co moim zdaniem jest dość wysokie.

Database używane: Oracle 11g

Java Wersja: 1,6

Środowisko: Windows 7

Nie jestem pewien, czy ja czegoś brakuje. Czy możesz doradzić lub polecić jakikolwiek najlepszy sposób na przetwarzanie takich ładunków masowych?

UPDATE

wziąłem drugą spojrzeć na tabeli temp - USER utworzonego wcześniej i widział nie było klucz podstawowy dodaje się do kolumny ID. Poszedłem do przodu i dodałem ograniczenie PK dla kolumny ID i ponownie uruchomiłem narzędzie. Teraz wystarczy 36 sekund, aby przetworzyć 100 000 wierszy.

Aby być podwójnie pewny, że również stworzył inną tabelę temp USER_TMP2 bez PK przymusu i prowadził moje narzędzia i zajęło 8 min jak zwykle dla

Answer 1

Zrób widok tabeli użytkownika i pobrać dane z tej tabeli. Pozwoli to zoptymalizować czas wykonania zapytania. To może być pomocne w twoim przypadku.

Answer 2

Wziąłem drugie spojrzenie w tabeli temp - INSTRUKCJA I stworzył przed i widział nie było Primary Key ograniczenie dodaje się do kolumny ID. Poszedłem do przodu i dodałem ograniczenie PK dla kolumny ID i ponownie uruchomiłem narzędzie. Przetworzenie 100 000 wierszy zajęło 36 sekund.

Aby być podwójnie pewny, że stworzył również inną USER_TMP2 tabeli temp bez PK przymusu i prowadził moje narzędzia i zajęło 8 minut, jak zwykle za 100,000

Morał z tej historii: Badając słabe wyniki jego pierwszą rzeczą do zrobienia jest zbadanie indeksowania tabel zaangażowanych – albo przez prosty przegląd lub patrząc na plany wykonania zapytań –, aby upewnić się, że nie robisz dużo niepotrzebnych skanów tabeli.