ПОСЛЕДОВАТЕЛЬНОСТЬ Oracle - «увеличение на» и «кэш»
Я использую JPA вместе с спящим режимом для моего загрузочного приложения Spring. Я сталкиваюсь с некоторыми проблемами производительности вставки при массовом выполнении. На данный момент найдены следующие исправления:
- Измените последовательность Oracle, обновите «
Increment by> 1, я даю 50». - В объекте Java используйте
allocationSizeдля того же значения, что и OracleIncrement By
Так что JPA не позволяет вызову получить следующую последовательность.
Моя последовательность определяется как:
CREATE SEQUENCE MYSCM.BOOKING_SCHED_SEQ INCREMENT BY 1 MAXVALUE 9999999999999999999999999999 MINVALUE 1 CACHE 20
Когда я увеличиваю INCREMENT BY до 50, должен ли кеш увеличиваться до 50 или уменьшаться?
Ответы 1
When I increase the INCREMENT BY to 50 should the cache be increased to 50 or reduce?
Ни один. Между INCREMENT BY и CACHE нет никакой связи.
INCREMENT BY управляет монотонностью последовательности. С УВЕЛИЧЕНИЕМ НА 50 серия идет 1, 51, 101, 151 и так далее.
КЭШ определяет, сколько порядковых номеров хранится в памяти для обслуживания запросов NEXTVAL. Чем меньше число CACHE, тем чаще базе данных приходится читать из своих внутренних таблиц, чтобы получить следующий диапазон распределения. Таким образом, в умеренно загруженной системе мы хотели бы свести к минимуму количество получаемых защелок, поэтому мы устанавливаем CACHE на большое число, скажем, 1000.
Люди одержимы установкой значения CACHE, потому что они думают, что если оно слишком велико, они могут «потерять» некоторые значения и получить пробелы в своих рядах. Это крайне маловероятно, и даже если это произойдет, нас это не должно волновать. Последовательности являются источником гарантированных уникальных значений и не имеют дальнейшего значения.
Хотя, перечитав ваш вопрос, я не думаю, что это как-то повлияет на производительность ваших объемных вставок. Почему вы решили сосредоточиться на распределении последовательности? Запускали ли вы какую-либо трассировку, чтобы обнаружить узкое место? Вы говорили со своим администратором баз данных?
Какую версию Oracle вы используете?
Я использую 12C версии 2
Опубликуйте фрагмент вашего кода вставки. Скорее всего, то, что вы называете объемная вставка, вовсе не является масса. Я подозреваю, что вы делаете один оператор выбора и один оператор вставки для каждой строки. Решение не является для ограничения состоит в том, чтобы выбрать один для 50 строк. Вам нужно будет активировать по крайней мере JDBC пакетная вставка под прикрытием, чтобы включить вставку нескольких строк за один цикл.
Я согласен с @marmitebomber. Это не проблема Oracle и уж точно не проблема Oracle Sequence. В вашей конфигурации JPA/Hibernate/Spring Boot есть что-то неправильное, из-за чего ваше приложение выполняет массовые вставки неоптимальным образом.
@MarmiteBomber да, ты прав. Его спящий режим делает плохие вещи. Я уменьшил это до уровня, увеличив приращение последовательности до 50 и выделение последовательности jpa до 50. Hibernate заполнит последовательность до 50 и вызовет следующую последовательность только после того, как 50 будут исчерпаны.
@APC кеш для sequence.nextval находится на самом сервере базы данных, верно? Не на стороне спящего режима?
@AlexandarPetrov - да, база данных кэширует последовательность
да. Массовая вставка вызывает тайм-аут из-за запроса
sequence.nextval, выдаваемого для каждой записи. Я включил пакетные вставки, которые помогли улучшить производительность, но это проблема.