powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Oracle [игнор отключен] [закрыт для гостей] / partition pruning при условии только на subpartition
14 сообщений из 39, страница 2 из 2
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
14 сообщений из 39, страница 2 из 2
Форумы / Oracle [игнор отключен] [закрыт для гостей] / partition pruning при условии только на subpartition
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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