Hi,

This can be happening due to multiple reasons.

1. Check if there is an executing background job in the same queue.

2. Check if the Default batch queue is enabled.

3. Check if the JOB_QUEUE_PROCESSES variable value is 0 using the below query. If it is change the value using the alter statement.

select value from v$parameter where name = 'job_queue_processes';

Alter statement:

ALTER SYSTEM SET JOB_QUEUE_PROCESSES = 20;

Refer the below thread for more information:

Best Regards,

Janith Ronaka

https://www.linkedin.com/in/janithronaka

Thanks @janithronaka 

The third solution fixed the issue.

Thanks,

JL

To be honest, if your job_queue_processes were set to 0, you probably had much bigger problems than customer order background jobs not releasing.

That would mean NONE of the background jobs set up in the system would ever execute automatically, including critical jobs that are set for system performance, like building/validating indexes, and many others.

How long were you operating in a system with no job_queue_processes available ?!

@SimonTestard   Thanks for your response.  Are you saying if I do the following?

select value from v$parameter where name = 'job_queue_processes';  return 0

and then,

Alter statement:

ALTER SYSTEM SET JOB_QUEUE_PROCESSES = 0;

It will no work? 

I ALTER SYSTEM SET JOB_QUEUE_PROCESSES = 20; and it works after couple of minutes.

Your question => How long were you operating in a system with no job_queue_processes available ?!

It was an TEST environment. It was probably with 0 maybe couple of week.

What is the reason to have JOB_QUEUE_PRECESSES = 0 or 20 ? If the value is zero probably my mean Background jobs will not work because. Am  I correct?

The solution to ALTER the job processes WILL work, the problem is more around the fact that you had to do that in the first place.

Job Queue Processes are the background database threads/processes that are used to execute jobs in the backend, including (but not limited to) background jobs.

If they’ve been set to zero, a lot of things, some possibly critical, wouldn’t be running, you can see them in the “Database Processes” screen in EE.

Thankfully, you just said it was in a TEST environment.

Did you recently get an update applied to the environment ? Are you managed cloud hosted by IFS?

This happened to us recently and IFS had make a mistake and set the job processes to zero during the delivery of an update and had forgotten to put them back to their original number.

@SimonTestard 

Did you recently get an update applied to the environment ?

No

Are you managed cloud hosted by IFS?

No

From your comment above “This happened to us recently and IFS had make a mistake and set the job processes to zero during the delivery of an update and had forgotten to put them back to their original number.”

I was wondering if the solution would be to first contact the business to temporarily stop using IFS, and then restart the servers, following the regular process of stopping all the IFS middleware servers first before restarting them. Could this resolve the issue? If this works, we may consider setting the command ALTER SYSTEM SET JOB_QUEUE_PROCESSES = 0;. I just want to ensure that this process is followed correctly in the PROD environment, and I want to be prepared in case it's necessary

What do you think about my above statement ?

Thanks,

JL

No, do NOT set the job queue processes to 0 ! They are required for proper utilization of the system and for the dbms scheduler to function!

Don’t do this! : ALTER SYSTEM SET JOB_QUEUE_PROCESSES = 0;

IF it is CURRENTLY set to 0, you want to set the job_queue_processes to a number HIGHER than 0, for instance (typically I run around 50-80 in a Prod environment, and 20 in a Non Prod environment).

So if it is CURRENTLY set to 0 (based on the result of the query  select value from v$parameter where name = 'job_queue_processes';) , do something like this:

ALTER SYSTEM SET JOB_QUEUE_PROCESSES = 50;