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

OCA/OCP Oracle Database 11g All-in-One Exam Guide 806 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. Chapter 22: The Scheduler 807 PART III 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 OCA/OCP Oracle Database 11g All-in-One Exam Guide 808 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 Chapter 22: The Scheduler 809 PART III 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 COMMENTS VARCHAR2 IN DEFAULT OCA/OCP Oracle Database 11g All-in-One Exam Guide 810 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: Chapter 22: The Scheduler 811 PART III 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 OCA/OCP Oracle Database 11g All-in-One Exam Guide 812 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: Chapter 22: The Scheduler 813 PART III • 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. OCA/OCP Oracle Database 11g All-in-One Exam Guide 814 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. Chapter 22: The Scheduler 815 PART III 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 . IN DEFAULT COMMENTS VARCHAR2 IN DEFAULT OCA/ OCP Oracle Database 11g All-in-One Exam Guide 810 The START_DATE defaults to the current date and time. This is the time that any jobs associated with. 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 OCA/ OCP Oracle Database 11g All-in-One Exam Guide 808 name a stored. 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