Named Schedules
Calendar strings provide a very helpful tool for specifying the schedule for executing your jobs. But suppose you have several jobs that run at the same time—for example, you might be collecting optimizer statistics for several tables. Here is an excerpt from the data dictionary view showing the schedule for these jobs:
SQL>SELECT job_name, repeat_interval2FROM dba_scheduler_jobs;JOB_NAME REPEAT_INTERVAL ------------------------------ ------------------------------ TABSTAT_ACCOUNTS FREQ=DAILY; BYHOUR=3 TABSTAT_SAVINGS FREQ=DAILY; BYHOUR=3 TABSTAT_CHECKING FREQ=DAILY; BYHOUR=3 ... and so on ...
Notice that the jobs have all the same calendar string, “FREQ=DAILY; BYHOUR=3”, which indicates execution at 3:00 A.M. every day. Now, suppose you want to change the timing to 4:00 A.M. instead of 3:00; what will you have to do?
You will have to go through each job painstakingly and change the calendar string. The more jobs you have, the more work you have to do—it will be a very tedious experience, and it will also be very prone to error. These are the drawbacks to any hardcoding inside an application.
The Scheduler gives you another option that helps you avoid this hardcoding. It allows you to create a named schedule, which all of your jobs can reference. If you use a named schedule, you won’t need to explicitly state the calendar string; maintenance of your schedules will be much simpler. Let’s see how this works.
Using the CREATE_SCHEDULE procedure , I can create a schedule ...