Есть сторонний софт.
Некие процедуры в нем несмотря на транзакции
нельзя запускать одновременно с разных компов или даже одного компа.
Иногда такой запуск именно блокировками подвешивает второй комп,
или хуже этого, результат получается путанный.
Запуск с другого компа возможен только, если данная процедура ( или список процедур)
не запущены больше нигде. Те отработали до конца.
sql developer в пункте сессии дает два окна
Первое вверху = сессия, внизу конкретные sql
Для обоих окон запросы знаю.
Нужно нечто среднее между ними,
те функция с параметром , который получает имя процедуры или функции,
которые нужно проверить, а не запущены ли они еще где.
Главный ораклист приболел, помоложе такое не проходили.
Гритику , что не так нужно было делать, принять трудно, софт чужой.
Основополагающие вещи там менять нельзя, меняют только тексты расчетных процедур.
Заводить таблицу, куда записывать лог запуска не есть хорошее решение.
Иногда вторую висящую сессию с расчетом банально убивают. Поэтому поле окончание работы может быть не заполнено.

rwijk.blogspot.com.by
Если подойдёт по версии оракла... Ну и если DBA согласится сделать - там права нужны полные (хотя с чего бы ему быть против, если УЖЕ такое г*но творится в БД )

Но я всё же расстрелял бы для начала разработчиков таких приложений

Игорь, спасибо, сейчас посмотрю.
Насчет прав и так понятно.
Насчет аутодафе, это народ с другой зарплатой.
Если бы не эти, то другие. У них главный - правильный чел.
До него не дотянуться. Когда Форда после выпуска его первых авто
спросили, какие вы можете предложить цвета, он ответил-любые,
при условии, если вы выберете черный цвет.
Не мы решаем, что и где купить. Купили черный цвет,
потому, как в правильном месте был только черный,
а другие места просто неправильные.
На самом деле вопрос не такой и простой.
Вот есть некий расчет, выполняющийся неким числом процедур из
пакета. Идет он, допустим минут 20. На фоке когда-то такое шло
секунд 25. Результат по мере расчета пишется в не одну таблицу.
Если это одна транзакия, то второй аналогичный расчет вполне может висеть
эти 20 минут, ожидая светофора.

Расчёт (тот что запущен вторым) и ДОЛЖЕН висеть ожидая коммита/отката первой транзакции. В этом смысл поддержания согласованности. И в результате такого "паровозика" НЕ ДОЛЖНО возникать

boba
хуже этого, результат получается путанный.

Это уже очевидный косяк соответствующего кода - значит он либо не в одной транзакции это делает, либо не блокирует специально "входящие в результат, но не изменяемые при расчёте" записи, либо от запуска к запуску меняет разные записи в этих "итогово-расчётных" таблицах, либо не тот уровень сериализации транзакций применяет...
При большом желании можно так закодировать сей расчёт, что он хоть и будет работать очень долго, но блокировать записи начнёт лишь в самом конце, когда будет сбрасывать уже просчитанный результат в таблицы. До того храня его во временных таблицах или вообще в динамических структурах в памяти - типа коллекций или других pl/sql-ных структурах.
Это позволит спокойно запускать хоть 50 раз этот расчёт (разными пользователями, т.е. в разных сессиях) - ничего не будет блокироваться, просто будет зазря считать, а потом перезаписывать только что посчитанное
Конечно, если эти 20 минут не есть чистое время на запись, запись и ещё раз запись Т.е. если процесс расчёта не генерирует 100500Гб разнообразных данных...