powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Oracle [игнор отключен] [закрыт для гостей] / partition pruning при условии только на subpartition
39 сообщений из 39, показаны все 2 страниц
partition pruning при условии только на subpartition
    #39591172
Alexus12
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Бодрого всем!
Oracle 12.1, есть фактовая таблица:

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
  CREATE TABLE LOG
   (          
                "RUN_ID" NUMBER(38,0) NOT NULL ENABLE, 
                "CREATE_TS" TIMESTAMP (0) DEFAULT CURRENT_TIMESTAMP(0) NOT NULL ENABLE, 
                куча прочих полей

   ) PCTFREE 0 PCTUSED 92 INITRANS 1 MAXTRANS 255 
  STORAGE(INITIAL 16384 NEXT 106496
)
  PARTITION BY RANGE ("CREATE_TS") INTERVAL (INTERVAL '1' DAY) 
  SUBPARTITION BY HASH ("RUN_ID") 
  SUBPARTITIONS 128




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

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

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

При этом уже существуют запросы, отбирающие только по "RUN_ID",
план в этом случае выглядит как
Код: plsql
1.
2.
partition range ALL - CREATE_TS
partition range SINGLE - RUN_ID



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

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

Спасибо!
...
Рейтинг: 0 / 0
partition pruning при условии только на subpartition
    #39591194
Alexus12
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
поправка - ускорить не в 1024К раз, а всего в 365*3 - 1 раз (столько лишних партиций накопится за 3 года)
...
Рейтинг: 0 / 0
partition pruning при условии только на subpartition
    #39591234
Alexus12,

Я правильно понял суть вопроса: нужно чтобы оракл отсек ненужные партиции и читал только одну нужную, и при этом в запросе не фильтровать по полю партиционирования, и не менять исходный запрос?

=)
...
Рейтинг: 0 / 0
partition pruning при условии только на subpartition
    #39591236
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Модератор форума
Alexus12
Код: plsql
1.
partition range SINGLE - RUN_ID

это и означает, что в секции просматривается только одна подсекция. Если было бы RUN_ID in (...), был бы PARTITION HASH INLIST , а полный - это PARTITION HASH ALL . Количество же просмотренных подсекций можно увидеть в STARTS.


Alexus12т.е. просматривается 1024К-2 субпартиций RUN_ID партиций ("CREATE_TS"), в которых в принципе искомого RUN_ID неткак такой вывод вообще был сделан? и считали-то как?
...
Рейтинг: 0 / 0
partition pruning при условии только на subpartition
    #39591239
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Модератор форума
Мимо крокодилAlexus12,

Я правильно понял суть вопроса: нужно чтобы оракл отсек ненужные партиции и читал только одну нужную, и при этом в запросе не фильтровать по полю партиционирования, и не менять исходный запрос?

=)ааа, вот теперь понял в чем вопрос


Alexus12,

Alexus12RUN_ID - монотонно возрастающее число, идентифицирующее набор строк

ораклу неоткуда брать информацию, в какой секции лежит какой диапазон RUN_ID (статистика не в счет, т.к. она ничего не гарантирует). В похожих случаях еще чек-контрейнты могли бы помочь, но не в вашем.
...
Рейтинг: 0 / 0
partition pruning при условии только на subpartition
    #39591245
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Модератор форума
Alexus12,

простейшее решение - это добавить таблицу (CREATE_DAY, RUN_ID_MIN, RUN_ID_MAX) и добавить условия по ней
...
Рейтинг: 0 / 0
partition pruning при условии только на subpartition
    #39591361
Bobby Z.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexus12вопрос: можно ли как-то ускорить эти запросы (в 1024К раз) без переписывания?
Глобальный индекс на RUN_ID. Он, конечно, создаст хренову кучу проблем в других областях (в частности, как раз ILM, поскольку его придётся каждый раз перестраивать после изменений структуры таблицы, что с Вашими масштабами будет весьма дорого и долго), но зато ускорит выборки по RUN_ID до быстрее некуда. Без переписывания. Это если в лоб отвечать на поставленный вопрос так, как он задан.

А ещё zone map вполне может помочь в данном конкретном случае. Как раз для того и придуманы.
...
Рейтинг: 0 / 0
partition pruning при условии только на subpartition
    #39591383
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Модератор форума
Bobby Z.зато ускорит выборки по RUN_IDхм, ТС не говорил ни об уникальности RUN_ID, ни вообще о селективности, может там фулсканы нужны...
...
Рейтинг: 0 / 0
partition pruning при условии только на subpartition
    #39591386
Bobby Z.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
xtenderBobby Z.зато ускорит выборки по RUN_IDхм, ТС не говорил ни об уникальности RUN_ID, ни вообще о селективности, может там фулсканы нужны...
Alexus12RUN_ID - монотонно возрастающее число, идентифицирующее набор строк Я сванговал из этого, что селективность достаточно высокая. Да и само название колонки как бы намекает. Хотя может каждый run генерит миллионы строк, тогда индекс, конечно, только хуже сделает.

Кстати, забыл сказать, что Zone Maps доступны только на Exadata и Supercluster, к сожалению, так что могут оказаться неприменимы в силу платформы. К хорошему быстро привыкаешь... :)
...
Рейтинг: 0 / 0
partition pruning при условии только на subpartition
    #39591492
[quot Bobby Z.]xtender
Кстати, забыл сказать, что Zone Maps доступны только на Exadata и Supercluster, к сожалению, так что могут оказаться неприменимы в силу платформы.

Эм... Сейчас читаю про zone maps, не увидел этого ограничения, разве что появилась эта фича только в 12с. Можно ссылочку, где про доступность только на экзе написано? Или вы спутали со storage index?
...
Рейтинг: 0 / 0
partition pruning при условии только на subpartition
    #39591507
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Модератор форума
Мимо крокодил,

https://docs.oracle.com/database/121/DBLIC/options.htm#DBLIC152 Zone Maps (Available starting with Oracle Database 12c Release 1 (12.1.0.2); Requires Exadata or Supercluster)
...
Рейтинг: 0 / 0
partition pruning при условии только на subpartition
    #39591512
Alexus12
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Спасибо!
Была надежда на что-то типа 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)
...
Рейтинг: 0 / 0
partition pruning при условии только на subpartition
    #39591519
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Модератор форума
Alexus12,

В принципе поможет даже локальный индекс по RUN_ID с адекватной статистикой - там где не будет нужного диапазона - будет index range scan, а в нужной подсекции в зависимости от статистики FTS или IRS
...
Рейтинг: 0 / 0
partition pruning при условии только на subpartition
    #39591521
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Модератор форума
IRS по подсекции где нет подходящего диапазона (high value/low value) будет моментальным
...
Рейтинг: 0 / 0
partition pruning при условии только на subpartition
    #39591523
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Модератор форума
Читай про трансформацию table expansion
...
Рейтинг: 0 / 0
partition pruning при условии только на subpartition
    #39591525
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Перебейте на partition by range (RUN_ID).
Ввиду корреляции между run_id и create_ts subpartitioning не требуется.
...
Рейтинг: 0 / 0
partition pruning при условии только на subpartition
    #39591527
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Модератор форума
правда будет шанс нарваться на ограничение inlist в 1000 элементов при table expansion
...
Рейтинг: 0 / 0
partition pruning при условии только на subpartition
    #39591528
Alexus12
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
дополнительное условие по теме можно ли как-то ускорить эти запросы (в 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.

конечно, это нецелевое ее использование, но - рабочий вариант?
...
Рейтинг: 0 / 0
partition pruning при условии только на subpartition
    #39591532
Alexus12
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
andrey_anonymous,

есть adhoc-запросы по таблице, которые отбирают как раз по create_ts, поэтому не хочется...
...
Рейтинг: 0 / 0
partition pruning при условии только на subpartition
    #39591536
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Модератор форума
Alexus12,

проще и правильнее было бы воспользоваться interval-reference partitioning: создали родительскую таблицу из (CREATE_TS,RUN_ID) секционированную по CREATE_TS, а текущая уже была бы дочерней к ней
...
Рейтинг: 0 / 0
partition pruning при условии только на subpartition
    #39591538
Alexus12
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
xtender,

table expansion - хороший вариант, но не в нашем случае - читаем записанное почти сразу, см use case выше
...
Рейтинг: 0 / 0
partition pruning при условии только на subpartition
    #39591542
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Модератор форума
Alexus12xtender,

table expansion - хороший вариант, но не в нашем случае - читаем записанное почти сразу, см use case вышену и что? оверхед-то будет меньше чем в секунду ~1000 логических чтений корня индекса
...
Рейтинг: 0 / 0
partition pruning при условии только на subpartition
    #39591543
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Модератор форума
сейчас то у вас вообще ~1000 фулсканов
...
Рейтинг: 0 / 0
partition pruning при условии только на subpartition
    #39591547
Alexus12
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
xtender,
>проще и правильнее было бы воспользоваться interval-reference partitioning

возможно, но:
1) хочется обойтись без изменения таблиц и запросов
2) interval-reference partitioning требует явного неdisabled FK-ключа, на таких объемах очень не хочется...
...
Рейтинг: 0 / 0
partition pruning при условии только на subpartition
    #39591550
Alexus12
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
xtenderAlexus12xtender,

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

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

насколько это лучше/хуже моего варианта с vpd?
...
Рейтинг: 0 / 0
partition pruning при условии только на subpartition
    #39591556
Alexus12
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vpd по сравнению с table expansion - как минимум не требует доп. индексов и их перестроения (unusable)
...
Рейтинг: 0 / 0
partition pruning при условии только на subpartition
    #39591608
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexus12есть adhoc-запросы по таблице, которые отбирают как раз по create_ts, поэтому не хочется...
Вариант reference partitioning уже указали, но даже без него ничего не мешает держать рядом объект структуры
Код: plsql
1.
(create_ts_min,create_ts_max,run_id from,run_id to)


который ведется при наполнении таблицы и используется для отбора границ run_id по заданному create_ts.
subpartitioning - в указанном случае overkill
...
Рейтинг: 0 / 0
partition pruning при условии только на subpartition
    #39591642
dba123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexus12,

Есть ли связь между run_id и датой?
может run_id ~ to_number(to_char(sysdate, 'j'),'fm', 'nls_numeric_characters='.') ?
или id точно раз в день генерируется.

Тогда еще можно для любого run_id сконструировать vpd_предикат
...
Рейтинг: 0 / 0
partition pruning при условии только на subpartition
    #39591739
Alexus12
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
andrey_anonymousAlexus12есть adhoc-запросы по таблице, которые отбирают как раз по create_ts, поэтому не хочется...
Вариант reference partitioning уже указали, но даже без него ничего не мешает держать рядом объект структуры
Код: plsql
1.
(create_ts_min,create_ts_max,run_id from,run_id to)


который ведется при наполнении таблицы и используется для отбора границ run_id по заданному create_ts.
subpartitioning - в указанном случае overkill

прошу пояснить на конкретном примере - как заполняем доп.таблицу, как используем для partitoin pruning
...
Рейтинг: 0 / 0
partition pruning при условии только на subpartition
    #39591746
Alexus12
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
в существующей схеме работы рядом заполняется еще одна, более короткая таблица-лог вида (run_id, create_ts) - по одной строке на run_id - можно переиспользовать и ее:
1) зная run_id, подсмотреть из нее create_ts
2) подставить create_ts в запрос к длинному логу (предмету обсуждения)
- но это означает переработку кода + не страхует от непонятливых adhoc-юзеров, не дописавших условие на create_ts...

похоже, быстрым тех. решением является vpd-подклеивание условия на create_ts,
а универсальным - table expansion (т.к. есть плюс для непонятливых adhoc-юзеров)

еще варианты?
...
Рейтинг: 0 / 0
partition pruning при условии только на subpartition
    #39591852
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexus12прошу пояснить на конкретном примере - как заполняем доп.таблицу, как используем для partitoin pruning
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
drop table ane_logkeys purge;
drop table ane_logdata purge;
drop sequence ane_log$sq;
create table ane_logdata(run_id integer, create_ts timestamp(3), somedata varchar2(100))
partition by range(run_id) interval (10)
(partition p_base values less than (1) segment creation deferred);
create table ane_logkeys(run_id_min integer, run_id_max integer
, create_ts_from timestamp(3)
, create_ts_to timestamp(3)
);
create sequence ane_log$sq;


Процесс наполнения, один из вариантов:
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
var v_run_id number
var v_create_ts varchar2(100)
alter session set nls_timestamp_tz_format='yyyy-mm-dd hh24:mi:ss.ff3';
alter session set nls_timestamp_format='yyyy-mm-dd hh24:mi:ss.ff3';
exec select ane_log$sq.nextval, systimestamp into :v_run_id, :v_create_ts from dual;
merge into ane_logkeys t
using (select :v_run_id v_run_id, to_timestamp(:v_create_ts) v_create_ts from dual) s
on (v_create_ts between t.create_ts_from and create_ts_to)
when matched then
update set run_id_min=least(run_id_min, v_run_id)
, run_id_max=greatest(run_id_max, v_run_id)
when not matched then
insert (run_id_min, run_id_max, create_ts_from, create_ts_to)
values (v_run_id, v_run_id, trunc(v_create_ts,'DD'), trunc(v_create_ts,'DD')+1-1/86400)
;
insert into ane_logdata(run_id, create_ts, somedata)
select :v_run_id, to_timestamp(:v_create_ts), 'value #'||rownum||' for run_id='||:v_run_id||' and create_ts='||:v_create_ts
from dual connect by level < 1000
;



Поиск по диапазону create_ts:
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
explain plan for
with t(run_id_min,run_id_max) as (select min(run_id_min), max(run_id_max) from ane_logkeys where CREATE_TS_FROM between :1 and :2)
select count(*) from t, ane_logdata d where d.run_id between t.run_id_min and t.run_id_max
and d.create_ts between :1 and :2;


set linesize 1000
col PLAN_TABLE_OUTPUT format a300

select * from table(dbms_xplan.display(format => 'ALL'));

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Plan hash value: 2951821927
----------------------------------------------------------------------------------------------------------
| Id  | Operation                  | Name        | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
----------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT           |             |     1 |    52 |    17   (0)| 00:00:01 |       |       |
|   1 |  SORT AGGREGATE            |             |     1 |    52 |            |          |       |       |
|   2 |   NESTED LOOPS             |             |     1 |    52 |    17   (0)| 00:00:01 |       |       |
|   3 |    VIEW                    |             |     1 |    26 |     3   (0)| 00:00:01 |       |       |
|*  4 |     FILTER                 |             |       |       |            |          |       |       |
|   5 |      SORT AGGREGATE        |             |     1 |    39 |            |          |       |       |
|*  6 |       FILTER               |             |       |       |            |          |       |       |
|*  7 |        TABLE ACCESS FULL   | ANE_LOGKEYS |     1 |    39 |     3   (0)| 00:00:01 |       |       |
|   8 |    PARTITION RANGE ITERATOR|             |     1 |    26 |    14   (0)| 00:00:01 |   KEY |   KEY |
|*  9 |     TABLE ACCESS FULL      | ANE_LOGDATA |     1 |    26 |    14   (0)| 00:00:01 |   KEY |   KEY |
----------------------------------------------------------------------------------------------------------
Query Block Name / Object Alias (identified by operation id):
-------------------------------------------------------------
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
   1 - SEL$2
   3 - SEL$1 / T@SEL$2
   4 - SEL$1
   7 - SEL$1 / ANE_LOGKEYS@SEL$1
   9 - SEL$2 / D@SEL$2
Predicate Information (identified by operation id):
---------------------------------------------------
   4 - filter(TO_TIMESTAMP(:1)<=TO_TIMESTAMP(:2))
   6 - filter(TO_TIMESTAMP(:1)<=TO_TIMESTAMP(:2))
   7 - filter("CREATE_TS_FROM">=TO_TIMESTAMP(:1) AND "CREATE_TS_FROM"<=TO_TIMESTAMP(:2))
   9 - filter("D"."CREATE_TS">=TO_TIMESTAMP(:1) AND "D"."CREATE_TS"<=TO_TIMESTAMP(:2) AND
              "D"."RUN_ID">="T"."RUN_ID_MIN" AND "D"."RUN_ID"<="T"."RUN_ID_MAX")
Column Projection Information (identified by operation id):
-----------------------------------------------------------
   1 - (#keys=0) COUNT(*)[22]
   2 - (#keys=0)
   3 - "T"."RUN_ID_MIN"[NUMBER,22], "T"."RUN_ID_MAX"[NUMBER,22]
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
   4 - MAX("RUN_ID_MAX")[22], MIN("RUN_ID_MIN")[22]
   5 - (#keys=0) MAX("RUN_ID_MAX")[22], MIN("RUN_ID_MIN")[22]
   6 - "RUN_ID_MIN"[NUMBER,22], "RUN_ID_MAX"[NUMBER,22]
   7 - "RUN_ID_MIN"[NUMBER,22], "RUN_ID_MAX"[NUMBER,22]
Note
-----
   - dynamic sampling used for this statement (level=2)

SQL> 
...
Рейтинг: 0 / 0
partition pruning при условии только на subpartition
    #39592263
Rudyshin Sergey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
> Перебейте на partition by range (RUN_ID).

поддерживаю
а еще лучше на LIST и создать партиций на год вперед

и если уж заморачиваться с VPD, то переписывать запросы подставляя RUN_ID, а не CREATE_TS

правда вот эта часть таблицы намекает на то, что вставки тормозили
Код: plsql
1.
SUBPARTITION BY HASH ("RUN_ID") SUBPARTITIONS 128



в таком случае можно было бы добавить колонку с дефолтным значением MOD(SYS_CONTEXT ('USERENV', 'SID'), 8)
и добавить сабпартиций по этой колонке и тоже по LIST

в противном случае у вас достаточно рано начнутся проблемы с числом партиций
при текущем решении уже через полгода будет 180*128=23040 партиций
и селекты к этой таблице будут долго парситься
...
Рейтинг: 0 / 0
partition pruning при условии только на subpartition
    #39592312
Rudyshin Sergey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
зря я предложил доп колонку. Сабпартиционирование уже и так по RUN_ID. А вот "by range (RUN_ID)" может выявить проблему со вставками, если много процессов будут вставлять в одну партицию. Так что скорее всего LIST. И кстати APPEND не применяется при вставках?
...
Рейтинг: 0 / 0
partition pruning при условии только на subpartition
    #39593165
Alexus12
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
andrey_anonymous

Поиск по диапазону create_ts:
Код: plsql
1.
2.
3.
4.
explain plan for
with t(run_id_min,run_id_max) as (select min(run_id_min), max(run_id_max) from ane_logkeys where CREATE_TS_FROM between :1 and :2)
select count(*) from t, ane_logdata d where d.run_id between t.run_id_min and t.run_id_max
and d.create_ts between :1 and :2;



у нас типовой запрос только по run_id отбирает...
соответственно, целевой запрос с доп.таблицей такого вида будет еще сложнее...
...
Рейтинг: 0 / 0
partition pruning при условии только на subpartition
    #39593168
Alexus12
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Rudyshin Sergey> Перебейте на partition by range (RUN_ID).

поддерживаю
а еще лучше на LIST и создать партиций на год вперед

и если уж заморачиваться с VPD, то переписывать запросы подставляя RUN_ID, а не CREATE_TS

правда вот эта часть таблицы намекает на то, что вставки тормозили
Код: plsql
1.
SUBPARTITION BY HASH ("RUN_ID") SUBPARTITIONS 128





эта часть таблицы заточена на следующее использование:
в одной дате create_ts вставляется 1000...10000 разных RUN_ID, в каждом RUN_ID 1000+строк


>и если уж заморачиваться с VPD, то переписывать запросы подставляя RUN_ID, а не CREATE_TS

не могу - готовый софт запрашивает по RUN_ID, а CREATE_TS не проблема дорисовать из VPD
...
Рейтинг: 0 / 0
partition pruning при условии только на subpartition
    #39593173
Alexus12
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Rudyshin Sergey>
у вас достаточно рано начнутся проблемы с числом партиций
при текущем решении уже через полгода будет 180*128=23040 партиций
и селекты к этой таблице будут долго парситься


хочу замерить это следующим подходом на проме:
0) клонировать текущую таблицу

1) заполнить ее на 10% целевых записей:
- create_ts - все дни за 3 года = 100% данных,
- run_id - 1000 разных в одной дате = 10% данных ,
- в каждом run_id - 1000 строк = 100% данных

2) подергать тигра за усы типовые запросы (условиями на run_id и create_ts по одной и вместе)

репрезентативен будет тест или стоит что-то подкрутить?


на вопрос про APPEND ответ утвердительный (льет Informatica)
...
Рейтинг: 0 / 0
partition pruning при условии только на subpartition
    #39593332
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexus12у нас типовой запрос только по run_id отбирает...
соответственно, целевой запрос с доп.таблицей такого вида будет еще сложнее...
????
Запрос по run_id НЕ требует никаких ухищрений.
Представлен давно апробированный поход к построению запросов по коррелированному с ключом секционирования атрибуту (дате в данном случае) :)
...
Рейтинг: 0 / 0
partition pruning при условии только на subpartition
    #39593334
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexus12на вопрос про APPEND ответ утвердительный (льет Informatica)
А в сколько потоков она льет?
Проблема append - в блокировке таблицы, т.е. пока такая сессия одна - все ОК, но две уже будут ссориться.
...
Рейтинг: 0 / 0
partition pruning при условии только на subpartition
    #39594505
Rudyshin Sergey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
с APPEND получается, что если не указать явно название партиции, в которую идет вставка, то вся таблица лочится
в Informatica, насколько помню, возможно заморочиться и начать подставлять эти названия. но сделано ли так у вас?

если не сделано, то скорее всего вставки идут последовательно
и убрав APPEND может ускориться загрузка

а вообще можно попробовать сделать следующее:
сделать обчную непартиционированную таблицу (сжать через advanced compression (если лицензия позволяет))
и добавить два индекса по RUN_ID и по CREATE_TS
они конечно съедят место, но возможно не так много по сравнению с самой таблицей
зато все запросы будут летать и никакого vpd не нужно
...
Рейтинг: 0 / 0
39 сообщений из 39, показаны все 2 страниц
Форумы / Oracle [игнор отключен] [закрыт для гостей] / partition pruning при условии только на subpartition
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]