Use Chains, or PL/SQL Block of calls.

Question

I currently have a half dozen cron jobs that kick off different batches of processing. Originally, these were generally a sequence of C programs that did different operations (fetch student info from student record system and load into IdM system, process directory changes, etc). Over the years, most of the program logic has been rewritten as PL/SQL packages and the cron jobs basically drop into SQL*PLUS and do things like:
prompt "Do Spbpers delta"
execute simon.employee_maint.Spbpers_Delta;
commit;
prompt "Do People.Update_From_Employees"
execute simon.People_Maint.Update_From_Employees;
commit;
prompt "Do SGBSTDN_Full"
execute Simon.Bstudent_Maint.Sgbstdn_Full;
commit;
prompt "Do SPRIDEN_Full (Student)"
execute Simon.Bstudent_Maint.Spriden_Full;
These procedures generally connect to other Oracle databases and get or push data around, and are hitting a number of different databases. The biggest of these scripts has 45 execute statements in it. (This script started in 1992.....)
Anyway, we are getting some issues with and it is time to clean things up. This is my first foray into Scheduler and I am hoping to get some philosophical guidance on how best I should restructure things. One obvious thing, is to break up the big script into a couple of smaller ones. In some cases, order matters and in other, it doesn't - although I would prefer not to have several jobs hitting the admin system at the same time.
I have been playing a bit with the scheduler, mostly via the EM web interface, and have come up with a few questions - some pretty specific, others more stylistic.
1) Procedures as jobs - it seemed to want stand alone procedures, and NOT procedures that were part of a package. True?
2) How fine grained should I make the steps in a chain? For example, I call 5 procedures in the same package (student_maint), each to to some specific aspect of the processing (each represents a different source table). Should I create 5 programs, and make them 5 steps in the chain, or just have 5 calls in a PL/SQL block in one program?
3) I don't care what order these 5 run in, but I don't want more than one running at once - thoughts on approaches to this?
4) I will on occasion want to turn off sets of these tasks (like when the remote system is going to be down for an upgrade) - how best to structure things to make this easy to do (and how do I do this?)
The Scheduler system seems to be a very rich and flexible environment, with a lot more options and features than I need, but I feel I should do more than just scheduling a single program with 45 procedure calls in it....

Answer 1

Hi,
I can try to answer some of these questions
1) Procedures as jobs - it seemed to want stand alone procedures, and NOT procedures that were part of a package. True?
False. The EM interface does have this restriction, but if you use dbms_scheduler directly there is no such restrisction. Even in the EM interface you can workaround this by using a PL/SQL block which calls the package procedure (although argument handling is a little less flexible this way).
2) How fine grained should I make the steps in a chain? For example, I call 5 procedures in the same package (student_maint), each to to some specific aspect of the processing (each represents a different source table). Should I create 5 programs, and make them 5 steps in the chain, or just have 5 calls in a PL/SQL block in one program?
The answer to this depends on what you are doing. If the 5 steps run serially one after the other, using one pl/sql block may be easier. If you want some pieces to run in parallel, then creating a simple chain is better. A bit more effort spent setting up the chain will result in much faster execution times if you can run pieces in parallel.
3) I don't care what order these 5 run in, but I don't want more than one running at once - thoughts on approaches to this?
This has come up on the forum a few times and there are basically two different approaches. One is to use dbms_lock to ensure that only one runs at a time. This is the easiest way and the way that I recommend.
The other way is to set up a job class with a resource consumer group and put into effect a resource consumer plan that specifies that only one session from that resource consumer group can run at a time. This is easily extensible to cases where you want 2 or more running at a time from a certain job class (which dbms_lock doesn't support).
Code on how to set this up and more discussion is located here
Run Jobs One After Another
4) I will on occasion want to turn off sets of these tasks (like when the remote system is going to be down for an upgrade) - how best to structure things to make this easy to do (and how do I do this?)
Jobs and programs can be disabled. But if a job or chain tries to run a disabled program it will result in a failure (though it will be retried if you say that the job can be restarted).
[ 5) ] The Scheduler system seems to be a very rich and flexible environment, with a lot more options and features than I need, but I feel I should do more than just scheduling a single program with 45 procedure calls in it....
The Scheduler was intended to accommodate a wide range of usage from simple one-off background tasks to complex sequences of interrelated tasks. As with any other software development you should use it in the simplest way possible that does what you need it to do.
Hope this helps. Feel free to post any further questions.
-Ravi