ситуация, редко, но всё ещё случается,
поэтому хотелось бы почитать и разобраться.

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

заранее спасибо всем ответившим по существу

dbms_photoshop,

причины ошибки и способы борьбы/предупреждения более-менее ясны.

самый главный вопрос, что происходит в ядре сразу ПОСЛЕ ORA-00020?
особенно, если появляются свободные процессы, очереди размораживаются и "всё само-собой рассасывается" :)
желательно, пошагово на уровне системных процессов ...

ты прав, всё сводится к вопросу: "насколько можно доверять заданию, которое завершилось, вроде бы , без ошибок, но в процессе возникала пресловутая ORA-00020?"
тесты (длительные), само собой, проходят для результата "на ура", но это сегодня.
а завтра ORA-00020 случится в момент отката транзакции/порождения цепочки джобов и т.п.
и что? доверять результату, потому что в прошлый раз всё было гут? не факт.
значит снова полное тестирование результатов -- долго и накладно.

вот поэтом и обратился к сообществу за линками на доки
как-то так

dbms_photoshop,

положим, даже при глухом затыке новую сессию создать можно с -prelim и рестартануться :)
то есть, резервы есть всегда.

причины успешно поборены, но несколько раз в год случается казус -- звёзды, сэр.

вот пришла ORA-00020, и, получается, что процессов записать сие событие в алертлог уже недостаточно, но хватает для трейса...

как пример, всегда запрос выполнялся в 8 потоков, сейчас свободных 10/8/4.
как он себя поведёт в каждом таком случае?

вот про это бы прочитать где-то...

я правильно понял твоё экспертное мнение, что если задание успешно доползло до финиша -- на промежуточную ORA-00020 можно забить?

Вячеслав, спасибо.

то же вопрос к эксперту -- если задание успешно доползло до финиша -- на промежуточную ORA-00020 можно забить?
или есть нюансы?

SY, спасибо за помощь.

в этот момент интерактивых подключений нет, точно.

dbms_photoshop,

ок. данке.

благодарю всех ответивших, извините за задержку -- "продукцион"

Scott TigerСтруктурно Ваша ситуация развивается так: возникла потребность породить процесс -> проверили возможность -> наткнулись на лимит, не породили -> выдали ошибку. После выдачи ошибки ничего интересного не происходит.

ИМХО, самое интересное здесь только начинается.
я правильно понимаю, что цикл некоторое время повторяется?
...выдали ошибку -> подождали -> вернулись на проверку возможности породить процесс -> проверили возможность -> наткнулись на лимит, не породили -> выдали ошибку -> подождали -> вернулись на проверку возможности породить процесс...

и это продолжается, до того как:
1) появились свободные процессы, достаточные для старта -- и все счастливы;
2) по тайм-лимиту, когда ора-20 висит достаточно долго, начали отваливаться/не запускаться некие служебные процессы -- увы и ах!
(какие?)

к сожалению, не нашел ответа на вопрос "какой бэкграунд-процесс порождает данную ошибку?"
грешил на ресурс-менеджер, но, вроде, в доках написано, что если его не активировали, то он спит себе спокойно...
я хз.

и основной вопрос к гуру, если внедрено планирование ресурсов через ресурс-менеджер,
и ветка "продукцион", которой к примеру я выделю 80% процессов, упрётся в ограничения на свободные процессы уже по плану ресурс-менеджера,
в этом случае ора-20 возникает или нет?


@Scott Tiger
ST>Сильно не советую делать обработчик таких системных сбоев...
дык, до такого ещё не опустился... или не взлетел... :)

всем удачи и доброго здоровья

Благодарю всех ответивших.
Поздравляю с новым 2017-м годом.
Всем здоровья.

с ув. ITest