Здравствуйте!

Нужны свежие стратегические идеи для ускорения процесса) Условие задачи
Есть широкая таблица (~80 колонок) все колонки это либо varchar2 либо number, либо date. Работа всегда идёт по месячной партиции, около 10М строк, есть ПК.
Пользователь пишет условие(идентифицируется ID_УСЛОВИЯ) вида (COL1 >50 and COL2 LIKE '%ZZZ%') or (COL3 BETWEEN TO_DATE('01.07.2017') AND TO_DATE( '15.07.2017' ) . Количество таких последовательных условий может быть технически любым, на практике, обычно, 4-5.
Каждая строка в исходной таблице может соответствовать любому количеству пользовательских условий от 0 до N.
Соответственно, задача - разметить каким-то образом строки исходной таблицы, сложив в другую таблицу данные как (PK,ID_УСЛОВИЯ).

Сейчас количество уникальных ID_УСЛОВИЯ для прохода равно ~100. Добавились условия вида (COL4 IN (SELECT VAL FROM LOOKUPS WHERE lookup_id =12345))
Испробовано 1) отдельные запросы для каждого условия, выполняется 2.5 часа
2) Один огромный кейс(не влезает в varchar2(32000)) выполняется 1.5 часа.
Очень хочется утоптать всё это хотя бы в час. База Oracle 11g.

Буду очень благодарен за любые идеи.

Спасибо за ответ!

10М записей в одном partition? А сколько их всего? Другими словами данные за какой период хранятся в таблице?
Всё верно, 10М в одной партиции. сейчас хранятся данные за полтора года, со временем вырастет до трех лет.

Запросы динамические или параметры передаются в хранимые процедуры, выполняющие запрос?
Запросы динамические,при чём есть грех пренебрежения бинд-переменными, не смог придумать как можно такое собрать на процедурах)


Есть ли соответствующие запросам индексы? Индексы локальные или глобальные?
Запросы динамические, соответственно индексы тоже придется создавать каждый раз под конкретный набор условий. Думал эту мысль, но не попробовал. Стоит испытать? Сейчас есть только уникальный индекс на одно поле, два индекса для других запросов на определённые поля с айдюками и индекс на поле с датой по которой идет партиционирование (partition by range DATE interval MONTH). Индексы все локальные.


Когда собиралась статистика по partitions и в целом по таблице? Имеются ли гистограммы?
Статистику собираем каждую ночь после заливки в таблицу актуальных данных. Открыл для себя гистограммы, буду думать. Их, получается, имеет смысл делать на числовых колонках, где часто возникают условия <>?

Есть ли процесс, удаляющий старые данные? Каким именно образом удаляются данные?
Сейчас при обновлении(данные вытягиваются через dblink из другой базы) делается drop partiton for (MONTH_DATE)

Последнее время явно добавляю ко всем запросам select * from t partition for (to_date('01.07.2018'))

Сейчас, судя по собранной глазами статистике, сильнее всего производительность угнетают условия типа (COL4 IN (SELECT VAL FROM LOOKUPS WHERE lookup_id =12345)). При этом табличка lookups перед запуском наполняется только релевантными данными, там ничего лишнего, около 2000 строк всего. В ней есть, соответственно, индекс на lookup_id и val, в плане стоит index_join.