|
|
|
partition pruning при условии только на subpartition
|
|||
|---|---|---|---|
|
#18+
Бодрого всем! Oracle 12.1, есть фактовая таблица: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. логика заполнения: RUN_ID - монотонно возрастающее число, идентифицирующее набор строк CREATE_TS - монотонно возрастающее дата/время удалений/правок в таблице нет расчетное наполнение - 2,5 млрд строк в год, ILM - 3 года хранения, т.е. пик наполнения ожидается на уровне 7,5 млрд строк Для эффективного отбора из нее (чтобы сработал partition pruning по обоим уровням) необходимо в запросе указывать условия на оба поля - "CREATE_TS" и "RUN_ID" При этом уже существуют запросы, отбирающие только по "RUN_ID", план в этом случае выглядит как Код: plsql 1. 2. - т.е. просматривается 1024К-2 субпартиций RUN_ID партиций ("CREATE_TS"), в которых в принципе искомого RUN_ID нет вопрос: можно ли как-то ускорить эти запросы (в 1024К раз) без переписывания? Спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2018, 18:07 |
|
||
|
partition pruning при условии только на subpartition
|
|||
|---|---|---|---|
|
#18+
поправка - ускорить не в 1024К раз, а всего в 365*3 - 1 раз (столько лишних партиций накопится за 3 года) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2018, 18:29 |
|
||
|
partition pruning при условии только на subpartition
|
|||
|---|---|---|---|
|
#18+
Alexus12, Я правильно понял суть вопроса: нужно чтобы оракл отсек ненужные партиции и читал только одну нужную, и при этом в запросе не фильтровать по полю партиционирования, и не менять исходный запрос? =) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2018, 18:59 |
|
||
|
partition pruning при условии только на subpartition
|
|||
|---|---|---|---|
|
#18+
Alexus12 Код: plsql 1. это и означает, что в секции просматривается только одна подсекция. Если было бы RUN_ID in (...), был бы PARTITION HASH INLIST , а полный - это PARTITION HASH ALL . Количество же просмотренных подсекций можно увидеть в STARTS. Alexus12т.е. просматривается 1024К-2 субпартиций RUN_ID партиций ("CREATE_TS"), в которых в принципе искомого RUN_ID неткак такой вывод вообще был сделан? и считали-то как? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2018, 19:00 |
|
||
|
partition pruning при условии только на subpartition
|
|||
|---|---|---|---|
|
#18+
Мимо крокодилAlexus12, Я правильно понял суть вопроса: нужно чтобы оракл отсек ненужные партиции и читал только одну нужную, и при этом в запросе не фильтровать по полю партиционирования, и не менять исходный запрос? =)ааа, вот теперь понял в чем вопрос Alexus12, Alexus12RUN_ID - монотонно возрастающее число, идентифицирующее набор строк ораклу неоткуда брать информацию, в какой секции лежит какой диапазон RUN_ID (статистика не в счет, т.к. она ничего не гарантирует). В похожих случаях еще чек-контрейнты могли бы помочь, но не в вашем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2018, 19:04 |
|
||
|
partition pruning при условии только на subpartition
|
|||
|---|---|---|---|
|
#18+
Alexus12, простейшее решение - это добавить таблицу (CREATE_DAY, RUN_ID_MIN, RUN_ID_MAX) и добавить условия по ней ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2018, 19:08 |
|
||
|
partition pruning при условии только на subpartition
|
|||
|---|---|---|---|
|
#18+
Alexus12вопрос: можно ли как-то ускорить эти запросы (в 1024К раз) без переписывания? Глобальный индекс на RUN_ID. Он, конечно, создаст хренову кучу проблем в других областях (в частности, как раз ILM, поскольку его придётся каждый раз перестраивать после изменений структуры таблицы, что с Вашими масштабами будет весьма дорого и долго), но зато ускорит выборки по RUN_ID до быстрее некуда. Без переписывания. Это если в лоб отвечать на поставленный вопрос так, как он задан. А ещё zone map вполне может помочь в данном конкретном случае. Как раз для того и придуманы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2018, 23:07 |
|
||
|
partition pruning при условии только на subpartition
|
|||
|---|---|---|---|
|
#18+
Bobby Z.зато ускорит выборки по RUN_IDхм, ТС не говорил ни об уникальности RUN_ID, ни вообще о селективности, может там фулсканы нужны... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2018, 01:16 |
|
||
|
partition pruning при условии только на subpartition
|
|||
|---|---|---|---|
|
#18+
xtenderBobby Z.зато ускорит выборки по RUN_IDхм, ТС не говорил ни об уникальности RUN_ID, ни вообще о селективности, может там фулсканы нужны... Alexus12RUN_ID - монотонно возрастающее число, идентифицирующее набор строк Я сванговал из этого, что селективность достаточно высокая. Да и само название колонки как бы намекает. Хотя может каждый run генерит миллионы строк, тогда индекс, конечно, только хуже сделает. Кстати, забыл сказать, что Zone Maps доступны только на Exadata и Supercluster, к сожалению, так что могут оказаться неприменимы в силу платформы. К хорошему быстро привыкаешь... :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2018, 01:25 |
|
||
|
partition pruning при условии только на subpartition
|
|||
|---|---|---|---|
|
#18+
[quot Bobby Z.]xtender Кстати, забыл сказать, что Zone Maps доступны только на Exadata и Supercluster, к сожалению, так что могут оказаться неприменимы в силу платформы. Эм... Сейчас читаю про zone maps, не увидел этого ограничения, разве что появилась эта фича только в 12с. Можно ссылочку, где про доступность только на экзе написано? Или вы спутали со storage index? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2018, 11:16 |
|
||
|
partition pruning при условии только на subpartition
|
|||
|---|---|---|---|
|
#18+
Мимо крокодил, 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) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2018, 11:40 |
|
||
|
partition pruning при условии только на subpartition
|
|||
|---|---|---|---|
|
#18+
Спасибо! Была надежда на что-то типа 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) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2018, 11:48 |
|
||
|
partition pruning при условии только на subpartition
|
|||
|---|---|---|---|
|
#18+
Alexus12, В принципе поможет даже локальный индекс по RUN_ID с адекватной статистикой - там где не будет нужного диапазона - будет index range scan, а в нужной подсекции в зависимости от статистики FTS или IRS ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2018, 11:58 |
|
||
|
partition pruning при условии только на subpartition
|
|||
|---|---|---|---|
|
#18+
IRS по подсекции где нет подходящего диапазона (high value/low value) будет моментальным ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2018, 11:59 |
|
||
|
partition pruning при условии только на subpartition
|
|||
|---|---|---|---|
|
#18+
Читай про трансформацию table expansion ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2018, 12:00 |
|
||
|
partition pruning при условии только на subpartition
|
|||
|---|---|---|---|
|
#18+
Перебейте на partition by range (RUN_ID). Ввиду корреляции между run_id и create_ts subpartitioning не требуется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2018, 12:00 |
|
||
|
partition pruning при условии только на subpartition
|
|||
|---|---|---|---|
|
#18+
правда будет шанс нарваться на ограничение inlist в 1000 элементов при table expansion ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2018, 12:02 |
|
||
|
partition pruning при условии только на subpartition
|
|||
|---|---|---|---|
|
#18+
дополнительное условие по теме можно ли как-то ускорить эти запросы (в 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. конечно, это нецелевое ее использование, но - рабочий вариант? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2018, 12:05 |
|
||
|
partition pruning при условии только на subpartition
|
|||
|---|---|---|---|
|
#18+
andrey_anonymous, есть adhoc-запросы по таблице, которые отбирают как раз по create_ts, поэтому не хочется... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2018, 12:09 |
|
||
|
partition pruning при условии только на subpartition
|
|||
|---|---|---|---|
|
#18+
Alexus12, проще и правильнее было бы воспользоваться interval-reference partitioning: создали родительскую таблицу из (CREATE_TS,RUN_ID) секционированную по CREATE_TS, а текущая уже была бы дочерней к ней ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2018, 12:15 |
|
||
|
partition pruning при условии только на subpartition
|
|||
|---|---|---|---|
|
#18+
xtender, table expansion - хороший вариант, но не в нашем случае - читаем записанное почти сразу, см use case выше ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2018, 12:15 |
|
||
|
partition pruning при условии только на subpartition
|
|||
|---|---|---|---|
|
#18+
Alexus12xtender, table expansion - хороший вариант, но не в нашем случае - читаем записанное почти сразу, см use case вышену и что? оверхед-то будет меньше чем в секунду ~1000 логических чтений корня индекса ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2018, 12:23 |
|
||
|
partition pruning при условии только на subpartition
|
|||
|---|---|---|---|
|
#18+
сейчас то у вас вообще ~1000 фулсканов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2018, 12:23 |
|
||
|
partition pruning при условии только на subpartition
|
|||
|---|---|---|---|
|
#18+
xtender, >проще и правильнее было бы воспользоваться interval-reference partitioning возможно, но: 1) хочется обойтись без изменения таблиц и запросов 2) interval-reference partitioning требует явного неdisabled FK-ключа, на таких объемах очень не хочется... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2018, 12:26 |
|
||
|
partition pruning при условии только на subpartition
|
|||
|---|---|---|---|
|
#18+
xtenderAlexus12xtender, table expansion - хороший вариант, но не в нашем случае - читаем записанное почти сразу, см use case вышену и что? оверхед-то будет меньше чем в секунду ~1000 логических чтений корня индекса да, в такой постановке 1000 логических чтений корня индекса лучше 1000 FTS насколько это лучше/хуже моего варианта с vpd? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2018, 12:29 |
|
||
|
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?all=1&fid=52&tid=1884500]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
42ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
58ms |
get tp. blocked users: |
1ms |
| others: | 214ms |
| total: | 355ms |

| 0 / 0 |
