Release 1.4.0
A53707_01
 Library |
 Product |
 Contents |
 Index |
| Oracle Enterprise Manager Concepts Guide Release 1.4.0 A53707_01 |
|
The Oracle Enterprise Manager provides a job scheduling system and an event management system.
The Job Scheduling System provides stored and forwarding capability which enables the automation of standard and repetitive tasks. With the Job system, you can create and manage jobs, schedule execution of jobs, and view information about the jobs. Jobs can be scheduled on a single node or multiple nodes in the network. If the site or its agent is down, the job request is queued, and once the site can be contacted, the queued job is submitted to the agent.
The Event Management System allows you to monitor specific event conditions, such as loss of service or lack of storage, that occur in your network environment. You choose predefined events on nodes, databases, or listeners, then select the threshold parameters for which you want to be notified. You can notify specific system administrators when an event condition occurs. For some events, you can also choose to execute a fixit job that automatically corrects the problem.
| Topic | See Page |
|---|---|
The Job Scheduling System allows you to schedule and manage job tasks on remote sites.
You can use the Job Scheduling System to perform asynchronous tasks on multiple sites without having to maintain connections to all those sites. In addition, jobs can run simultaneously on different nodes in the system.
The Job Scheduling System, communication daemon, and agents work in unison to schedule and execute the job.
The process for scheduling a job is:
This section discusses the following benefits of the job scheduling system.
| Topic | See Page |
|---|---|
Oracle Enterprise Manager includes a variety of predefined jobs to select from.
Examples of predefined jobs are
You can also submit your own custom jobs to the Job Scheduling System.
The Job Scheduling System is simple to use because the task of scheduling and managing jobs is centralized in the Enterprise Manager Console. You only needs to submit a job once, regardless of the number of destinations on which the job will run or the number of times the job will be run.
When you submit a job, the Console's daemon process sends the job information to the appropriate intelligent agents on the destinations you selected. The agents are responsible for executing the job on schedule and returning job status messages back to the daemon.
When a job is submitted to one or more destinations, it is possible that any one of those sites may be down. If a site or its agent is down, the communication daemon queues job requests that could not be delivered to the site. Once the site can be contacted, the daemon will submit the queued job to the agent.
To schedule a job, you do not have to connect to the node on which the job will be run. You only need to submit the job to the Console and specify the destinations on which it should run. The destinations can include nodes, databases, listeners, names servers, and user-defined groups that have been created with the Map system. You do not need to connect to the node on which the job will be run.
The Job Scheduling System allows you to automate repetitive and periodic tasks and problem correction. If the job has to be executed periodically, the agents reschedule the job without your 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 to be monitored by the Enterprise Manager, you have the option of specifying a fixit job, which will be executed to correct the problem if the event occurs.
Jobs are implemented as Tool Command Language (Tcl) scripts. Tcl is a scripting language that is used to write both job and event scripts. Oracle has also extended Tcl (OraTcl) to include database-specific commands.
With OraTcl, you can:
Although you submit a job from the Console, the job scripts themselves reside on the agent nodes. Because the manner in which a job is implemented may depend on the platform, each agent keeps its own set of job scripts.
Some DBA jobs involve more than one task. For example, before making schema changes to a database, you may want to back up the database. To accommodate these types of jobs, the Job Scheduling System allows you to combine two or more predefined jobs into one composite job. Each of the predefined jobs contained in the composite job is called a task.
Composite jobs can contain test conditions based on the success of a 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.
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 agent servicing the node.
When the job is executed, it is run by the agent on that node, minimizing network traffic between the remote node and the Console and daemon. The only communication between the agents and the Console and daemon are the initial transmission of job information and any subsequent messages about job status changes.
Because jobs are run independently by 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 start another task without waiting for the agents to schedule the jobs.
In addition, because there is an intelligent agent residing on each managed node, jobs can be run on multiple nodes simultaneously. For example, you can submit a job to run a report on multiple databases worldwide. The job is scheduled and run independently by the agent that services each database. Therefore, the jobs can be executed by their respective agents at the same time.
Jobs are normally run with your preferred credentials; therefore, you will not be able to run jobs to perform functions that you could not perform if you were logged into the machine directly.
Because jobs are categorized by service types, such as database or node, the Job system knows which credentials to pass to the agent.
If the job runs on a node, the Job Scheduling System passes either your preferred credentials for the node, or if none are specified, the username and password you used when you logged into the Console.
If the job runs on a service, such as a database, the Job Scheduling System also passes your preferred credentials to the service.
A job can also be run with the agent's credentials. This flexibility allows a site to easily incorporate the Job Scheduling System's authentication methods with existing security policies.
The Event Management System automates problem detection and correction by allowing you to monitor for specified events throughout the network and to execute a job to fix the problem.
The Event Management System includes the following processes:
The process to register an event set is:
When an event occurs, you can be notified in various ways, such as electronic mail or paging. Also, events are always logged in the repository and can be viewed in the Console.
This section discusses the following features of the Event Management System.
| Topic | See Page |
|---|---|
When an event set is registered, you have the option to specify a fixit job for the event. A fixit job is run by the agent if it detects the 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 impact end-users.
The Event Management System does not require that the intelligent agent be the only mechanism for error detection.
The Event Management System can include other tools and applications that detect events independent of the intelligent agents. These tools and applications can be integrated into the Event Management System. They can communicate directly with the intelligent agents.
For example, a third-party application can detect an event on a node and report that event to the intelligent agent on that node. The agent then sends the message back to the Console as usual.
The Event Management System allows one person to monitor a large system. If you are responsible for 100 databases, you cannot connect to each database every day to check on its performance. However, using the Event Management System you can effectively monitor all the databases 24 hours a day and be alerted if a problem is detected.
The Event Management System also allows you to focus on select systems and events. Focus control is vital in a large system. Rather than monitor all sites or a large number of sites, you can pinpoint only those services they wish to monitor.
In the Event Management 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 only those messages related to the events that they have submitted.
On the other hand, you can monitor a large number of sites with minimal performance impact on the Console. Because the intelligent agents perform the monitoring independent of the Console, you have the option of monitoring many sites without slowing down other tasks.
Standard pre-defined event sets are provided with Enterprise Manager. Advanced event sets are included with the optional Performance Pack.
The standard pre-defined events are the fault management events:
Some of pre-defined event sets that are included with the Performance Pack are:
Refer to the Oracle Enterprise Manager Performance Monitoring User's Guide.
As with jobs, events are OraTcl scripts that are stored on the agent node. Event scripts can save state information. Saving a state between executions of an event script allows the agent to remember if it has detected a certain event already and eliminates redundant event messages to the Console. It also allows event scripts to maintain a history of a database and adjust to behavior that is typical.
Unlike job scripts, event scripts are run with the permissions of the agent.
The intelligent agent has been optimized to monitor large numbers of systems and events efficiently. Event tests are generally executed by the agent process directly and can be run quickly.
