Бодрого всем!
Oracle 12.1, есть фактовая таблица:





логика заполнения:
RUN_ID - монотонно возрастающее число, идентифицирующее набор строк
CREATE_TS - монотонно возрастающее дата/время
удалений/правок в таблице нет

расчетное наполнение - 2,5 млрд строк в год,
ILM - 3 года хранения, т.е. пик наполнения ожидается на уровне 7,5 млрд строк

Для эффективного отбора из нее (чтобы сработал partition pruning по обоим уровням) необходимо в запросе указывать условия на оба поля - "CREATE_TS" и "RUN_ID"

При этом уже существуют запросы, отбирающие только по "RUN_ID",
план в этом случае выглядит как



- т.е. просматривается 1024К-2 субпартиций RUN_ID партиций ("CREATE_TS"), в которых в принципе искомого RUN_ID нет

вопрос: можно ли как-то ускорить эти запросы (в 1024К раз) без переписывания?

Спасибо!

поправка - ускорить не в 1024К раз, а всего в 365*3 - 1 раз (столько лишних партиций накопится за 3 года)

Спасибо!
Была надежда на что-то типа Zone Maps ... но:

https://docs.oracle.com/database/121/DBLIC/editions.htm#DBLIC109
Zone Maps - Requires the Partitioning option, and Exadata or Supercluster


про селективность:
RUN_ID - монотонно возрастающее число, идентифицирующее набор строк (в общем случае от 1000 строк до разумной бесконечности на один конкретный RUN_ID)

дополнительное условие по теме можно ли как-то ускорить эти запросы (в 1024К раз) без переписывания:
если известно, что
а) таблица всегда только дописывается, т.е. в старых партициях CREATE_TS не появляются новые run_id
б) под конкретным техн.юзером use case этой таблицы выглядит так:

1) заполнить, вставив набор строк с:
- конкретным run_id
- CREATE_TS, равным CURRENT_TIMESTAMP

2) прочитать (для сбора итогов или иных целей) "только что вставленное" на шаге 1, при этом:
- run_id известен и фильтруется (сейчас так работает тех.запрос)
- CREATE_TS не фильтруется и не известен тех.запросу, но его можно указать не точный, а на сутки назад от CURRENT_TIMESTAMP , т.к. это все равно решит задачу отсечения лишних 365*3 партиций

в этом use case применимым выглядит подклеивание к запросам этого юзера к этой таблице условия во where:
CREATE_TS > systimestamp - 1

сделать это можно, например, навесив vpd policy
https://docs.oracle.com/cd/B28359_01/network.111/b28531/vpd.htm#DBSEG98215
Essentially, Oracle Virtual Private Database adds a dynamic WHERE clause to a SQL statement that is issued against the table, view, or synonym to which an Oracle Virtual Private Database security policy was applied.

конечно, это нецелевое ее использование, но - рабочий вариант?

andrey_anonymous,

есть adhoc-запросы по таблице, которые отбирают как раз по create_ts, поэтому не хочется...

xtender,

table expansion - хороший вариант, но не в нашем случае - читаем записанное почти сразу, см use case выше

xtender,
>проще и правильнее было бы воспользоваться interval-reference partitioning

возможно, но:
1) хочется обойтись без изменения таблиц и запросов
2) interval-reference partitioning требует явного неdisabled FK-ключа, на таких объемах очень не хочется...

xtenderAlexus12xtender,

table expansion - хороший вариант, но не в нашем случае - читаем записанное почти сразу, см use case вышену и что? оверхед-то будет меньше чем в секунду ~1000 логических чтений корня индекса

да, в такой постановке 1000 логических чтений корня индекса лучше 1000 FTS

насколько это лучше/хуже моего варианта с vpd?