|
|
|
DBMS_PARALLEL_EXECUTE OVER PARTITION
|
|||
|---|---|---|---|
|
#18+
Есть необходимость задействовать DBMS_PARALLEL_EXECUTE для сканирования единственной партиции таблицы. Не ясно каким образом в данном случае следует создавать чанки (очевидно, самый выгодный подход для обычных таблиц - DBMS_PARALLEL_EXECUTE::CREATE_CHUNKS_BY_ROWID - не предусматривает работу с одиночными партициями). Кроме того, CREATE_CHUNKS_BY_ROWID не возможно использовать после перемещения партиции (ALTER TABLE EXCHANGE PARTITION) ввиду ошибки: INVALID_TABLE, ORA-29491, "Attempts to chunk a table by rowid in cases in which the table is not a physical table, or the table is an IOT". Можно воспользоваться CREATE_CHUNKS_BY_NUMBER_COL, но это очень долго при больших объемах данных (десятки миллионов строк в партиции, десятки партиций). Что-то ниже спины подсказывает мне, что CREATE_CHUNKS_BY_SQL - то, что мне нужно, но я не знаю как написать запрос для разбиения партиции на чанки по заданному количеству ROWID. Подскажите, пожалуйста, люди ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2017, 11:55 |
|
||
|
DBMS_PARALLEL_EXECUTE OVER PARTITION
|
|||
|---|---|---|---|
|
#18+
--Eugene--, камрад, теоретически можно извратиться в этом направлении: Код: plsql 1. 2. 3. правда, количество чанков будет плавающим от запроса к запросу... с ув. IT ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2017, 19:03 |
|
||
|
DBMS_PARALLEL_EXECUTE OVER PARTITION
|
|||
|---|---|---|---|
|
#18+
--Eugene--очевидно, самый выгодный подход для обычных таблиц - DBMS_PARALLEL_EXECUTE::CREATE_CHUNKS_BY_ROWID - не предусматривает работу с одиночными партициямиЭто только тебе очевидно. Раз (create_chunks_by_sql) параллельное выполнение процедур Два (create_chunks_by_number_col) DBMS_PARALLEL_EXECUTE ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2017, 19:16 |
|
||
|
DBMS_PARALLEL_EXECUTE OVER PARTITION
|
|||
|---|---|---|---|
|
#18+
--Eugene--, Для получения rowid'а не обязательно лезть в таблицу, его можно сочинить с помощью dbms_rowid.rowd_create. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2017, 20:32 |
|
||
|
DBMS_PARALLEL_EXECUTE OVER PARTITION
|
|||
|---|---|---|---|
|
#18+
dbms_photoshop, если Вы о драматической деградации перформанса (скатывания практически до последовательного исполнения), я в курсе сего феномена (и работаю как раз на 11.2.0.4). На тот момент я не знал, что это баг, и сделал вывод, что использование CREATE_CHUNKS_BY_NUMBER_COL не спасет ситуацию, тем более, что сам способ разбиения по колонке (в противоположность разбиению по ROWID), насколько я понимаю, занимает гораздо больше времени (не прав?). И да, это-таки лечится? (имеется в виду 18379323 ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.10.2017, 21:17 |
|
||
|
DBMS_PARALLEL_EXECUTE OVER PARTITION
|
|||
|---|---|---|---|
|
#18+
--Eugene--если Вы о драматической деградации перформансаНет, я про разбиение на подзадачи различными способами. В скобочках были указаны соответствующие методы. Разбиение должно быть таким, чтоб во-первых подзадачи покрывали необходимое тебе множество, а во-вторых были примерно равными по объему. --Eugene--сам способ разбиения по колонке (в противоположность разбиению по ROWID), насколько я понимаю, занимает гораздо больше времени (не прав?)Время на разбиением любым из способов весьма мало и вообще им можно пренебречь по сравнению со временем на выполнение. Не совсем понятно откуда берутся твои домыслы. Всё же проверяемо. --Eugene--И да, это-таки лечится? (имеется в виду 18379323 )Если цель чтоб на очень малых объемах было желаемое число подзадач, то можно прикрутить самостоятельное разбиение на подзадачи. С помощью того же dbms_job. Elic приводил код. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.10.2017, 15:21 |
|
||
|
|

start [/forum/search_topic.php?author=Olchi&author_mode=last_posts&do_search=1]: |
0ms |
get settings: |
6ms |
get forum list: |
14ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
153ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
| others: | 422ms |
| total: | 686ms |

| 0 / 0 |
