10 Job System

Because the IT systems of today are composed of many sets of systems, you need to minimize the time needed to support these systems and eliminate the human error associated with system maintenance. The Enterprise Manager Job System provides the capacity to automate routine administrative tasks and synchronize systems so you can manage them more efficiently.

This chapter describes the Job System in the following sections:

• What Is A Job?

• Using and Defining Jobs

• Analyzing Job Activity

• Jobs and Groups

• Sharing Job Responsibilities

• Job Library

What Is A Job?

The Enterprise Manager Job System serves a dual purpose. It:

• Provides for the automation of many administrative tasks, for example, backup, cloning, and patching

• Allows end users to create their own jobs using their own custom OS and SQL scripts

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.

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

• Search for existing job runs and job executions

  You can restrict the search by name, owner, status, scheduled start, job type, target type, and target name.

• Create a job

• View, edit, create like, suspend, resume, stop, and delete a run

• View, edit, create like, suspend, resume, retry, stop, and delete an execution

Figure 10-1 Job Activity Page

Description of the illustration job_activity.gif

The results of Jobs display on the target's home 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 rollup 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 not available or the job needs to be postponed. Once you suspend a job, any scheduled executions will 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 once the cause of the problem has been determined. This alleviates the need of creating 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.

Refining the Job Search

In addition to restricting the job search by name, owner, status, scheduled start, job type, and target name, you can query against a target using the target type and access.

Target Types

You can form a query against a target using the following target types:

• All Targets

  For basic targets, for example hosts and databases, you can query to see what jobs ran on those targets.

• All Groups

  You can query to see what jobs were submitted to these targets.

• All Member Targets of the Target Named Below

  You can query to see what jobs ran on the members of the named composite target (group, Real Application Cluster, or cluster). This differs from the All Groups query because it shows both jobs which were submitted to the Group, as well as those submitted directly to any member of the group.

• System

  This is a special job category for jobs that do not run against any target, for example, RefreshFromMetalink.

Access Check Box

Using the Show jobs to which I have not been granted view access check box, you can view the jobs to which you do not have access. Using this option you can avoid surprises to members of your group. For example, if you are about to bounce a database or place a database into blackout, you may want to check on what jobs may be currently executing or about to execute on that target.

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, backup 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:

• When defining these jobs, you can use target properties.

• You can submit the jobs against many targets or a group. The job automatically keeps up with the group membership.

• For host command jobs, you can submit to a cluster.

• For SQL jobs you can submit to a Real Application Cluster.

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

• CloneHome

  Copies the known state of an Oracle home. For example, after you have an Oracle home in a known state (you have chosen particular install options for it, applied required patches to it, and tested it), you may want to clone that Oracle home to one or more hosts.

• Host Command

  Use to execute a user-defined OS script.

• Patch

  Use to find a patch and then apply that patch.

• Refresh from MetaLink

  Use to be notified of critical patch advisories.

• SQL script

  Use to execute a user-defined SQL script.

See Also: Chapter 6, " Managing Deployments" for information about deployment jobs Chapter 4, " Database Management" for information about the Database Scheduler "About Jobs", "About Scheduler", "About Cloning", and "About Patching" in the Enterprise Manager 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 Home page. Figure 10-2 shows the All Targets Jobs information on the Grid Control Home page.

Figure 10-2 Summary of Target Jobs on the Grid Control Page

Description of the illustration job_summary.gif

This information is particularly important when you are examining jobs that execute against hundreds, if not 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 will automatically be 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 will only run against applicable targets in the group.

By accessing the Groups 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:

• View access to the administrators who need to see the results of the job

• Give full access to the administrators who may need to edit the job definition

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:

• Basic definitions of jobs then add targets and other custom settings before submitting the job

• Jobs for your own reuse or to share with others. You can share jobs using views or giving full access to the jobs.