Professional Documents
Culture Documents
OUAF Batch Scheduler Integration-1
OUAF Batch Scheduler Integration-1
Scheduler
Integration
Oracle Utilities Application Framework (4.4.0.0.0)
Basic Concepts............................................................................................................................ 7
Scheduler Integration................................................................................. 10
What are the licensing restrictions for the Oracle Scheduler? ....................................................25
Can I build a query to view the Oracle Scheduler objects from other users? .............................27
• Support for wide range of types of jobs. Allows for the scheduling of database program units (i.e.
PL/SQL anonymous blocks, pl/sql stored procedure and Java based stored procedures) as well as
external executables (i.e. applications, shell scripts and batch files). These scheduled objects can
be expressed as reusable programs or individual jobs. These can be mixed across products and
across technologies.
• Support for Local or Remote Execution. Execution of database program units and external
executable locally or remotely using Destinations and related Credentials.
• Flexible Scheduling. Scheduling is flexible with support for one or more of the following scheduling
methods:
– Time based scheduling. Scheduling job based upon dates and times including overlapping
calendars.
– Event based scheduling. Scheduling based upon dynamic events and file arrivals using File
Watchers and other event types including pl/sql events and Oracle AQ based events.
• Prioritization Support. Job Prioritization is supported based upon class of job and/or the schedule
itself.
• High Availability Support. Support for Oracle Maximum Availability Architecture including support
for Real Application Clustering.
• Effective Resource controls. Database resource usage controls using Database Resource Plans
and Windows.
• Native Database Support. Scheduler objects are dictionary objects so can be granted individual
object permissions, if desired.
For more information about the features of the Oracle Scheduler refer to the Oracle Scheduler
Concepts.
Basic Concepts
The Scheduler is a set of processes and objects that are defined and executed within the Oracle
Database. The Scheduler can be implemented within the same database as the product or remotely to
implement enterprise wide scheduling. Refer to Local or Remote Scheduling under Implementation
Guidelines for a discussion of each implementation option.
The lowest object in a scheduler is the Program. A program describes what is to be run by the schedule.
The program object includes a definition of the physical object as well as arguments to execute them.
An instance of a program, is a Job. The job is a collection of metadata that defines the program to
execute as well as where to execute it (for remote executions), its related schedule (which dictates
when it is executed) and any related information.
Jobs are subject to scheduling using the time based, event based and/or dependency of other jobs.
The Schedule object defines when and how many times the job is executed. The schedule object uses
a rich calendaring syntax to define repeating schedules. Jobs also contain data used for prioritizing as
well as resource profiles including support for Windows and Resource Manager.
Jobs can also be executed based upon events. These events can be based upon outcomes of SQL or
most commonly arrivals of files. The scheduler uses a File Watcher to detect when a file has arrived to
trigger the event.
Sequences of jobs expressing the dependencies are represented by Chains. Chains define steps which
link a job or file watcher and contains Rules to decide the sequence and outcomes based upon the
state of another job in the chain. For example, Job B needs to run only if Job A has completed
successfully. Chains can support multiple branches and chains can include other chains for greater
reuse.
The Oracle Scheduler supports remote invocation of jobs using configurations of Destinations and their
related Credentials to access that remote destination. These remote destinations must enable the
Oracle Scheduler Agent which is installed with the Database (for database destinations) or Oracle
Client installation (for non-database destinations).
To maximize reuse, the Oracle Scheduler also supports groups in the form of Destination Groups and
Window Groups.
Job
Event
File Watcher
Schedule
Time
Destination
Credentials
Remote Only
Management Capabilities
The Oracle Scheduler is maintained using several tools provided by Oracle:
• SQL Interface. At the base level, there is a DBMS_SCHEDULER package which is installed with the
database automatically. This interface is available to be used by any valid direct SQL interface such
as SQL*Plus or equivalent. This interface has a set of subprograms to allow maintenance of the
scheduler objects. This is recommended for Developers.
• Oracle SQL Developer. The Oracle SQL Developer (V4 and above) includes a set of wizards and
functions to maintain the schedule attached to a connected database (including DBaaS instances).
For example:
• Oracle Enterprise Manager. For customers using Oracle Enterprise Manager, there is a browser
interface to maintain the scheduler objects from the Administration menu on the appropriate
database target. For example:
Whichever interface has been used, will ultimately result in the execution of the DBMS_SCHEDULER
package.
Note: This Technical Brief will generically refer to object creation using the DBMS_SCHEDULER
interface. If an alternative is used, then adjust the advice to suit the tool.
Dictionary Views
The Oracle Scheduler creates a series of dictionary objects that contain the definitions of the various
scheduler objects. These dictionary objects are accessible from a series of views that can be used for
object management, to track progress of jobs for effective monitoring. Refer to the Scheduler Data
Dictionary Views for a detailed description of the views available.
Interface Components
The Oracle Scheduler integration interface is a set of components to implement a simple but powerful
interface reusing the batch infrastructure within Oracle Utilities Application Framework in conjunction
of the Oracle Scheduler. The interface consists of the following:
• Scheduler Administrator. A new database user, SCHADM by default, and set of Oracle Scheduler
roles to maintain and build the scheduler definitions. This user will own the schedule whether the
schedule is implemented locally in the products database or on a remote dedicated scheduler
database.
• Special Database objects. A set of database objects used by the interface on the product database
to control executions and set options.
• Permission sets. A set of SQL commands to enable permissions to product tables and individual
objects to implement the interface. As the Oracle Scheduler implements dictionary objects for
scheduler objects, then database object permission rules need to be applied (e.g. GRANT, REVOKE
etc).
The Installation Guide and DBA Guide shipped with your product outlines the installation process for
the scheduler interface.
Interface Architecture
The Oracle Scheduler interface has a flexible architecture that exploits the underlying features of the
product to execute and monitor background processes. From an architecture perspective the following
applies:
• The Oracle Scheduler objects are held as dictionary objects in the Schedule Administrator schema.
At a minimum the Oracle Scheduler uses Programs, Jobs and Chains. Other Schedule objects can
be defined as necessary.
• The Oracle Scheduler interface is installed on the product schema which includes several interface
tables, the OUAF_BATCH pl/sql package and permissions to product batch tables. If the product
database is remote to the Oracle Scheduler database then the Scheduler Agent must be enabled on
the server containing the product database and the appropriate Destinations and Credentials Oracle
Scheduler objects created.
• The product batch architecture must have a batch daemon enabled on one of the threadpools. The
batch daemon will monitor internal batch tables to detect when to initiate batch processes in the
threadpool cluster.
Interface Tables
Threadpool
Scheduler Agent (if remote)
Programs
Chains Threadpool
OUAF_BATCH
Threadpool
Jobs
Threadpool
Other Objects Batch Instance Tables
Threadpool
• The OUAF_BATCH.Submit_Job procedure is invoked from the Oracle Scheduler within the relevant
job definition either locally or remotely via the destination using the credentials provided. The job can
be part of a chain, manually initiated or because of a successful pre-configured event.
Note: Refer to the Server Administration Guide supplied with your product for details of the
OUAF_BATCH package.
• On the OUAF_BATCH.Submit_Job command there are several parameters that are specified,
including the batch control to execute. Any parameters explicitly or implicitly specified, are subject to
the precedence rules set out in Parameter Use Guidelines.
• The interface creates an entry within the CI_BATCH_JOB object in pending status, with an internal
identifier (generated using the DBMS_RANDOM package). Whilst this identifier is used internally, it can
also be used to cancel the job. The job is created with the following processing:
• Parameters are gathered from the various facilities using the processing sequence outlined in
Parameter Precedence.
• Each thread is individually submitted to the batch cluster to the threadpool specified in the options
or specified in the parameters.
• The batch daemon detects the Pending job entry in the CI_BATCH_JOB and submits the job to the
cluster using the threadpool configuration for the cluster and the threadpool derived for the
parameters for the execution.
Cancelling Jobs/Threads
Whilst in most of cases the execution of a scheduled job will be handled automatically, it may be
necessary to cancel a job or chain for some business or technical reason. The process of cancellation
will differ depending on the execution state of the job:
• If the job has not been executed yet, then use the STOP_JOB on the chain or pause the chain using
the DBMS_SCHEDULER package (directly or via the SQL Developer/Enterprise Manager interface).
• If the job is executing, then use the Cancel_Job procedure within the OUAF_BATCH package
specifying the Batch Control or generated job identifier to cancel the job. This can be issued from
any SQL compliant tool against the product database. Refer to the Server Administration Guide
supplied with the product for more information on the command line. The threads for the job will be
cancelled when the next poll of the status is performed according to the global poll interval.
When a running job is cancelled the identifier of the connection is attached to the cancellation for audit
purposes. This information is accessible from the batch run tree.
The Oracle Scheduler and Oracle Scheduler interface have many advantages over the command-
based interface:
• License free implementation. The Oracle Scheduler is provided in all editions of the Oracle
Database and is included in existing licenses. No additional licensing is required no matter how much
of the scheduler is used, how it is deployed or how many jobs are managed by the scheduler. This
assumes that the database housing the scheduler is already licensed.
• Less Administration. In the command-based utilities, parameters are either on command lines
and/or external properties files. This means any changes to the batch control by the business need
to be reflected in the properties files which is an additional administration step.
• Flexible Administration. Oracle supplies a set of flexible administration methods to the Oracle
Scheduler which can be command based, DBA tool based (via Oracle SQL Developer) or via Oracle
Enterprise Manager.
• Flexible implementation models. The Oracle Scheduler can live with the product or externalized
for centralized scheduling support. This implementation can be mixed as well with some
environments having local copies of their schedules and other environments sharing a global
scheduling instance.
• Increased Use of the Batch Controls. The Oracle Scheduler interface uses the Batch Control
parameters directly which mean that authorized users can maintain the parameters from the
business, local support or your IT personnel. The Batch Control maintenance function is subject to
authorization rules within the product.
• Reuse of Resource Profiles. Resource Profiles are supported in the Oracle Utilities Application
Framework which can be shared with the Oracle Scheduler to automate resource usage for
scheduling.
• Maximum Flexibility. The Oracle Scheduler can schedule simple and complex chains with flexible
scheduling.
The existing command line interface will continue to be supported and enhanced to give
implementations an alternative option if desired.
IMPLEMENTATION GUIDELINES
The Oracle Scheduler can be implemented in any number of ways to suit the way you want to use it
and the scope of the jobs managed by the scheduler. This section outlines some basic implementation
principles that may assist in the effective implementation of the scheduler. Also refer to the Additional
Resources outlined earlier for additional advice.
The Oracle Scheduler is popular with Oracle customers and is used in some of the Oracle products
that you may use already. There are lots of resources available with advanced advice that can be
access using an appropriate search engine using the terms Oracle Scheduler or DBMS_SCHEDULER.
Before discussing the implementation implications, it is important to understand the advantages and
disadvantages of the local and remote architecture:
• Oracle Scheduler can manage and schedule many types of jobs which can include database jobs
(such as backups), external jobs and interface jobs needed for an implementation. These jobs can
be housed in separate chains or integrated with product specific chains. Typically, it is recommended
to consider implementing Oracle Scheduler remotely as it makes it independent of the product and
provides an enterprise wide resource to implement these additional jobs.
• Implementing Oracle Scheduler remotely, in enterprise wide mode, does mean additional
configuration within the scheduler. The Oracle Scheduler Agent must be installed and active on any
server where work needs to be scheduled. Within the scheduler objects, each remote location must
be defined as a destination and the appropriate credentials of the job type must be configured so
that the scheduler can access the resources remotely. While enterprise scheduling is supported, it
is only recommended if this extra configuration is not burdensome.
• Implementing Oracle Scheduler locally is easier to configure, as it avoids destinations and agents,
and focuses on scheduling the product jobs. The schema would be housed in the product database
using a different schema owner.
The following guidelines should be considered when deciding to use local or remote scheduling:
• If your implementation is primarily using the scheduler for product jobs (and some simple associated
jobs) then consider using a local installation on the product database to avoid the extra effort in
remote management.
• If your implementation is considering enterprise wide scheduling, then the database agent on the
database server for the product must be configured and started. The product database must be
defined as a destination and the product user must be used as credentials. For Oracle Utilities
Application Framework V4.x and above customers, it is recommended to use the credentials
represented in the BATCH_DBUSER and BATCH_DBPASS configuration settings as credentials to
isolate batch processes for monitoring and take advantage of common resource plans, if used.
Ensure the BATCH_DBUSER has access to the OUAF_BATCH packages within the product schema.
Refer to the Installation Guide and DBA Guide shipped with your product for more advice.
It is possible to add custom jobs of several types into any schedule managed by the Oracle Scheduler.
Refer to the Oracle Scheduler Concepts for additional advice in this area.
• Set the default time zone. The schedule engine uses a default time to align schedules. This can be
overridden using the calendaring syntax for individual jobs and/or chains.
• Set the email attributes. One of the optional features is to configure an email server with various
settings that allows an email to be sent according to the specifications on the job or chain. The
interface supplies an OUAF_NOTIFY that is used as the default job to send the email, if necessary.
The attributes to specify include the email server URL, email server credentials and optional email
encryption settings.
• Set the event expiry time (in seconds). The Oracle Scheduler holds the state of any job for a
period to be used by the scheduler to cover long running processes or multi-day processes. The
state is held within the scheduler dictionary for use by the scheduler.
• Set log history retention period (in days). The Oracle Scheduler includes a basic log facility that
is retained in the dictionary views for perusal. Refer to the Monitoring Jobs for more details of the
logs. It is possible to set the period within the dictionary views on how long these records are retained
for analysis. This information can be set globally or set via Job Class.
The event expiry time and log history retention period only apply to the dictionary objects used by the
Oracle Scheduler. They do not apply to the data held in the batch run tree or the logs generated by the
batch jobs themselves. These are managed separately as outlined in the Server Administration Guides
shipped with your products.
Note: Refer to the Set_Option API documented in the Server Administration Guide supplied with
your product for additional advice
The following parameters are set using the Set_Option procedure of OUAF_BATCH using the
GLOBAL scope:
• Business Date (business_date). Set the global business date which will be used as the default
for all executions. Setting this value ensures the business date is used consistently across chains
regardless of time of day or date. If used, it is highly recommended to set this value at least once a
day either at the start of a chain or as part of an independent process. This value can be overridden
on individual jobs.
• User Identifier (user_id). This is the global authorization user within the product that will be used
for permissions of underlying objects. It is also used to mark any records created or modified by the
process for auditing purposes. This value can be overridden on individual jobs.
• Poll Seconds (poll_seconds). How often the interface will check with the product on the state of
the job. This poll interval will also determine how often a job cancel request will be checked for.
Note: By default, an individual thread that ends in error will trigger notification job OUAF_NOTIFY.
This is independent of the job's overall status (for all threads) or the raise_error option. Triggering
a notification for a thread in error allows the user to correct the problem and resubmit that thread
without interrupting the overall flow of the chain. The job will wait indefinitely for the job to reach the
status defined by min_run_status, so individual threads can be restarted while this condition is
not true. To disable it, set thread_notifications to false, but be aware that the job may then
appear to be running while it is in fact waiting for a thread to be resubmitted, so it is a clever idea to
keep an eye on the Batch Run Tree to monitor the threads.
• Default Thread Pool (thread_pool). The default threadpool if no threadpool is set for the
individual job.
• Discard Queue (discard_queue). Determines whether all unused online job queue entries are
removed. This is housekeeping for the interface to prevent batch instance records from overloading
the system. This does not affect batch run tree information.
• Single Submitter (single_submitter). By default, set to false, the interface submits a multi-
threaded job one by one. In implementations where there are many threads, this can cause
excessive lock contention on the Batch Control table. Setting this value to true will reduce lock
contention on a multi-threaded job.
For example:
begin
end;
• Consider setting the user_id and thread_pool to appropriate settings for your site. These can
be overridden on individual jobs as necessary.
• Leave most of the settings on the defaults unless the defaults are not appropriate for your site.
• To avoid long term storage issues consider leaving discard_queue to true to allow the interface
to manage its entries automatically. The records managed are internal only typically as the Batch
Run Tree information is not altered by this change.
• The notification engine used in the interface works only with failed threads. If this is not appropriate,
then disable the notifications from the interface and use the notification settings on individual jobs to
set your notification preferences. The format of the email can be altered per job if necessary with
appropriate events. For example:
Set raise_error to true to make the procedure raise an application error and end if the job ends
with that min_run_status. For example, to stop if a job ends in error, specify min_run_status =>
OUAF_BATCH.RUN_STAT_ERROR, raise_error => true.
Note: Option raise_error => true is not valid for min_run_status =>
OUAF_BATCH.RUN_STAT_COMPLETED.
State Values
STATE COMMENTS
RUN_STAT_PENDING Pending Status which is the initial state for all jobs before they execute.
Refer to Event Types Raised by the Scheduler for additional notifications events.
SCHEDULE GUIDELINES
The important aspect of implementing Oracle Scheduler is designing your scheduling solution that will
effectively schedule and manage your batch processes. The Oracle Scheduler is flexible and allows
chains to be designed to suit not only the raw dependencies but also to mirror your individual style of
IT management. In effect, there are typically many ways of achieving the same results. This section
will outline some general and specific techniques that can be used to build, maintain, operate and
optimize your scheduling objects.
General Guidelines
The Oracle Scheduler is powerful, flexible and has a wide range of capabilities. Whilst those capabilities
can be used with the interface there are several general guidelines that should be considered:
• Avoid using lightweight jobs for product jobs. The LIGHTWEIGHT job type is not recommended
for use with Oracle Utilities Application Framework based jobs.
• Avoid using detached jobs for product jobs. Detached jobs are processes that typically spawn
other processes that are independent of the scheduler. Avoid using that with product jobs.
• Respect the naming conventions of the objects. As the scheduler objects are dictionary objects
they are subject to Oracle dictionary naming conventions. For example, the Batch Controls contain
the "-" character and/or reserved words. These cannot be used in the object identifiers, such as Job
identifier. It is recommended that if you wish to use product identifiers, such as batch control
identifiers, then substitute "_" for the "-" character and prefix any reserved words to avoid naming
errors.
• Avoid loops in chains. One of the most common issues in scheduling, including within Oracle
Scheduler, is recursive chains. These are chains that loop back potentially causing an endless loop.
Avoid loops as much as possible.
• Ensure all jobs in a chain are linked. Each chain has a start and ending event job. Jobs within a
chain typically have predecessors and successors. In some chains you may have jobs that have no
predecessors or successors. It is recommended that these jobs be connected to either the start
event, if the job does not have predecessors and to the end event if they do not have successors.
Whilst, this is not required for execution it ensures all processes in a chain are started and complete
before the chain itself is complete.
• Start simple and alter as necessary. When designing a chain, it is always a pitfall to try and get it
setup fully featured schedules in the Oracle Scheduler. Most of the optimized chains tend to be
optimized over time to reflect ever changing business needs. The best approach is to start with the
simple dependencies and adjust those dependencies over time and add resource management after
examining the progress of the chain. This will then truly optimize the chain.
• Ensure objects are enabled. Ensure your scheduler objects are enabled before they are used. The
Oracle Scheduler will ignore objects that are not enabled. You can disable a job to alter it and then
set enabled to true when edits are complete.
• If the interface job is built using the same technology as the product, the batch control will be setup
and the OUAF_BATCH interface can be used the same as product jobs within the chain.
• If the interface job is built on different technology than the product the job can be setup as an External
Job within the chain. Refer to the External Job Guidelines for additional advice.
• If the job requires an event then use File Watcher, or general events as the attribute on the job.
• If the interface job is one that loads data into a staging table, then the next job in the chain is
recommended to be the product job that processes that loaded staging data.
• Destinations and Credentials. The job should be linked to the machine and operating system
credentials for the server that is running the process. It is possible to set global credentials in the
scheduler agent.
• Running Scripts. If the script is run using the product environment variables, then prefix the
command with the splenviron[.sh] -c <command> where the <command> is the command to
execute.
Threadpool Guidelines
The Oracle Scheduler interface does not support the execution and stopping of batch threadpools. This
is intentional as the management of thread pools can be performed from many options including cron,
Oracle Enterprise Manager etc. If the scheduler, is to be used to start and stop the thread pools then it
is recommended that the thread pools be managed using an external job. Refer to the External Job
Guidelines for advice.
Job Parameters
The scheduler interface allows for flexible implementation of parameters to batch jobs. The parameters
can be specified in several formats:
• Batch Specific Options. It is possible to provide specific parameters at the batch control level using
several techniques, described in the Parameter Precedence section.
• Command Line Overrides. For maximum flexibility, it is possible to override parameters at the
command line level to support advanced situations and special executions.
Parameter Precedence
The parameters for the scheduler interface are assessed in the following order (lower levels can
override upper levels):
• OUAF_BATCH defaults. The OUAF_BATCH interface sets a base set of parameters as indicated in
the Server Administration Guide supplied with the product.
• Global Options. It is possible to set options at the global level using the OUAF_BATCH.Set_Option
procedure with the GLOBAL scope. Refer to the Server Administration Guide supplied with the
product for details of the options that can be set.
• Batch Control settings. It is possible to set parameters for each product batch job on its associated
Batch Control record. Refer to the online documentation for details of the parameters that can be set
for individual batch jobs.
• Batch Specific Options. It is also possible to use the OUAF_BATCH.Set_Option procedure with
the scope set to the values of the Batch Control to set the options. Refer to the Server Administration
Guide supplied with the product for details of the options that can be set.
• Command Line Parameters. At the lowest level it is possible to override parameters at the
command line level using the parameters on the OUAF_BATCH.Submit_Job procedure. This level
supports several formats to specify the parameter for flexibility.
Set_Option Parameters
As part of the OUAF_BATCH package a procedure Set_Option is provided to set options for global
and the batch job levels. The options supported configure the behavior of the interface for the execution
of jobs as well as provide options for common parameters across jobs.
• Scope. The scope of the setting needs to be provided. For global options use the value GLOBAL and
for batch job specific options then specify the Batch Control Identifier.
• Option Name and Option Value. The option to set and the value to set it to for the option. Refer to
the Server Administration Guide shipped with your product for a full description of the options that
are available.
The values can be removed as options using the OUAF_BATCH.Unset_Option procedure. Refer to
the Server Administration Guide shipped with your product for more information about that procedure.
The parameters of a job can be specified on the command line using multiple formats for maximum
flexibility. The parameters may be specified in two formats:
declare
my_soft_parms OUAF_BATCH.parm_map_t;
begin
my_soft_parms('isRestrictedByBatchCode') := 'true';
end;
• In Memory Table Array (soft_parm_list). This is a table array of parameters and values. It is
specified as a list of name and value pairs. This may be convenient for jobs where the parameters
need to be directly specified in the job call. In this format the parameters must be of the type
OUAF_BATCH.parm_list_t. An example of this format is as shown:
begin
OUAF_BATCH.Submit_Job(
soft_parm_list =>
OUAF_BATCH.parm_list_t('maintenanceObject','F1-SYNC REQ',
'isRestrictedByBatchCode','true'));
end;
Both formats can be used in the same call. In this case, the soft_parm_list format may override
values set in the soft_parm_map.
• Set parameters at global level and use overrides for exceptions. To save maintenance costs it
is recommended to set the parameter at higher levels and only specify parameters at the lower levels
when overrides are necessary.
• Batch Controls are key for business parameters. The batch control object should be used to
maintain batch control specific business settings.
• Use the business_date GLOBAL option for handling past midnight scheduling. One of the
general issues in scheduling is the setting of a consistent business date for a chain. If the system
date is used, then if the chain extends over the midnight boundary then jobs past midnight may use
different business dates from those jobs running before midnight. To run a consistent business date,
it is recommended to set the business_date at the start of the chain using the GLOBAL option. For
example:
begin
);
end;
begin
);
end;
• Set a command line standard. If you want to specify parameters on the command line, decide on
the format that is comfortable for your implementation. For supported formats refer to the Soft
Parameters Formats for a discussion on supported formats.
Resource Optimization
Note: The use of resource optimization is optional but can be useful for flexibility in scheduling and
prioritization.
One of the techniques to use with the scheduler is resource management to implement prioritization
and management of resources. The key component of this is the ability to specify a set of resource
objects to control the jobs or chains use of database resources to optimize your schedule.
The product supports the use of resource manager at the connection level (including the session
variables as documented in the Server Administration Guide provided with your product). The resource
plans and other resource objects can be created independently of the schedule to control resources at
a global level. If the scheduler needs to use these resource objects they can be specified at the
following levels:
• Job Class. It is possible to set the resource plans for the group of jobs allocated a specific job class.
This is a general optimization technique to group jobs into resource groups that can be allocated
• Windows. It is possible to design windows which control which resource plan is used at specific
times. For example, it may be possible to create windows that define peak and non-peak times that
allocate different resource objects to control resources between different channels. These windows
are then allocated to schedules which are used for scheduling chains and/or jobs. It is also possible
to create several windows and group them as Windows Groups to allocate multiple windows to the
schedule.
• Optional. The use of resource management is optional. In this case all jobs in the scheduler are
treated with the same overall resource plans and overall priority.
• Keep it simple. The Job priority (job_priority) attribute of the jobs is a simple method of
prioritization. All jobs within the same job class, that run concurrently are treated the same unless
the job priority is used where the jobs with the highest priority (the value of the job_priority
parameter is lower) are given execution priority over other concurrent jobs in that class. Use of job
class with resource profiling is the simplest method after using priority.
• Use Windows for complex situations. If your schedules are all over the time period and overlap
with other channels it is recommended to use Windows for resource management to prevent one
channel taking over resources reserved for another. An example of this is the balance between online
and batch. If you need to run batch during peak online hours, then batch will potentially cause
contention issues if run without any resource management. In this case, it may be appropriate to
create a set of windows that describe peak and non-peak periods for online transactions and define
appropriate values for online and batch. This can ensure batch is kept within resource limits to
minimize contention during peak periods and given more resources at non-peak times.
Refer to Managing Resources with Oracle Database Resource Manager and Using the Database
Resource Manager to Manage Database Server Resources (Doc Id: 2067783.1) available from My
Oracle Support for more information.
Job Attributes
auto_drop FALSE Drop the internal scheduler objects after the job
has completed.
restartable FALSE This setting does not apply to product jobs as the
Restart_Thread API within OUAF_BATCH is
available.
Note: These API’s will only work when the scheduler objects are housed in the same database as the
product. Remotely implemented schedulers or remote objects are NOT supported.
Note: Refer to the Server Administration Guide for details of the Scheduler API's available for your
version of the Oracle Utilities Application Framework.
);
end;
Note: To use external procedures, ensure the product user used for the interface has appropriate
access to those procedures within the product database. Ideally, these procedures should be owned
by the database user used for executing the jobs to avoid permission issues.
• Using the OUAF_BATCH.Cancel_Job interface. It is possible to stop a running job and/or thread
using the Cancel_Job procedure. This will sent the job to a cancelled status and on the next poll
interval, cancel the job and/or thread from the batch cluster. After all threads are cancelled the job
will register the cancellation in the Batch Run Tree (with the conditions of the cancellation). Refer to
the Server Administration Guide for more information about the Cancel_Job interface.
• Using the JMX interface. It is possible to cancel a thread using the JMX interface using jconsole,
jmxbatchclient[.sh] or Oracle Enterprise Manager with the Application Management Pack for
Oracle Utilities. Refer to the Server Administration Guide for more information about this interface.
As with previous interfaces, the Batch Run Tree will record the relevant information of the
cancellation.
• Using SQL interface. This interface is not recommended and should only be used as a last resort,
but it is possible to stop the jobs using the SQL:
UPDATE CI_BATCH_JOB
COMMIT;
where:
EFFECTS ON CHAINS
Depending on the setup of the chain rules the chain will react differently to a job cancellation:
• If the chain rule has an end condition for a FAILED execution, then the chain will stop executing.
• If the chain rule is setup for a SUCCEEDED execution, the default, then the chain will be in a
STALLED state and must be manually set to resume.
• If the chain rule is setup for COMPLETED execution, then the next job in the chain will be executed.
Note: Avoid using the DBMS_SCHEDULER.stop_job procedure as while it will stop the chain it will
not stop the execution of the underlying process as the interface does not permit a call back to support
remote jobs. Use the OUAF_BATCH.Cancel_Job instead to avoid issues as that interface will stop the
job and send the FAILED status to the chain.
It is recommended to use the OUAF_BATCH.Restart_Thread job to restart the thread of the job
correctly. Do not use the OUAF_BATCH.Submit_Job as this may result in duplicates in the scheduler.
Refer to the Server Administration Guide for more information about these interfaces.
Can I build a query to view the Oracle Scheduler objects from other users?
While the Oracle Scheduler stores its objects in the dictionary supplied within the Oracle database and
that dictionary is accessible from views it may not be possible to create a view to query the scheduler
objects. Since the scheduler objects are stored as dictionary objects they are subject to database
security rules. For one user to see another user's objects they must be granted appropriate
permissions. An example set of permissions are outlined in Setting Oracle Scheduler Privileges section
of the Oracle Scheduler documentation. There are several recommendations:
• Permissions are set at database user level NOT product user level. Each product channel can have
different database users if desired. For each user to access the scheduler objects for the scheduler
user they must be granted permissions on individual objects.
• Avoid granting SCHEDULER_ADMIN role to users. It is a powerful role that should be treated as akin
to the DBA role.
• All scheduler objects used in GRANT should be fully qualified to avoid issues. Typically, scheduler
objects will be prefixed by the Scheduler administrator account. Refer to the GRANT statement for
full list of Job Scheduler Objects that are managed.
• Any dictionary views should use the USER, ALL or DBA prefix. If the user that owns the objects is
used for the query, then use the USER version of the view otherwise use the ALL version of the view
with the appropriate OWNER value.
The following summary of the subset of dictionary associated with the Oracle Scheduler is listed in the
Scheduler Data Dictionary Views section of the Administrating Oracle Scheduler documentation.
Worldwide Headquarters
500 Oracle Parkway, Redwood Shores, CA 94065 USA
Worldwide Inquiries
TELE + 1.650.506.7000 + 1.800.ORACLE1
FAX + 1.650.506.7200
oracle.com
CONNECT W ITH US
Call +1.800.ORACLE1 or visit oracle.com. Outside North America, find your local office at oracle.com/contact.
Copyright © 2007 - 2019, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only, and the contents hereof
are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed
orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any
liability with respect to this document, and no contractual obligations are formed either directly or indirectly by this document. This document may not be
reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior written permission.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or
registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of
Advanced Micro Devices. UNIX is a registered trademark of The Open Group. 0219
Batch Scheduler Integration - Oracle Utilities Application Framework
February 2019