OCA /OCP Oracle Database 11g A ll-in-One Exam Guide- P86 doc

--- --- --- ---PROGRAM_NAME VARCHAR2 IN PROGRAM_TYPE VARCHAR2 IN PROGRAM_ACTION VARCHAR2 IN NUMBER_OF_ARGUMENTS BINARY_INTEGER IN DEFAULT ENABLED BOOLEAN IN DEFAULT COMMENTS VARCHAR2 IN

There will be many occasions when you as DBA, or your users, need to automate the scheduling and running of jobs These jobs could be of many kinds—for example, maintenance work, such as database backups; data loading and validation routines; report generation; collecting optimizer statistics; or executing business processes The Scheduler is a facility that can be used to specify tasks to be run at some point (or points) in the future The jobs can run within the database, on the machine hosting the database instance, or even on a remote machine

The Scheduler can be coupled to the Resource Manager It can activate Resource Manager plans and run jobs with the priorities assigned to various Resource Manager consumer groups

The Scheduler was introduced in release 10g of the Oracle database and is

substantially enhanced in release 11g In earlier releases of the database, job

scheduling capabilities were provided through the DBMS_JOB facility This is still supported for backward compatibility, but it is not as versatile as the Scheduler

The Scheduler Architecture

The data dictionary includes a table that is the storage point for all Scheduler jobs You can query this table through the DBA_SCHEDULER_JOBS view The job queue coordinator background process, the CJQ0 process, monitors this table and when

necessary launches job queue processes, the Jnnn processes, to run the jobs The CJQ0

process is launched automatically if there are any defined and active Scheduler jobs

The Jnnn processes are launched on demand, though the maximum number is limited

by the JOB_QUEUE_PROCESSES instance parameter, which can have any value from zero to a thousand (the default) If set to zero, the Scheduler will not function

The job queue coordinator picks up jobs from the job queue table and passes them to job queue processes for execution It also launches and terminates the job queue processes on demand To see the processes currently running, query the

V$PROCESS view:

SQL> select program from v$process where program like '%J%';

PROGRAM

-oracle@vblin1.bplc.co.za (CJQ0)

oracle@vblin1.bplc.co.za (J000)

oracle@vblin1.bplc.co.za (J001)

This query shows that the job queue coordinator and two job queue processes are running In a Unix instance, the processes will be separate operating system processes (as

in this query); in a Windows instance they execute as threads within the ORACLE.EXE process

EXAM TIP The JOB_QUEUE_PROCESSES instance parameter must be

greater than zero or the Scheduler cannot run It is 1000 by default The job queue coordinator will always be running if there any defined and active jobs

Jobs defined as procedures run within the database Jobs can also be defined as

operating system commands or shell scripts: these will run as external operating system

tasks The triggering factor for a job can be a time or an event Time-based jobs may

run once, or repeatedly according to a schedule Event-based jobs run when certain

conditions arise There are some preconfigured events, or you can use user-defined

events Jobs can be connected into a chain, using simple rules for branching depending

on a job’s success or failure

An advanced feature of the Scheduler is to associate it with the Resource Manager

It may be that certain jobs should be run with certain priorities, and this can be achieved

by linking a job to a Resource Manager consumer group It is also possible to use the

Scheduler to activate a Resource Manager plan, rather than having to activate a plan

manually by changing the RESOURCE_MANAGER_PLAN instance parameter or using

the DBMS_RESOURCE_MANAGER.SWITCH_PLAN procedure call

The Scheduler can be configured with an API—the DBMS_SCHEDULER package—

and monitored through a set of data dictionary views, or it can be managed with

Database Control

Scheduler Objects

The most basic object in the Scheduler environment is a job A job can be completely

self-contained: it can define the action to be taken, and when to take it In a more

advanced configuration, the job is only a part of the structure consisting of a number

of Scheduler objects of various types

Jobs

A job specifies what to do, and when to do it

The “what” can be an anonymous PL/SQL block (which could consist of just a

single SQL statement), a PL/SQL stored procedure (which could invoke a Java stored

procedure or an external procedure), or any executable file stored in the server’s file

system: either a binary executable or a shell script A particularly powerful capability

(beyond the scope of the OCP curriculum) is the remote external job, which runs on

a separate machine

The “when” specifies either the timestamp at which to launch the job and a repeat

interval for future runs, or the triggering event

There are several options when creating a job, as can be seen from looking at the

DBMS_SCHEDULER.CREATE_JOB procedure This procedure is overloaded; it has

no less than six forms Figure 22-1 shows part of the output from a DESCRIBE of the

DBMS_SCHEDULER package, showing the first three forms of CREATE_JOB

All forms of the CREATE_JOB procedure must specify a JOB_NAME This must be

unique within the schema in which the job is created Note that jobs are schema objects

Then, taking the first form of the procedure, the JOB_TYPE must be one of

PLSQL_BLOCK, STORED_PROCEDURE, EXECUTABLE, or CHAIN If JOB_TYPE

is PLSQL_BLOCK, then JOB_ACTION can be either a single SQL statement or a

PL/SQL block If the JOB_TYPE is STORED_PROCEDURE, then JOB_ACTION must

name a stored procedure, which can be anything that conforms to the PL/SQL call specification: a PL/SQL stored procedure, a Java stored procedure, or an external procedure written in C If the JOB_TYPE is EXECUTABLE, then the JOB_ACTION can

be anything that could be run from an operating system command-line prompt: an individual command, an executable binary file, or a shell script or batch file If the JOB_TYPE is CHAIN, then the steps of the chain will be defined separately The NUMBER_OF_ARGUMENTS parameter states how many arguments the JOB_ACTION should take

The first form of the procedure, shown in Figure 22-1, continues with details of when and how frequently to run the job The first execution will be on the START_ DATE; the REPEAT_INTERVAL defines a repeat frequency, such as daily, until END_ DATE JOB_CLASS has to do with priorities and integration of the Scheduler with the

Figure 22-1 The specification of the CREATE_JOB procedure

Resource Manager The ENABLED argument determines whether the job can actually

be run Perhaps surprisingly, this defaults to FALSE If a job is not created with this

argument on TRUE, it cannot be run (either manually, or through a schedule) without

enabling it first Finally, AUTO_DROP controls whether to drop the job definition

after the END_TIME This defaults to TRUE If a job is created with no scheduling

information, it will be run as soon as it is enabled, and then dropped immediately

if AUTO_DROP is on TRUE, which is the default

The second form of CREATE_JOB shown in Figure 22-1 creates an event-based job

The EVENT_CONDITION is an expression based on the definition of the messages

enqueued to the queue table nominated by the QUEUE_SPEC argument Between the

start and end dates, Oracle will monitor the queue and launch the job whenever a

message arrives that conforms to the condition

The third form of the CREATE_JOB procedure has the job details replaced with a

PROGRAM_NAME that points to a program, which will provide these details, and the

scheduling details replaced with a SCHEDULE_NAME that points to a schedule, which

will manage the timing of the runs

Programs

Programs provide a layer of abstraction between the job and the action it will perform

They are created with the DBMS_SCHEDULER.CREATE_PROGRAM procedure:

PROCEDURE CREATE_PROGRAM

Argument Name Type In/Out Default?

- - -

-PROGRAM_NAME VARCHAR2 IN

PROGRAM_TYPE VARCHAR2 IN

PROGRAM_ACTION VARCHAR2 IN

NUMBER_OF_ARGUMENTS BINARY_INTEGER IN DEFAULT

ENABLED BOOLEAN IN DEFAULT

COMMENTS VARCHAR2 IN DEFAULT

By pulling the “what” of a job out of the job definition itself and defining it in a

program, it becomes possible to reference the same program in different jobs, and

thus to associate it with different schedules and job classes, without having to define

it many times Note that (as for a job) a program must be ENABLED before it can be

used; the default for this is FALSE

Schedules

A schedule is a specification for when and how frequently a job should run The basic

principle of a schedule is to pull out the “when” portion of a job out of a job, thus

associating it with different jobs It is created with the DBMS_SCHEDULER.CREATE_

SCHEDULE procedure:

PROCEDURE CREATE_SCHEDULE

Argument Name Type In/Out Default?

- -

-SCHEDULE_NAME VARCHAR2 IN

START_DATE TIMESTAMP WITH TIME ZONE IN DEFAULT

REPEAT_INTERVAL VARCHAR2 IN

END_DATE TIMESTAMP WITH TIME ZONE IN DEFAULT

The START_DATE defaults to the current date and time This is the time that any jobs associated with this schedule will run The REPEAT_INTERVAL specifies how frequently the job should run, until the END_DATE Schedules without a specified END_DATE will run forever

The REPEAT_INTERVAL argument can take a wide variety of calendaring expressions These consist of up to three elements: a frequency, an interval (defaulting to 1), and possibly several specifiers The frequency may be one of these values:

YEARLY

MONTHLY

WEEKLY

DAILY

HOURLY

MINUTELY

SECONDLY

The specifiers can be one of these:

BYMONTH

BYWEEKNO

BYYEARDAY

BYMONTHDAY

BYHOUR

BYMINUTE

BYSECOND

Using these elements of a REPEAT_INTERVAL makes it possible to set up

schedules that should satisfy any requirement For example,

repeat_interval=>'freq=hourly; interval=12'

will run the job every 12 hours, starting at the START_DATE The next example,

repeat_interval=>'freq=yearly; bymonth=jan,apr,jul,oct; bymonthday=2'

will run the job on the second day of each of the named four months, starting as early

in the day as resources permit A final example,

repeat_interval=>'freq=weekly; interval=2; byday=mon; byhour=6; byminute=10' will run the job at ten past six on alternate Mondays

Using programs and schedules normalizes the job structure, allowing reuse of predefined programs and schedules for many jobs, as shown in Figure 22-2

Job Classes

A job class is used to associate one or more jobs with a Resource Manager consumer group, and also to control logging levels Create a class with the DBMS_SCHEDULER CREATE_JOB_CLASS procedure:

PROCEDURE CREATE_JOB_CLASS

Argument Name Type In/Out Default?

- - -

-JOB_CLASS_NAME VARCHAR2 IN

RESOURCE_CONSUMER_GROUP VARCHAR2 IN DEFAULT

SERVICE VARCHAR2 IN DEFAULT

LOGGING_LEVEL BINARY_INTEGER IN DEFAULT

LOG_HISTORY BINARY_INTEGER IN DEFAULT

COMMENTS VARCHAR2 IN DEFAULT

The JOB_CLASS_NAME is the name to be referenced by the JOB_CLASS argument

of the CREATE_JOB procedure The RESOURCE_CONSUMER_GROUP nominates the

group whose resource allocations should be applied to the running job, as determined

by the Resource Manager plan in effect whenever the job happens to run The SERVICE

has significance only in a RAC database: you can restrict the job to run only on an

instance offering a particular service name The details of logging can also be specified

per class

Windows

A schedule specifies exactly when a job should be launched Windows extend the concept

of schedules, by giving Oracle more freedom to decide when to run the job A window

opens at a certain time and closes after a certain duration: jobs specified to run in a

window may be launched, at Oracle’s discretion, at any time during the window The

window itself can open repeatedly according to a schedule Use of windows is of

particular value when combined with classes and the Resource Manager: Oracle can

schedule jobs to run within a window according to their relative priorities Windows

also activate Resource Manager plans

Figure 22-2 The relationships between Scheduler and Resource Manager objects

Create windows with the DBMS_SCHEDULER.CREATE_WINDOW procedure: PROCEDURE CREATE_WINDOW

Argument Name Type In/Out Default?

- - -

-WINDOW_NAME VARCHAR2 IN

RESOURCE_PLAN VARCHAR2 IN

START_DATE TIMESTAMP WITH TIME ZONE IN DEFAULT

REPEAT_INTERVAL VARCHAR2 IN

END_DATE TIMESTAMP WITH TIME ZONE IN DEFAULT

DURATION INTERVAL DAY TO SECOND IN

WINDOW_PRIORITY VARCHAR2 IN DEFAULT

COMMENTS VARCHAR2 IN DEFAULT

The RESOURCE_PLAN nominates the Resource Manager plan that will be activated when the window opens The window will open on the START_DATE and reopen according to the REPEAT_INTERVAL until the END_DATE The procedure is overloaded; there is a second form that lets you nominate a precreated schedule rather than specifying the schedule here with these three arguments

The DURATION is an INTERVAL DAY TO SECOND datatype This will allow a time span to be specified in days, hours, minutes, and seconds The basic syntax for

an INTERVAL DAY TO SECOND column is

'<days> <hours>:<minutes>:<seconds>'

Note that there is a space between the days and the hours, and colons between the hours, minutes, and seconds So this,

'1 2:3:4'

specifies a time gap of one day, two hours, three minutes, and four seconds

The PRIORITY argument is intended to manage circumstances where windows overlap, and has two possible values: LOW (the default) or HIGH Only one window can be in effect at a time, and it will be the window with the higher priority If two or more overlapping windows have the same priority, the window that opened first will take priority

Windows share the same namespace as schedules It is therefore impossible to create a window with the same name as a schedule, but this does mean that wherever you can refer to a schedule, you can also refer to a window So looking back to the third form of the CREATE_JOB procedure in earlier Figure 22-1, it becomes clear that

a job can be created to run at any time within a named window, rather than at the precise times specified by a schedule The window itself will open and close according

to a schedule, either a schedule defined within the window or a precreated schedule object

Figure 22-2, shown previously, illustrates the normalized relationships between the Scheduler and Resource Manager objects

Privileges

All Scheduler privileges are granted and revoked with the usual GRANT and REVOKE syntax There are a number of Scheduler-related privileges:

• CREATE JOB

• CREATE ANY JOB

• CREATE EXTERNAL JOB

• EXECUTE ANY PROGRAM

• EXECUTE ANY CLASS

• MANAGE SCHEDULER

• EXECUTE ON <job, program, or class>

• ALTER ON <job, program, or schedule>

• ALL ON <job, program, schedule, or class>

Before a user can create any jobs, schedules, or programs, they must be granted the

CREATE JOB privilege; this includes the ability to create and use their own programs

and schedules To create jobs in other schemas, the user will need CREATE ANY JOB

External jobs require a separate privilege To use Scheduler objects in other schemas,

you need the EXECUTE privilege on them The MANAGE SCHEDULER privilege is

needed to create job classes and windows, and to force windows to open or close

irrespective of their schedules

The ready-made role SCHEDULER_ADMIN includes the first six privileges just

listed It is granted to SYSTEM with ADMIN by default

Creating and Scheduling Jobs

Time-driven jobs can be independent, or tied to a program and a schedule

Event-driven jobs are launched by some triggering event Jobs can be linked together, with

dependencies, into a chain An advanced concept is that of the lightweight job: a

technique for creating many jobs very fast, without the overhead of standard jobs

A Self-Contained Job

To create and schedule a job with one procedure call, use the CREATE_JOB procedure

For example,

begin

dbms_scheduler.create_job(

job_name=>'hr.refresh_sums',

job_type=>'stored_procedure',

job_action=>'hr.refresh_summaries',

start_date=>trunc(sysdate)+23/24,

repeat_interval=>'freq=weekly;byday=mon,tue,wed,thu,fri;byhour=23',

enabled=>true,

auto_drop=>false,

comments=>'update summary tables');

end;

This will create an enabled job that will call the procedure HR.REFRESH_

SUMMARIES at eleven o’clock every weekday evening, starting today The job is

created in the HR schema

Exercise 22-1: Create a Job with the Scheduler API Use the DBMS_ SCHEDULER package to create a job, and confirm that it is working

1 Connect to your database as user SYSTEM using SQL*Plus

2 Create a table to store times, and set your date format to show the date and time SQL> create table times (c1 date);

SQL> alter session set nls_date_format='dd-mm-yy hh24:mi:ss';

3 Create a job to insert the current time into the table every minute

SQL> begin

2 dbms_scheduler.create_job(

3 job_name=>'savedate',

4 job_type=>'plsql_block',

5 job_action=>'insert into times values(sysdate);',

6 start_date=>sysdate,

7 repeat_interval=>'freq=minutely;interval=1',

8 enabled=>true,

9 auto_drop=>false);

10 end;

11 / PL/SQL procedure successfully completed.

4 Query the job and times tables a few times to see that the job is scheduled and running:

SQL> select job_name,enabled, to_char(next_run_date,'dd-mm-yy hh24:mi:ss'),run_count from user_scheduler_jobs;

SQL> select * from times;

5 Disable the job

SQL> exec dbms_scheduler.disable('savedate');

6 Rerun the queries from Step 4 to confirm that the job is disabled, and that no more inserts are occurring

7 Drop the job:

SQL> exec dbms_scheduler.drop_job('savedate');

Using Programs and Schedules

Programs and schedules enable you to reuse Scheduler components for similar tasks Rather than defining each job as a self-contained entity, you create programs and schedules, each of which can be used by many jobs

The job created in Exercise 22-1 could be split up into a job, a program, and a schedule To do this through Database Control, from the database home page select the Server tab Then in the Oracle Scheduler section select the Programs link, click CREATE, and enter the code you want executed as in Figure 22-3 This can be as long and complicated as you want, within the 32K limit of the PL/SQL VARCHAR2 datatype

TIP Keep your JOB_ACTIONs and PROGRAM_ACTIONs as short as

possible, preferably just one statement Do all the work in a procedure

invoked by that statement This will be far easier to maintain than having

a large amount of SQL or PL/SQL in your job and program definitions

If you create a program with the CREATE_PROGRAM procedure, then (just as with

jobs) the program will be disabled by default Change this default either by specifying

the ENABLED argument as TRUE when you create the program or by using the ENABLE

procedure subsequently:

SQL> exec dbms_scheduler.enable('myprogram');

To create a schedule, choose the Schedules link from the Oracle Scheduler section,

and click CREATE to view the page shown in Figure 22-4 The GUI interface does not

give access to some of the more complicated interval possibilities, such as every third

Tuesday, which would be

'freq=weekly;interval=3;byday=tue'

but it gives access to all that will usually be required

Figure 22-3 Creating a program with Database Control