Re: Dbms_scheduler auto drop

From: Jure Bratina <jure.bratina_at_gmail.com>
Date: Mon, 27 Apr 2015 18:51:01 +0200
Message-ID: <CAC08BHJBh-2fq3M5Rc3v9hZ_ViQ1afBSm+xTDs_h1vF14Ar+Pw_at_mail.gmail.com>



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

--
http://www.freelists.org/webpage/oracle-l
Received on Mon Apr 27 2015 - 18:51:01 CEST

Original text of this message