This content has been marked as final. Show 2 replies
The graceful stop mechanism for dbms_scheduler was designed so that it could not be trapped or intercepted. So it is a bit strange that a graceful stop_job doesn't work on your job (though certainIO opertions are uninterruptible) . But this also makes it difficult to do what you want to do in the job itself.
Once the job has been stopped however, that is recorded in the SCHEDULER_JOB_LOG and SCHEDULERJOB_RUN_DETAILS views so maybe you could get the information from those views.
That makes sense. If it wasn't done that way then people could write uninterruptible jobs that could hang systems.
It's a pity there isn't an "even more graceful" version that can be trapped. Then if that doesn't work the "graceful" can be used, and if that doesn't work then the force version can be used.
I reckon my procedure was in the middle of a large DELETE operation which is probably why the graceful stop didn't have any effect.
I think I've decided to just deal with the concequences of calling STOP_JOB manually since (as far as I know) it will only be done by a human. Any other issue should raise an exception and be dealt with in the code.