Есть большая таблица около 500 млн записей вида:

CREATE TABLE SEGMENTS
(LOAD_DTTM DATE, CD VARCHAR2(30 BYTE), AP NUMBER(18,3), CHAR_PARAM_1 VARCHAR2(200 CHAR), CHAR_PARAM_2 VARCHAR2(200 CHAR), CHAR_PARAM_3 VARCHAR2(200 CHAR), CHAR_PARAM_4 VARCHAR2(200 CHAR), CHAR_PARAM_5 VARCHAR2(200 CHAR), NUM_PARAM_1 NUMBER, NUM_PARAM_2 NUMBER, NUM_PARAM_3 NUMBER, NUM_PARAM_4 NUMBER, NUM_PARAM_5 NUMBER);

и индекс на ней
CREATE INDEX SEGMENTS$AP_CD ON SEGMENTS (AP, CD);

Независимые друг от друга процессы обновляют в течении дня данные в этой таблице. Обновление в рамках каждого процесса идет по одному CD. Обновление происходит в рамках одной транзакции: сначала идет DELETE FROM SEGMENTS WHERE CD='AAA' затем INSERT для CD='AAA' и потом COMMIT. Количество записей для одной транзакции (одного значения CD) разное и колеблется от сотен тысяч записей до десятков миллионов. В один момент времени может работать несколько процедур обновления по разным значениям CD.

К таблице идут постоянные запросы со стороны приложения по связкам CD+AP или просто по AP, до сотен в секунду, т.е. таблица должна быть всегда доступна. За одни сутки в целом обновляются все записи в таблице.

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

Есть мысль сделать партиционирование по CD и в рамках обновления работать только с конкретной партицией, но возникает вопрос доступности данных, если делать truncate partition то пока не пройдет insert фактически приложение не сможет работать с этим куском данных и непонятно как быть с индексом...

Кроме обновления существующих данных, возможно появление новых пачек записей с новым CD.

ORACLE 12c, какие есть гениальные мысли? :-)

не подходит, данные меняются

обновляются в смысле меняются связки AP в привязке к CD, сохраняются/добавляются/удаляются AP

а чем update будет быстрее идти? и табличке обращение идет 24х7 за чтением данных

спасибо, покурим эту тему)

единственно, merge не удалит ненужные записи, которых нет во временной табличке, но есть в исходной, а это нужно

непредсказуемо, постоянно появляются новые CD, в целом AP уникальных около 100 млн, AP меняются между CD и могут входить в несколько CD

сейчас уникальных CD около 100

ок, хорошая мысль, CD нет станет миллион, от силы сотни

В данной ситуации в приложении, которое читает данные придётся каждый раз генерировать динамически запрос из нужной subpartition, возможность внесения изменений в код приложения, к сожалению, отсутствует, т.к. это вендорское решение.

Кроме того, от global index не получится скорее всего отказаться, т.к. часть запросов идёт просто по AP без конкретного CD по всей таблице целиком.