0

We have a dbms_parallel_execute task that calls a stored procedure using department ids as chunk's start/end ids. If we run this task, we see chunks at specified parallel level get started with status ASSIGNED.

However, in session window, we see all those chunks are frozen at one select statement, making them run for hours. This is strange, because if we run the stored procedure alone in test window, it takes minutes to run.

Furthermore, if we create dbms_scheduler jobs for each department with job action calling that procedure, instead of using parallel task, all those jobs are running stable and getting finished quickly.

What could be the reason that the same procedure runs differently when executed by dbms_parallel_execute task and dbms_scheduler job?

Sherzodbek
  • 170
  • 1
  • 20
  • 3
    when they are "frozen" check v$session or v$sesswait for the worker sessions - presumably they are stuck on something – Connor McDonald Aug 08 '23 at 06:35
  • 1
    There's absolutely no way to help with this since there's no any line of code and there's no info about wait events in the question. Please edit it and add some insights to help us help you. Standalone code works well because things behave differently in the concurrent environment, and this is most probably design issue. Parallel jobs are not different from "regular" jobs: they are regular jobs generated by the `dbms_parallel_execute` package – astentx Aug 08 '23 at 06:55
  • Impossible to help without code, but I once had a similar experience and it was caused by locking that caused dml statements to wait for each other. – doberkofler Aug 08 '23 at 07:11
  • Thanks all for insights, apologies, I will include information about wait events, I didn't before since I wasn't sure what to look at. – Sherzodbek Aug 08 '23 at 09:20

0 Answers0