Skip to main content
Solved

Does background jobs with queue_id=4 get prioritized?

  • January 4, 2021
  • 10 replies
  • 430 views

Forum|alt.badge.img+14

Hi all,

I have noticed that if I run a background job with queue_id=4 (Touch apps push), it with execute within a few seconds.

I have now created a new queue (9) with the same parameters as 4 and it always execute much slower.

 

Can anyone explain why and what to do about it (20 sec is sometimes too slow)?

Best answer by kathlk

Search for “Database Processes” in EE and open the screen. You will see one row per each batch queue. First compare  values for Database Process Queue 4 and 9  (Job Action looks like ‘Transaction_SYS.Process_All_Pending__(<Queue Id>,'<Queue Name>','%',job_id_)’).

Re inti batch Queue can be done via a RMB option in the batch queue screen.

This topic has been closed for replies.

10 replies

kathlk
Hero (Employee)
Forum|alt.badge.img+14
  • Hero (Employee)
  • January 4, 2021

Hi Hans;

Start time of a BG job is depends on how many other pending jobs are queued in the same Batch Queue. Even batch queue configuration is the same, no of BG jobs in the queue might be not the same (may be you can verify that) ?  If you do not have any Touch Apps installed on this environment, then there is no load on Queue 4. it fetch your jobs quick.  may be you can compare it. 


Thanks

Kapila 


Forum|alt.badge.img+14
  • Author
  • Hero (Partner)
  • January 4, 2021

I am on a test environment. There is nothing in either queue 4 or 9 when jobs are posted. They jobs are running the same procedure. Still, there is a considerable difference.

Transaction_Sys.Deferred_Call(
procedure_name_ => 'INDUFLEX_ESTIMATE_API.Set_Transfer_Part_No',
argument_type_db_ => 'PARAMETER',
arguments_ => attr_,
description_ => 'hja',
queue_id_ => 9
);

Transaction_Sys.Deferred_Call(
procedure_name_ => 'INDUFLEX_ESTIMATE_API.Set_Transfer_Part_No',
argument_type_db_ => 'PARAMETER',
arguments_ => attr_,
description_ => 'hja',
queue_id_ => 4
);

 


kathlk
Hero (Employee)
Forum|alt.badge.img+14
  • Hero (Employee)
  • January 4, 2021

Can you check the Database Process relevant to each queue. Before doing you can re init both batch queues at the same time. Then the values in database process will start from 0. I would like to see the Priority, Runs  and Execution Interval columns where you can match values in queues.  


kathlk
Hero (Employee)
Forum|alt.badge.img+14
  • Hero (Employee)
  • January 4, 2021

May be check the values before In it batch Queue. I would expect two different Execution Intervals there in the Db Process. 


Forum|alt.badge.img+14
  • Author
  • Hero (Partner)
  • January 4, 2021

Hi @kathlk 

Can you further explain how todo these?

check the Database Process relevant to each queue

 

 re init both batch queues

 

 


kathlk
Hero (Employee)
Forum|alt.badge.img+14
  • Hero (Employee)
  • Answer
  • January 4, 2021

Search for “Database Processes” in EE and open the screen. You will see one row per each batch queue. First compare  values for Database Process Queue 4 and 9  (Job Action looks like ‘Transaction_SYS.Process_All_Pending__(<Queue Id>,'<Queue Name>','%',job_id_)’).

Re inti batch Queue can be done via a RMB option in the batch queue screen.


Forum|alt.badge.img+14
  • Author
  • Hero (Partner)
  • January 4, 2021

Yes, the execution plan is different

 

 


Forum|alt.badge.img+14
  • Author
  • Hero (Partner)
  • January 4, 2021

‘Init batch queue’ did the job.  

Thanks a lot.


kathlk
Hero (Employee)
Forum|alt.badge.img+14
  • Hero (Employee)
  • January 4, 2021

Good job :grinning:


durette
Superhero (Customer)
Forum|alt.badge.img+19
  • Superhero (Customer)
  • January 5, 2021

I've run into a strange issue a couple times that is somewhat related, and the solution might be worth sharing here...

After killing a blocking session, initializing the batch queue failed:

"One or more batch jobs are currently running. If you still need to initialize the queue, first break the running jobs from Database Processes windows and retry"

At the Oracle level, the job was in a weird state. It couldn't be disabled because it looked like it was running, but it couldn't be stopped because it looked like it was disabled. (If this wasn't production, I would have loved to restart the server to get back to a clean slate.)

The solution looked something like this:

BEGIN
   dbms_scheduler.enable('F1JOB_128');
   dbms_scheduler.stop_job('F1JOB_128');
   dbms_scheduler.disable('F1JOB_128');
END;
/

(We ran into this a few times on 11.2.0.3, and now that I think of it, I can’t remember seeing it since we upgraded to 12.1.0.2.)