Oracle выбирает sequence.nextval из двух звуков слишком медленно - PullRequest
Новая
       61

Oracle выбирает sequence.nextval из двух звуков слишком медленно

0 голосов
/ 06 января 2019

Некоторое время назад у меня была проблема с производительностью базы данных для вставки / обновления нескольких миллионов записей с использованием jdbc. Для повышения производительности я изменил код на batch. Тогда я решил контролировать код, используя jprofiler, чтобы узнать, насколько сильно увеличивается производительность ... но в то же время, мониторинг обнаружил странную вещь!

enter image description here

Как вы можете видеть на скриншоте выше, генерация нового идентификатора из последовательности очень медленная. Снимок экрана настолько нагляден, что я должен сказать, что вторая строка - это запрос inner join к таблице с ~ 8 миллионами записей с самим собой и некоторыми вычислениями (сравните его время со временем третьего запроса!).

Я спросил эту проблему у нашего dba, и он сказал что-то о рекомендации оракула для последовательностей кэширования, но когда я проверил последовательность, я увидел, что она уже кэширована. 

CREATE SEQUENCE  "XXXXXXXXXXXX_ID_SEQ"  MINVALUE 1 MAXVALUE 9999999999999999999999999999 INCREMENT BY 1 START WITH 1 CACHE 20 NOORDER  NOCYCLE;

Есть мысли?

p.s. Я думаю, что Hibenate использует последовательности для вставки записей аналогичным образом, и на самом деле я ищу лучшие практики для использования последовательностей для повышения производительности нашего проекта, использующего спящий режим. Вышеуказанная задача jdbc завершена.

1 Ответ

0 голосов
/ 07 января 2019

Как предлагается в комментариях других - это не генерация чисел, которая требует времени. Рассмотрим приведенный ниже пример, который исключает задержку сети и сети из затрат времени. 

SQL>  create sequence tst_seq start with 1 increment by 1; 

Sequence created.

SQL> set timing on
SQL> declare
  seqNo number(38,0); 
begin
  loop 
    select tst_seq.nextval into seqNo from dual; 
    exit when seqNo>=100000; 
  end loop; 
end;   2    3    4    5    6    7    8  
  9  /

PL/SQL procedure successfully completed.

Elapsed: 00:00:05.86

без кэширования требуется 5,86 секунды для генерации 100 000 номеров. если вы воспроизведете тест, описанный выше, вы получите краткую оценку того, чего вы можете достичь, если вы измените свою реализацию, чтобы исключить дополнительный круговой переход для порядковых номеров

...