|
dbms_parallel_execute create_chunks_by_rowid - долгая работа на двух таблицах
|
|||
---|---|---|---|
#18+
Коллеги, привет. Использую dbms_parallel_execute.create_chunks_by_rowid на таблицах с большим количеством записей (10 миллиардов). На некоторых таблицах create_chunks отрабатывает достаточно быстро (около минуты), а на паре таблиц - затупила очень сильно: работала 2-3 часа. Количество строк, длина записи у таблиц - всё одного порядка. Разница - в количестве сегментов. Там, где отрабатывает быстро: 1-5-15 сегментов. Там, где медленно: 250 сегментов. Но не должно же быть такого адского замедления (в 100 раз) при увеличении сегментов в 10 раз. Видимо дело не только в сегментах? Куда копать? Причём время исполнения операции run_task - нормальное, сопоставимое с остальными таблицами. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2021, 13:56 |
|
dbms_parallel_execute create_chunks_by_rowid - долгая работа на двух таблицах
|
|||
---|---|---|---|
#18+
shurka22, Опять наткнулся на проблему. Погуглил, наткнулся на этот свой пост. Крутили ручки с админами. Решили: alter session set optimizer_index_cost_adj=8 "_hash_join_enabled"=true "_push_join_union_view"=true "_optimizer_cost_based_transformation"=on "_optimizer_sortmerge_join_enabled"=true; ... |
|||
:
Нравится:
Не нравится:
|
|||
13.10.2021, 13:53 |
|
dbms_parallel_execute create_chunks_by_rowid - долгая работа на двух таблицах
|
|||
---|---|---|---|
#18+
shurka22 Разница - в количестве сегментов. Там, где отрабатывает быстро: 1-5-15 сегментов. Там, где медленно: 250 сегментов. "Сегментов" - это Вы имеете в виду что таблица партиционирована, и 1-5-15/250 - это количество партиций (бо каждая партиций - сегмент). Или все же не "сегментов", а экстентов? Не суть на самом деле. Я бы оттрассировал сам вызов DBMS_PARALLEL_EXECUTE.CREATE_CHUNKS_BY_ROWID - и посмотрел бы, что у него "под капотом", какие рекурсивные запросы выполняются, суть как именно работает эта процедура, какие запросы выполняются и какой именно тормозит. Скорее всего выплывет какой-то неэффективный запрос к словарю (типа к таблице SEG$, обычно она фигурирует в больших базах), который Вы и починили указанными параметрами оптимизатора optimizer_index_cost_adj, _hash_join_enabled и прочими (надеюсь, Вы их используете только в сессии, в которой вызываете процедуру DBMS_PARALLEL_EXECUTE.CREATE_CHUNKS_BY_ROWID, а не ко всему экземпляру). Соответственно, решением будет пересобрать статистику либо только по fixed objects, либо по всему словарю в целом: Код: plsql 1. 2.
(выполнять от SYS, конечно) ... |
|||
:
Нравится:
Не нравится:
|
|||
13.10.2021, 20:39 |
|
|
start [/forum/topic.php?fid=52&tid=1879824]: |
0ms |
get settings: |
16ms |
get forum list: |
5ms |
check forum access: |
1ms |
check topic access: |
1ms |
track hit: |
34ms |
get topic data: |
4ms |
get forum data: |
1ms |
get page messages: |
75ms |
get tp. blocked users: |
0ms |
others: | 296ms |
total: | 433ms |
0 / 0 |