Re: Dbms_scheduler auto drop

  • From: Jure Bratina <jure.bratina@xxxxxxxxx>
  • To: Andrew Kerber <andrew.kerber@xxxxxxxxx>
  • Date: Mon, 27 Apr 2015 18:51:01 +0200

Hi Andrew,

The job probably doesn't get dropped automatically because of the behavior
described in: "Bug 8517144 : JOB WITH AUTO_DROP=TRUE AND MAX_RUNS=1 IS NOT
BEING DROPPED AUTOMATICALLY":


"The customer is right in
stating that if auto_drop is set to true and a job has reached is max_runs
is
set to 1, it must be automatically dropped at the end of the first run.
However, run_count and max_runs only applies to normally scheduled runs. It
does not apply to manual runs that are triggered through run_job().

It seems that in this case the scheduler is not used in its intended way.
You
do not use run_job() to get the job to run according to its normal
schedule.
You determine a schedule for a job and then enable() the job and then the
job
will run according to that schedule. That is the normal way to use the
scheduler. Run_job() is used to run an instance of the job outside its
normal
schedule. Job instances that are triggered through run_job() will not count
towards max_runs.
"

Out of curiosity, why do you have to explicitly run the job asynchronously
with run_job(use_current_session=>false) instead of simply scheduling it to
run immediately with create_job()? Additionally, if there are many such
one-time jobs, Lightweight jobs might be used instead:
http://docs.oracle.com/cd/E11882_01/server.112/e25494/schedover.htm#CHDECJDB
.

Regards,
Jure Bratina

Other related posts: