Skip Headers

Oracle Enterprise Manager Concepts Guide
Release 9.2.0

Part Number A96674-01
Go To Documentation Library
Home
Go To Product List
Book List
Go To Table Of Contents
Contents
Go To Index
Index

Master Index

Feedback

Go to previous page Go to next page

3
Job and Event Systems

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

The Job system allows you to automate standard and repetitive tasks, such as executing a SQL script or executing an operating system command. With the Job system, you can create and manage jobs, share jobs with other administrators, schedule execution of jobs, and view information about the jobs. Jobs can be scheduled on a single node or multiple nodes in the 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 system allows you to monitor your network for specific conditions, such as loss of service or lack of storage, that may occur in your managed environment. 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 System and the Event System:

Topic See Page

Job System

3-2

Event System

3-7



Job System

The Job 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 System and can be performed on any remote system.

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

The three tiers of Oracle Enterprise Manager, which are the Console, 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 scheduled 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 access levels. 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 System.

Pre-defined System Tasks

When scheduling a job, you construct it with one or more tasks. The Job 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 createjo.gif follows.

Text description of the illustration createjo.gif

Job Scheduling

The Job 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 targets 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 targets 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 targets on which it should run. The targets can include databases, nodes, listeners, web servers, and groups of such targets.

Lights-out Management

The Job 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 System can be used with the Event 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 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.

Composite Jobs

A composite job combines two or more tasks into one job. Composite jobs consist of separate tasks that are constructed such that some tasks may or may not execute upon completion of another task. For example, if a composite job consists of two tasks, starting up a database and then running a SQL script, you can specify that the script be run only if the database was successfully started. Here, you specify a dependency between the two tasks that determine whether the next task is executed. The Job system allows you to specify one of three dependencies for any task: Always (default), Only on Success, or Only on Failure.

Scalability

The Job 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

Jobs are normally run with the preferences of the administrator who submitted the job. This ensures that jobs cannot be used to perform functions the administrator could not perform if logged into the machine directly. Because jobs are categorized by the type of target they act on, the job system knows what credentials to pass to the Intelligent Agent. The Job system uses preferred credentials to determine what preference information needs to be passed. When a job runs on a node, the job system passes the administrator preferences for the managed node.

Event System

The Event system allows you to efficiently monitor a large system. Using the Event system and Intelligent Agents, you can effectively monitor any number of databases, nodes, or other targets 24 hours a day, and be alerted when a problem or specific condition is detected. You can also pinpoint only the targets you wish to monitor. The Event system can be extended to include other third-party applications that detect events independent of the Intelligent Agents.

Events are simply a group of event tests that you want to run on your managed systems. Oracle Enterprise Manager includes a variety of predefined event tests that you can use when creating events. The event tests are grouped by target type, for instance:

You can create events using the predefined event tests that have been installed with Oracle Enterprise Manager. The events are created with information entered in the Event property sheet. You determine parameters such as the target that is monitored, the specific tests to perform, the frequency that the event test is executed, and whether other administrators can share the events and which administrators should be notified if the event condition is met. Some event tests have parameters with threshold values that you can customize for your system.

In the Event system, event settings are stored based on the administrator registering the event. This allows administrators of large systems to customize their event systems to their preferences and tasks. Administrators receive messages for events for which they have been selected to receive notifications by other administrators.

The Event system includes the following processes:

  1. Creating an event by completing the Event property sheet pages. This involves:
    1. Determining the monitored targets.
    2. Selecting the event tests that you want to run.
    3. Determining the threshold parameters for the event tests.
    4. Determining how often the event condition is to be checked.
    5. Specifying a fixit job to be run when an event triggers. (Optional)
    6. Assigning permissions to allow other administrators to share the event or be notified if the event condition is met.
  2. Saving and modifying an event.
  3. Registering or submitting an event to the Intelligent Agents on the monitored targets.
  4. Interpreting and correcting an event occurrence.
    1. Logging information pertinent to your interpretation of the event to the Event log.
    2. Assigning the Event to a different administrator if appropriate.

The Event 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-11



Proactive Event Management

When registering an event, in some cases you can create a fixit job that responds to specific event conditions. Refer to the Oracle Enterprise Manager Administrator's Guide for more information about associating fixit jobs with events. These situations are noted in the online help for Oracle events.

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 System allows administrators 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 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 targets can be monitored without slowing down other tasks.

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

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 e-mail notifications are sent.

Event notification occurs as follows:

Extended Event Status

An event is composed of one or more event tests. While an individual event test may result in a different status (For example, some clear, some are in alert), there is a general status for the Event. To determine the general severity 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 an alert 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" (yellow hexagon).
  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 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:

The colors of the event severity icons are:

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 access levels 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 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 can be specified for unsolicited events only if you are using an Oracle9i Intelligent Agent




Event Handler

Specific enterprise IT demands may require that responses to certain event occurrences be performed and/or tracked automatically by Enterprise Manager. For example, if the database updown event triggers, administrators may want Enterprise Manager to automatically open an in-house trouble-ticket so that the appropriate IT staff can respond to this event occurrence. The ability to provide customized automatic responses to event occurrences can be achieved by using the Event Handler.

The Event Handler is an integral part of the Oracle Management Server. It listens for event notifications and responds to these events in ways specified by the administrator.

For detailed information about the Event Handler, refer to the Oracle Enterprise Manager Administrator's Guide.


Go to previous page Go to next page
Oracle
Copyright © 1996, 2002 Oracle Corporation.

All Rights Reserved.
Go To Documentation Library
Home
Go To Product List
Book List
Go To Table Of Contents
Contents
Go To Index
Index

Master Index

Feedback