Skip Headers
Oracle® Enterprise Manager Concepts
10g Release 2 (10.2)

Part Number B16241-01
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Feedback

Go to previous page
Previous
Go to next page
Next
View PDF

8 Job System

Because today's IT environments are composed of many sets of components, you need to minimize the time needed to support those IT components and eliminate the human error associated with component maintenance. The Enterprise Manager Grid Control Job System provides the capacity to automate routine administrative tasks and synchronize components in your environment so you can manage them more efficiently.

This chapter describes the Job System in the following sections:

What Is a Job?

The Enterprise Manager Job System serves a dual purpose:

A job is a unit of work that you define to automate commonly-run tasks. One of the advantages of jobs is that you can schedule a job to start immediately or start at a later date and time. You also have the option to have the job run once or at a specific interval, for example, three times every month. Job results are displayed on the target's home page.

The Job Activity page (Figure 8-1) is the hub of the Job System. From this page you can:

Figure 8-1 Job Activity Page

This figure shows a screenshot of the Enterprise Manager Job Activity page
Description of "Figure 8-1 Job Activity Page"

Job functionality is not restricted to only the Jobs tab. You can access job functionality while you are working on deployments and databases. On the Deployments page you can create a job to clone a database and another job to clone an Oracle home. While you are working with your databases, you can clone a database by clicking Deployments in the Related Links section.

What Are Job Executions and Job Runs?

Job executions are usually associated with one target, for example, a backup job on a particular database. When a job is run against multiple targets, each execution may execute on one target.

Job executions are not always a one-to-one mapping to a target. Some executions have multiple targets, for example, comparing hosts. Other executions have no targets, for example, the RefreshFromMetaLink job.

When you submit a job to many targets, it would be tedious to examine the status of each execution of the job against each target. For example, say that you run a backup job against 100 databases. Typical questions would be: Were all the backups successful? If not, which backups failed? If this backup job runs every week, you would want to know each week which backups were successful and those that failed.

With the Job System, you can easily get these answers viewing the "job run." A job run is the sum of all job executions of a job that ran on a particular scheduled date. Using the backup example, if you have a backup job against 100 databases on November 5th, then you will have a November 5 job run. The job table that shows the job run will provide a roll-up of the status of those executions.

Differences Between Job Executions and Job Runs

In addition to supporting the standard job operations of create, edit, create like, and delete, the Job System allows you to suspend and resume jobs, as well as retry failed executions. For example, you may need to suspend a job if a needed resource was unavailable, or the job needs to be postponed. Once you suspend a job, any scheduled executions do not occur until you decide to resume the job.

When analyzing a failed execution, it is useful to be able to retry a failed execution after the cause of the problem has been determined. This alleviates the need to create a new job for that failed execution. When you use the Retry operation in the Job System, Enterprise Manager provides links from the failed execution to the retried execution and vice versa, should it become useful to retroactively examine the causes of the failed executions.


See Also:

For more information on job executions and runs, refer to Enterprise Manager Grid Control online help.

Using and Defining Jobs

Enterprise Manager provides predefined job tasks for database targets and deployments. A job task is used to contain predefined, unchangeable logic—for example, patch an application, back up a database, and so on.

The predefined database jobs include backup, export, and import. The predefined jobs associated with deployments include patching, cloning Oracle homes, and cloning databases.

In addition to predefined job tasks, you can define your own job tasks by writing code to be included in OS and SQL scripts. The advantages of using these scripts include:

Using the Job System, you can create jobs using the following job types:


See Also:

Chapter 6, "Managing Deployments" for information about deployment jobs

Chapter 12, "Database Management" for information about the Database Scheduler

"About Jobs," "About Scheduler," "About Cloning," and "About Patching" in the Enterprise Manager Grid Control online help.


Analyzing Job Activity

After you submit jobs, the status of all job executions across all targets is automatically rolled up and available for review on the Grid Control Console Home page. Figure 8-2 shows the All Targets Jobs information on the Grid Control Console Home page.

Figure 8-2 Summary of Target Jobs on the Grid Control Console Home Page

This figure shows a screenshot of the Enterprise Manager Target Jobs Summary page
Description of "Figure 8-2 Summary of Target Jobs on the Grid Control Console Home Page"

This information is particularly important when you are examining jobs that execute against hundreds or thousands of systems. You can determine the job executions that have failed. By clicking the number associated with a particular execution, you can drill down to study the details of the failed job.

Jobs and Groups

In addition to submitting jobs to individual targets, you can submit jobs against a group of targets. Any job that you submit to a group is automatically extended to all its member targets and takes into account the membership of the group as it changes.

For example, if a Human Resources job is submitted to the Payroll group, then if a new host is added to this group, the host automatically becomes part of the Human Resources job. In addition, if the Payroll group is composed of diverse targets, for example, databases, hosts, and application servers, then the job only runs against applicable targets in the group.

By accessing the Group Home page, you can analyze the job activity for that group.

Sharing Job Responsibilities

To allow you to share job responsibilities, the Job System provides job privileges. These job privileges allow you to share the job with other administrators. Using privileges, you can:

These privileges can be granted on an as-needed basis.

Job Library

Once you have defined jobs, you can save these jobs to the Job Library. Use the Library as a repository for frequently used jobs. Analogous to active jobs, you can grant View or Full access to specific administrators.

In addition, you can use the Job Library to store:

Job Notifications

The Grid Control Notification system allows you to define a notification rule to send e-mail to the job owner when a job enters a chosen state (Scheduled, Running, Suspended, Completed, or Problems). New functionality has been added to the Notification system (rule creation) that allows you to easily associate specific jobs with a notification rule.

Multitask Jobs

Multitask jobs allow you to create complex jobs consisting of one or more distinct tasks. Because multitask jobs can run against targets of the same or different type, they can perform ad hoc operations on one or more targets of the same or different type.

You can create a multitask job consisting of two tasks, each a different job type, each operating on two separate (and different) target types. For example,

The Job System's multitask functionality makes it easy to create extremely complex operations.