Oracle Enterprise Manager Concepts Guide Release 2.2 Part Number A85250-01 |
|
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 |
---|---|
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:
This section discusses the benefits of the Job Scheduling System.
Topic | See Page |
---|---|
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
The registering and monitoring of an event involves the following steps:
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.
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 |
---|---|
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.
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.
Events can consist of multiple event tests.
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:
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:
You can still see the individual status of each event test in the Event Viewer.
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:
The colors of the event severity icons are:
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 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.
|
![]() Copyright © 1996-2000, Oracle Corporation. All Rights Reserved. |
|