Oracle Enterprise Manager Concepts Guide Release 2.2 Part Number A85250-01 |
Library | Service | Contents | Index

# 3
Job and Event Systems

This chapter describes the Oracle Enterprise Manager Job Scheduling System and Event Management System.

The Job Scheduling System enables the automation of standard and repetitive tasks. With the Job system, you can create and manage jobs, schedule runs of jobs, and view information about jobs. Jobs can be scheduled against a single target (database or other service) or multiple targets in a network, provided that the node has an Intelligent Agent running on it. If the node or its Intelligent Agent is down, the job request is queued, and once the node can be contacted, the queued job is submitted to the Intelligent Agent.

The Event Management System monitors your network environment for specific event conditions, such as loss of service or lack of storage. You select tests to run on managed targets (databases, nodes, listeners, or other services), then set the threshold parameters for which you want to be notified. You can share events with other administrators, in addition to being able to notify specific administrators when an event condition occurs. For some event tests, you can also choose to execute a fixit job that automatically corrects the problem.

This chapter describes the Job Scheduling System and the Event Management System:

Topic | See Page
--- | ---
Job Scheduling System | 3-2
Event Management System | 3-7

## Job Scheduling System

The Job Scheduling System allows you to schedule and manage job tasks throughout the network, even remotely. Any job that an administrator can perform from the operating system command or with SQL can be sent from the Job Scheduling System and can be performed on any remote system.

With the Job Scheduling System, you can perform asynchronous tasks on multiple databases and other services without having to maintain connections to all those services. In addition, jobs can run simultaneously on different nodes in the system.

The three tiers of Oracle Enterprise Manager, which are the Console and its Job Scheduling pane, the Oracle Management Server, and Intelligent Agents residing on managed nodes, work in unison to schedule and execute the job.

From job scheduling to job completion, the following steps occur:

1. From the Console Jobs pane, a job is submitted against one or more targets of the same type that is made up of one or more tasks.

2. The Oracle Management Server stores the information and checks if the target node is up or down. If the node or its Intelligent Agent is down, the Oracle Management Server queues the job.

3. Once the node can be contacted, the Oracle Management Server sends the job information to the Intelligent Agent residing on the managed node. Jobs can be sent to multiple nodes concurrently.

4. The Intelligent Agent executes the job on schedule.

5. The Intelligent Agent returns any related job messages back to the Oracle Management Server for display in the appropriate consoles based on administrator permissions. If the Intelligent Agent cannot get in touch with the Oracle Management Server, it queues the messages.

This section discusses the benefits of the Job Scheduling System.

Topic | See Page
--- | ---
Pre-defined System Tasks | 3-3
Job Scheduling | 3-4
Lights-out Management | 3-5
Cross-Platform Job Scripts | 3-5
Job Progress | 3-5
Job Notification and Filtering | 3-5
Communication with the Intelligent Agent | 3-6
Complex Jobs | 3-6
Scalability | 3-6
Security and Jobs | 3-7

### Pre-defined System Tasks

When scheduling a job, you construct it with one or more tasks. The Job Scheduling System includes a variety of pre-defined tasks from which to select, such as starting up and shutting down Oracle databases and Listeners; running SQL and DBA commands; and running operating system commands or shell scripts.

#### Figure 3-1 Selecting Tasks When Creating a Job

Text description of the illustration createjo.gif

### Job Scheduling

The Job Scheduling System is simple to use because the task of scheduling and managing jobs is centralized in the Enterprise Manager Console. The administrator only needs to submit a job once, regardless of the number of destinations on which the job will run.

When you submit a job, the Management Server sends the job information to the appropriate Intelligent Agents on the destinations you selected. The Intelligent Agents are responsible for executing the job on the specified schedule and returning job status messages to the Console through the Management Server. Once submitted, jobs will run regardless of whether you are logged in or not.

When a job is submitted to one or more remote sites, it is possible that any one of those site may be down. If a site or its Intelligent Agent is down, the Management Server queues any job requests that could not be delivered to the site. Once the site can be contacted, the Management Server submits the queued job to the Intelligent Agent, which in turn executes the job on the node.

If a job has been scheduled with an Intelligent Agent, and the connection between the Intelligent Agent and the Oracle Management Server goes down, the Intelligent Agent still executes the job on schedule. When the job is completed, and if the Oracle Management Server is back up, the Intelligent Agent notifies the Oracle Management Server, which then displays the status of the job on the Console. If the Oracle Management Server cannot be contacted, the Intelligent Agent queues the status message until the server is available.

To schedule a job, you do not have to connect directly to the node on which the job will be run. You only need to submit the job from the Console and specify the destinations on which it should run. The destinations can include databases, nodes, listeners, web servers, and groups of such destinations.

### Lights-out Management

The Job Scheduling System allows you to automate repetitive and periodic tasks and problem correction. If a job needs to be run periodically, the Intelligent Agents reschedule the job without the need for additional intervention. Messages about a job's status are reported back to the Console.

The Job Scheduling System can be used with the Event Management System to automate problem correction. When you register an event, you have the option of specifying a fixit job, which will automatically be run in response to an event to correct the problem.

### Cross-Platform Job Scripts

Jobs are implemented as Tool Command Language (Tcl) scripts. Tcl is a platform-independent scripting language used to write both job and event scripts. For example, a job can be run against a UNIX and an NT machine at the same time, without changing a single byte of information in the job definition.

### Job Progress

You can monitor the progress of a job by double-clicking on the job in the Active Jobs page of the Jobs pane. When you click on a job in the list, the Job Properties dialog box appears providing information about the job's activities and progress.

After a job is run, a list of tasks comprising the job and the time that each task completed or failed appears in the Progress tab of the Job Properties dialog box.

### Job Notification and Filtering

Administrators can be notified in various ways of the status of jobs, such as by electronic mail or page, depending on the administrator's preferences. With the job scheduling system, you can set up notification procedures and choose which administrators to have notified of job completion or failure. You can also filter e-mail and pages sent to administrators according to a job's status.

### Communication with the Intelligent Agent

Although a job is submitted from the Console, the job scripts themselves reside on the Intelligent Agents residing on the managed nodes. Because the manner in which a job is implemented may depend on the platform, each Intelligent Agent keeps its own set of job scripts.

### Complex Jobs

A complex job is a job comprised of more than one task. Tasks in a job can be set up in any order, and can be configured to depend on the success or failure of other tasks in the job. For instance, a task in a job can be configured to halt if the previous task in the job fails.

### Scalability

The Job Scheduling System allows you to run jobs efficiently on multiple remote nodes. When you submit a job to run on a remote node, all the information needed to run the job is transferred to the Intelligent Agent servicing the node.

When the job is run, it is run by the Intelligent Agent on that node, minimizing network traffic between the remote node, the Oracle Management Server, and the Console. The only communication between the Intelligent Agent and the Oracle Management Server is the initial transmission of the job and any subsequent messages about job status.

Because jobs are run independently by Intelligent Agents, you can submit any number of jobs on multiple nodes without affecting the Console. For example, you can submit several jobs and then immediately administer something else without waiting for the Intelligent Agents to schedule the jobs.

Additionally, because there is an Intelligent Agent residing on each managed node, jobs can run on multiple nodes simultaneously. For example, you can submit a job, such as running a report, on multiple databases worldwide. The job is then run independently by each Intelligent Agent servicing each database. In this way, all jobs are performed by their respective Intelligent Agents at the same time.

### Security and Jobs

When jobs are run on a managed service, your preferred credentials for that service (stored in the repository) are usually used for accessing that service; therefore, you can perform any task from the Console that you could perform if you were logged directly into the service using those credentials.

## Event Management System

The Event Management System can be used to automatically monitor managed targets for potential problems, such as loss of service or lack of storage.

Note: Only up/down events are shipped with base Oracle Enterprise Manager; all other events are bundled with the separately licensable packs.

The administrator defines what to monitor by creating an "event", which is a potential problem occurrence for which the Intelligent Agent then monitors services. An event is made up of one or more tests.

When a test within an event returns true, the Event Management System notifies you or another administrator that you specify. In certain cases, Oracle Enterprise Manager can also run a pre-defined fixit job to run in response to an event to correct the problem.

The Event Management System includes the following processes:

- Creation and registration of events by the selection of one or more tests

- Notification of specified administrators

- Correction of problem occurrences

The registering and monitoring of an event involves the following steps:

1. From the Events pane in the Console, you register an event made up of one or more tests that you select from a list of pre-defined tests.

   In registering the event, you select the managed target(s) in the network that you want to monitor. You then select one or more tests to make up the event, specifying threshold parameters for each test.

2. When you have completed these event specifications, you submit the event.

3. The event is passed to the Oracle Management Server, which stores the information and checks if the node is up or down. If the node or its Intelligent Agent is down, the Oracle Management Server queues the event.

4. If the node and its Intelligent Agent are up, the Oracle Management Server sends the event information to the Intelligent Agent on the managed node containing the destination service. (Events can be sent to multiple nodes concurrently.)

5. When an Intelligent Agent receives an event, it runs the event's tests against the target service or services at user-defined polling periods which continue until the event is cancelled (de-registered).

6. When one or more tests on a service return true, the Intelligent Agent alerts the Oracle Management Server. If the Oracle Management Server is not reachable, the Intelligent Agent queues the messages.

7. Once the Oracle Management Server is notified, the Event Management System notifies administrators who have the Notify permission for the event and are scheduled for notification. Administrators are notified by Console alert if they have at least view permissions, and can also be notified by page or e-mail alert if specified.

Information about an event's status is viewable in the Event Viewer window, which is accessible when you double-click on a listed event on the Alert page or History page in the Events pane. In the Event Viewer page you can check the status of an event and share information about it with other administrators by recording and viewing comments in the Event Log.

The Event Management System contains the following features:

Topic | See Page
--- | ---
Proactive Event Management | 3-8
Scalability | 3-9
Event Notification and Filtering | 3-9
Event Log | 3-10

### Proactive Event Management

When registering an event, you have the option to specify a fixit job, which is run by the Intelligent Agent on the managed node in response to an event. Events and fixit jobs used together automate problem detection and correction. The proactive management of an event ensures that a problem is corrected before it noticeably impacts end-users.

### Scalability

The Event Management System allows one person to monitor multiple databases and systems. For example, it would be difficult for one person to connect to 100 databases individually every day to check on each database's performance. However, using the Event Management System, one person can effectively have the databases monitored 24 hours a day with minimal performance impact on the Console, and he can be alerted if a problem is detected. Because the monitoring is performed by Intelligent Agents independently of the Console, multiple services can be monitored without slowing down other tasks.

The Event Management System also gives you the option of focusing on select systems and events. Rather than monitoring all services or a large number of services at once, you can choose to focus on select services.

### Event Notification and Filtering

Events can consist of multiple event tests.

#### Event Notification

If any one of these tests identify a specified condition, the event is triggered and a notification is sent to the Console. If enhanced notification is configured for your system, paging and/or email notifications are sent.

Event notification occurs as follows:

- A notification is sent when the threshold of an event test exceeds the level specified by parameter values. If the event does not have parameters, a notification is sent when the event occurs.

- If the event test condition remains above the threshold specified, a new notification is not sent. If the condition does not exist when the next test is run, the event clears. Notifications are also sent (email/paging) when an event clears, depending on the filtering of notifications.

- If an event test condition changes from warning to critical or critical to warning, a new notification is sent to the Event pane or via E-mail or paging.

- If you acknowledge and move an alert to history, a new notification is not sent to the Alerts page unless a moved warning changes to a critical alert.

#### Extended Event Status

While an individual event test may result in a different status (For example, some clear, some are in critical), there is a general status for the Event. To determine the general status for the event, the following rules apply in succession:

1. If the event includes an UpDown event test, and this test triggers, then the general status of the Event is "Unknown" (gray flag)

2. Otherwise, if the event includes a test that reaches a critical state, then the general status of the Event is "Critical" (red flag)

3. Otherwise, if the event includes a test that reaches a warning state, then the general status of the Event is "Warning" (yellow flag)

4. Otherwise, if the event includes a test that is in error, then the general status of the Event is "Error" (inverted yellow triangle)

5. Otherwise, all tests should be clear, so the general status of the event is "Clear"

You can still see the individual status of each event test in the Event Viewer.

#### Event Colors and Icons

All events return values and some events produce output messages. The events return different colored icons depending on the severity of the event. These severity levels are determined by parameter thresholds you set for the event tests during event creation. The colors are displayed on the event severity icon that is located:

- Next to the event name listed in the Alerts page.

- On the object in the Group pane if it is part of a group.

The colors of the event severity icons are:

- Error State (yellow hexagon)

- Event cleared (green flag)

- Warning (yellow flag)

- Critical (red flag)

- Unknown (gray flag)

### Event Log

With the Event Log page, located in the Event Viewer page, administrators can share information with other administrators about events and how they are being managed. The Event Log page allows comments to be entered on a selected event by administrators with modify permissions for the event.

The information displayed in the Event Log page includes any comments that have been entered for the event, the names of the administrators that entered the comments, and the time and date each comment was entered. The Event Management System itself also enters data in the Event Log page.

### Unsolicited Error Detection

Unsolicited event tests are event tests that have been initiated outside the Enterprise Manager Event system. An event is considered unsolicited if it is raised by a process other than the Oracle Intelligent Agent, but is running on the same node as the Intelligent Agent. These events are usually provided by third-party software. Creating an unsolicited event allows you to integrate and monitor third-party events.

Note: Fixit jobs cannot be specified for unsolicited events.

| Copyright © 1996-2000, Oracle Corporation. All Rights Reserved. |
Library | Service | Contents | Index