Оптимизация уровня доступа к данным

Question

У меня есть веб-сервис (JAX-RS / Spring), который генерирует SQL-запросы, которые работают с временной таблицей в Oracle.Затем данные архивируются в другую таблицу (через 3 оператора MERGE).Выполнение каждого «задания» (запрос и слияние) выполняется в фоновом режиме через JMS-брокер (ActiveMQ).Последовательность операций каждого задания выглядит примерно так:

   insert/update into table Q (select from table F) -- done between 4 and 20 times
   merge into table P (select from table Q)  -- twice
   merge into table P (select from table F)
   merge into table P (select from table F)
   create a view V as select from table P

(таблица Q является временной таблицей).

Когда я отправляю два или три задания, подобные этим, это занимает около7 минут для каждой работы.Но когда я отправляю до 15 бегущих одновременно, продолжительность растягивается намного дольше.

происходит ли это потому, что все эти процессы пытаются вставить / обновить в временную таблицу Q?таким образом боретесь за ресурс?Какие методы я должен смотреть, чтобы оптимизировать это?Например, я подумал о создании 5 или 6 дубликатов таблицы Q и «балансировке нагрузки», к которым объект доступа к данным запрашивает их.

Спасибо

Answer 1

Когда я отправляю две или три работы, такие как что это занимает около 6-7 минут каждая работа для выполнения. Но когда я отправка до 15 работающих одновременно время, продолжительность растягивается больше.

Существует множество ресурсов, за которые могут бороться ваши процессы, а не только временная таблица.

Для начала, сколько процессоров (процессоров / ядер) имеет ваша база данных? Существует довольно хорошее практическое правило, согласно которому мы не должны запускать более 1,8 фоновых заданий на процессор. Поэтому нет смысла беспокоиться о клонировании вашей временной таблицы, если у вас недостаточно процессоров для поддержки высокой степени параллелизма.

Ключевая вещь с настройкой: не угадай . В отличие от некоторых других продуктов СУБД, у Oracle есть много инструментов, которые мы можем использовать, чтобы точно определить, куда уходит время. Это называется интерфейсом ожидания. Это не идеально, но это намного лучше, чем слепая перестройка схем вашей базы данных. Узнайте больше.

Answer 2

Если Q действительно является временной таблицей (как в GLOBAL TEMPORARY TABLE), то каждый сеанс будет иметь отдельный физический объект, поэтому они не будут бороться за блокировки или на уровне данных.

более вероятно, что возникнет конфликт между постоянной таблицей P или ресурсами сервера (память и диск).