|
|
|
partition pruning при условии только на subpartition
|
|||
|---|---|---|---|
|
#18+
vpd по сравнению с table expansion - как минимум не требует доп. индексов и их перестроения (unusable) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2018, 12:34 |
|
||
|
partition pruning при условии только на subpartition
|
|||
|---|---|---|---|
|
#18+
Alexus12есть adhoc-запросы по таблице, которые отбирают как раз по create_ts, поэтому не хочется... Вариант reference partitioning уже указали, но даже без него ничего не мешает держать рядом объект структуры Код: plsql 1. который ведется при наполнении таблицы и используется для отбора границ run_id по заданному create_ts. subpartitioning - в указанном случае overkill ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2018, 13:28 |
|
||
|
partition pruning при условии только на subpartition
|
|||
|---|---|---|---|
|
#18+
Alexus12, Есть ли связь между run_id и датой? может run_id ~ to_number(to_char(sysdate, 'j'),'fm', 'nls_numeric_characters='.') ? или id точно раз в день генерируется. Тогда еще можно для любого run_id сконструировать vpd_предикат ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2018, 13:57 |
|
||
|
partition pruning при условии только на subpartition
|
|||
|---|---|---|---|
|
#18+
andrey_anonymousAlexus12есть adhoc-запросы по таблице, которые отбирают как раз по create_ts, поэтому не хочется... Вариант reference partitioning уже указали, но даже без него ничего не мешает держать рядом объект структуры Код: plsql 1. который ведется при наполнении таблицы и используется для отбора границ run_id по заданному create_ts. subpartitioning - в указанном случае overkill прошу пояснить на конкретном примере - как заполняем доп.таблицу, как используем для partitoin pruning ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2018, 15:10 |
|
||
|
partition pruning при условии только на subpartition
|
|||
|---|---|---|---|
|
#18+
в существующей схеме работы рядом заполняется еще одна, более короткая таблица-лог вида (run_id, create_ts) - по одной строке на run_id - можно переиспользовать и ее: 1) зная run_id, подсмотреть из нее create_ts 2) подставить create_ts в запрос к длинному логу (предмету обсуждения) - но это означает переработку кода + не страхует от непонятливых adhoc-юзеров, не дописавших условие на create_ts... похоже, быстрым тех. решением является vpd-подклеивание условия на create_ts, а универсальным - table expansion (т.к. есть плюс для непонятливых adhoc-юзеров) еще варианты? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2018, 15:16 |
|
||
|
partition pruning при условии только на subpartition
|
|||
|---|---|---|---|
|
#18+
Alexus12прошу пояснить на конкретном примере - как заполняем доп.таблицу, как используем для partitoin pruning Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Процесс наполнения, один из вариантов: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. Поиск по диапазону 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2018, 18:09 |
|
||
|
partition pruning при условии только на subpartition
|
|||
|---|---|---|---|
|
#18+
> Перебейте на partition by range (RUN_ID). поддерживаю а еще лучше на LIST и создать партиций на год вперед и если уж заморачиваться с VPD, то переписывать запросы подставляя RUN_ID, а не CREATE_TS правда вот эта часть таблицы намекает на то, что вставки тормозили Код: plsql 1. в таком случае можно было бы добавить колонку с дефолтным значением MOD(SYS_CONTEXT ('USERENV', 'SID'), 8) и добавить сабпартиций по этой колонке и тоже по LIST в противном случае у вас достаточно рано начнутся проблемы с числом партиций при текущем решении уже через полгода будет 180*128=23040 партиций и селекты к этой таблице будут долго парситься ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2018, 22:11 |
|
||
|
partition pruning при условии только на subpartition
|
|||
|---|---|---|---|
|
#18+
зря я предложил доп колонку. Сабпартиционирование уже и так по RUN_ID. А вот "by range (RUN_ID)" может выявить проблему со вставками, если много процессов будут вставлять в одну партицию. Так что скорее всего LIST. И кстати APPEND не применяется при вставках? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2018, 10:31 |
|
||
|
partition pruning при условии только на subpartition
|
|||
|---|---|---|---|
|
#18+
andrey_anonymous Поиск по диапазону create_ts: Код: plsql 1. 2. 3. 4. у нас типовой запрос только по run_id отбирает... соответственно, целевой запрос с доп.таблицей такого вида будет еще сложнее... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2018, 11:01 |
|
||
|
partition pruning при условии только на subpartition
|
|||
|---|---|---|---|
|
#18+
Rudyshin Sergey> Перебейте на partition by range (RUN_ID). поддерживаю а еще лучше на LIST и создать партиций на год вперед и если уж заморачиваться с VPD, то переписывать запросы подставляя RUN_ID, а не CREATE_TS правда вот эта часть таблицы намекает на то, что вставки тормозили Код: plsql 1. эта часть таблицы заточена на следующее использование: в одной дате create_ts вставляется 1000...10000 разных RUN_ID, в каждом RUN_ID 1000+строк >и если уж заморачиваться с VPD, то переписывать запросы подставляя RUN_ID, а не CREATE_TS не могу - готовый софт запрашивает по RUN_ID, а CREATE_TS не проблема дорисовать из VPD ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2018, 11:06 |
|
||
|
partition pruning при условии только на subpartition
|
|||
|---|---|---|---|
|
#18+
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) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2018, 11:10 |
|
||
|
partition pruning при условии только на subpartition
|
|||
|---|---|---|---|
|
#18+
Alexus12у нас типовой запрос только по run_id отбирает... соответственно, целевой запрос с доп.таблицей такого вида будет еще сложнее... ???? Запрос по run_id НЕ требует никаких ухищрений. Представлен давно апробированный поход к построению запросов по коррелированному с ключом секционирования атрибуту (дате в данном случае) :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2018, 14:00 |
|
||
|
partition pruning при условии только на subpartition
|
|||
|---|---|---|---|
|
#18+
Alexus12на вопрос про APPEND ответ утвердительный (льет Informatica) А в сколько потоков она льет? Проблема append - в блокировке таблицы, т.е. пока такая сессия одна - все ОК, но две уже будут ссориться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2018, 14:03 |
|
||
|
partition pruning при условии только на subpartition
|
|||
|---|---|---|---|
|
#18+
с APPEND получается, что если не указать явно название партиции, в которую идет вставка, то вся таблица лочится в Informatica, насколько помню, возможно заморочиться и начать подставлять эти названия. но сделано ли так у вас? если не сделано, то скорее всего вставки идут последовательно и убрав APPEND может ускориться загрузка а вообще можно попробовать сделать следующее: сделать обчную непартиционированную таблицу (сжать через advanced compression (если лицензия позволяет)) и добавить два индекса по RUN_ID и по CREATE_TS они конечно съедят место, но возможно не так много по сравнению с самой таблицей зато все запросы будут летать и никакого vpd не нужно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2018, 00:07 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39593165&tid=1884500]: |
0ms |
get settings: |
8ms |
get forum list: |
15ms |
check forum access: |
2ms |
check topic access: |
3ms |
track hit: |
38ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
52ms |
get tp. blocked users: |
1ms |
| others: | 244ms |
| total: | 374ms |

| 0 / 0 |
