| Oracle Scheduler
Updated May 5 2004
| Does the scheduler support job dependencies?
Can the GET_JOB_ARGUMENT_VALUE procedure also retrieve arguments set with the SET_JOB_ANYDATA_ARGUMENT_VALUE procedure?
Can the information written to the job log be customized?
Can the name of the job be retrieved from within the job?
Does the Scheduler support instance affinity?
When would you use the SCHEDULER_ADMIN role instead of the MANAGE SCHEDULER system privilege? What are the advantages of using one over the other?
Will the output from dbms_output go to the job log?
Does the Scheduler have support for daylight saving time?
What are the Scheduler attributes?
What privilege is required to manage Scheduler attributes?
From within a job while it is running it is possible to disable the job so that its next run will not happen?
Can the MANAGE SCHEDULER privilege be granted to any user or does the user have to have DBA privileges?
Can the job metadata be modified from within the job? Can the job attributes be changed from within the job while it's running?
What are the object privileges that can be granted on a job?
How does retry work with Oracle Scheduler?
Which platforms support external jobs?
Not in 10gR1.
There is no get_job_argument_value call. Argument values are be visible through the *_scheduler_job_args views.
No. The Scheduler supports Service �affinity� but not instance affinity.
Let's assume a cluster has 5 nodes. Service A consists of nodes 1 and 2 and Service B consists of nodes 3, 4 and 5. You can specify that a job class has service affinity for Service B. This means that the jobs belonging to that job class will ONLY run on nodes 3, 4 or 5.
At the job level you can specify Instance Stickiness. This implies that the Scheduler will attempt to run a job on the instance that it last ran on. However if this is not possible (instance is either down or overloaded) the job will run on another instance.
The MANAGE SCHEDULER privilege allows a DBA to control resources associated with the scheduler (create and maintain windows, window groups and classes) and to set system-wide scheduler settings (set_scheduler_attribute) and to forceably kill jobs.
The SCHEDULER_ADMIN role includes these privilege as well as ALL other scheduler system privileges. It would allow a user to execute any program, execute any class, create jobs, programs and schedules in anyone's schema (except SYS)and do anything that MANAGE SCHEDULER allows.
Because it allows the creation of jobs in any schema, it allows the running of PL/SQL code as any user (except SYS). This makes it a very powerful role, which should be granted with caution.
No. The Scheduler does not track output from jobs.
Yes. You must set the DEFAULT_TIMEZONE scheduler attribute if you want your job or window to follow daylight savings adjustments. For instance, if your database resides in Paris, you would set this to 'Europe/Warsaw'. Daylight saving adjustments will not be followed if you specify an absolute offset, for instance '-8:00' would only be correct for half of the year in San Francisco. If no value is specified for this attribute, the scheduler uses the time zone of systimestamp when the job or window is enabled. This is always an absolute offset and will not follow daylight savings adjustments.
Default_timezone, Log_history, Max_job_slave_processes
The MANAGE SCHEDULER privilege is required.
Yes. Using the SET_ATTRIBUTE call, you can disable the job
This privilege can be granted to anybody but is meant for somebody that is a DBA type person, i.e. one that manages the behavior of the scheduler. You do not need DBA privileges as well.
Yes, job attributes can be changed using the SET_ATTRIBUTE call.
Jobs will be retried a max 6 times or until the next scheduled date of the job. First retry will be after 1 sec then after 10 sec, then 100 sec and so on until one day.
Supported: Solaris64, Linux, HP64, TRU64, IA64 HP, IA64 Linux, Solaris x86, MAC, z/Linux, AMD, Windows.
Not supported: OS390, AIX