Re: HELP: DBMS_JOB QUESTION

Jurij,

Thanks for the 'not at all small' correction, and apologies to the group for helping to propagate another Oracle mythtake.

This demonstrates my primary implementation axiom:

    If it's important, don't believe it, prove it.     Even if I'm the one that said it.

Outline of proof:

    Create a small procedure which does something like:

        insert into t1 values (timestamp);
        dbms_lock.sleep(45);

    Submit this procedure as a job.

    Keep an eye on :

        last_sec, this_sec, next_sec
    for that job until the job starts, runs,     and completes.

    Note that on startup

        This_sec takes on a time which is written to your table     Note that on job completion

        Last sec becomes this_sec (as above)
        Next_sec becomes last_sec + your interval

    i.e. - the next run time is generated as the job starts.

    You can also observe that the the job queue process     re-starts it wait time as it finishes the processing the     last job in the queue.

    An interesting side-effect - if your job runs for long     enough, the 'next run time' can be in the past of the     current clock time - if so, the job does NOT restart     immediately it waits for the next startup of the     (next available) job queue process.

--

Jonathan Lewis
Yet another Oracle-related web site: http://www.jlcomp.demon.co.uk

Jurij Modic wrote in message <37e8e36b.3026159_at_news.siol.net>...

>A small correction, since this appears to be quite common
>misunderstanding:
>
>The "next time" of a job is not set at END of the job completion, it
>is computed as an offset from the START of the beginning of the
>current job execution. However it is true that this computed time of
>the next job run is "written" in the dictionary only after the
>completion of the current job run (ie it is not visible until the
>current run is completed).
Received on Wed Sep 22 1999 - 03:59:48 CDT