ТЕМА:

Bubu пишет: Думаю с параллелизмом хорошего ничего не будет. Надо no_parallel(...) еще для каждой таблицы.

Вот с этим и проблема. Аппликейшн наращивает параллелизм, может будет быстрее выполняться, и уперся в то что весь процесс работает 20 часов на на лучшем железе с большим уровнем параллеизма. Раньше работал всего 8 часов. Да еще Async IO не включают.

Event Waits Time(s) Avg Wait(ms) % Total Call Time Wait Class
PX Deq Credit: send blkd 313,486 23,788 76 34.4 Other
db file sequential read 1,113,864 17,021 15 24.6 User I/O
CPU time 6,700 9.7
log file parallel write 15,691 771 49 1.1 System I/O
log file sync 13,602 328 24 .5 Commit

Наверно быстрее будет разобраться, чем ждать, Смущает выбор NDEX RANGE SCAN WC_PLANNED_VOLUMES_F_M2 и низкая стоимость, может у этого индекса, может конечно у индекса идеальный clustering factor, но я бы проверил настройки оптимизатора, например, вот так: select sql_id, name from v$sql_optimizer_env where sql_id = '...'

Так же интересны события ожидания во время выполнения запроса, в трассировке это же будет

Статы собираются
Попробую включить трейс, еще раз запустить запрос не получиться.
Еще узнал что статистика собрана была не по таблицам и запрошу ее собрать тоже

Group By нужен в подзапросе для уникальности.
Вообще странно что в плане нет столбцов связанных с параллелизмом, может быть по ошибке ormat был задан так, что опция parallel оказалась не включена.