Добрый день.
Столкнулся с проблемой. Есть задача, которая обрабатывается в параллели в 10 потоков. Например на начало выполнения разбивается задача на 200 чанков, создаются 10 потоков, которые берут в обработку чанк, после завершения одного, переходят к следующему. И тут начинается самое интересное, в большинстве случаев все работает как описал. Но бывает, когда создались 10 потоков, но в итоге 9 потоков отвалились по окончании обработки чанка и к новому не перешли, и все сводиться в 1 поток, бывает в 2. В alert.log нет никаких упоминаний об аварийной завершении джоба в это время. Уже и пакет пересмотрел, но все упирается во внешние методы на С.

Элик спасибо.
Действительно проблема в определении следующего свободного чанка. Ребята не учли, что один и тот же чанк может быть взять разными потоками в одно и то же время. Т.е. если 2 потока освободились одновременно, то один возьмет новый чанк, а второй получит ошибку блокировки и скорее всего на верху стоит глушилка. В новых версиях они использовали
и переписали сам метод dbms_parallel_execute_internal.GET_RANGE под новую логику.

ElicFireXДействительноТы понял, что версию указывать немаловажно?
Да, согласен на все 100. Но у меня это воспроизводилось не у одного заказчика и на разных версиях, но у всех стояла меньше 11.2.0.4. Но теперь зная где ошибка, можно разврапить пакет dbms_parallel_execute_internal и посмотреть на метод GET_RANGE
Еще раз спасибо.
И еще, я поторопился с выводом об ошибке блокировки, 2-й поток просто бы получил пустой чанк CHUNK_ID и посчитал, что свободных чанков больше нет и завершил свою работу. И так со всеми чанками, я обратил внимание, что у меня чанки отваливались по одному, не сразу все сваливались, а продолжали работу какое-то время.