views:

340

answers:

4

It's probably just the vocabulary I am missing to find out how to do this:

A job scheduled to run regularly every 5 mins, however keeping track that there are never two instances of it running at the same time, i.e. the next instance would be postponed or skipped if the prior runs longs than 5 mins.

What is the easiest/most elegant way to achieve this?

+1  A: 

DBMS_JOB takes care of that. Just use it.

ammoQ
+1 for not re-inventing the wheel. Also, see the DBA_JOBS and DBA_JOBS_RUNNING views if you need to determine the last/next run information.
dpbradley
thanks a lot for your response.does it take care of avoiding two instances of the job running at the same time, too? if yes, which option should i use for this? this is what i did not manage to find out yet...
PeterP
IIRC, dbms_job will only run one at a time (you won't have two instances of a job running). Dbms_scheduler allows greater flexibility as to what to do on job failure.
DCookie
+1  A: 

From the Oracle 10g administrators guide:

"The DBMS_JOB package has been superseded by the DBMS_SCHEDULER package. In particular, if you are administering jobs to manage system load, you should consider disabling DBMS_JOB by revoking the package execution privilege for users."

DBMS_SCHEDULER is Oracle's recommended way to do this now. One advantage it has is that you can manage your jobs via Enterprise Manager/Grid Control if you're using this.

DCookie
A: 

an other advantage that dbms_scheduler has above dbms_job is that you can better control the load, resource usage and that you can also run jobs external to the database.

hth, Ronald.

ik_zelf
A: 

If for some reason dbms_job or dbms_scheduler doesn't work for you, you could also use DBMS_APPLICATION_INFO.SET_APPLICATION_INFO to set the module name of your job and you could query v$session to see how many sessions are currently executing that module.

What type of job is this? A PL/SQL stored procedure?

Plasmer
thanks for your reply, I think both of dbms_job and dmbs_scheduler would work for me, but somehow I do not seem to be smart enough to figure out how to avoid two jobs overlapping...
PeterP
btw: it's a stored procedure, yes
PeterP
You don't need to worry about jobs overlapping. Both scheduling mechanisms will only run one instance of a job at a time.
DCookie
-1 Sorry, this just won't work - in the time between when you query v$session, then call SET_APPLICATION_INFO, there's nothing stopping another process doing the same thing - you'll still end up with multiple sessions with the same APPLICATION_INFO. If the dbms_job/dbms_scheduler doesn't cut it, DBMS_LOCK does provide a way to create locks.
Jeffrey Kemp
Yes, this does not work well when there is a lot of concurrency, but if the job is only called every 5 minutes as the questioner mentioned, I don't believe this is a problem.
Plasmer