|
Oracle® Enterprise Manager Concepts
10g Release 2 (10.2) B16241-01 |
|
 Previous |
 Next |
|
Oracle® Enterprise Manager Concepts
10g Release 2 (10.2) B16241-01 |
|
|
Previous |
Next |
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:
The Enterprise Manager Job System serves a dual purpose:
Provides for the automation of many administrative tasks, for example, backup, cloning, and patching
Allows 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. 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:
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
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.
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.
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. |
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:
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 job types:
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 this Oracle home to one or more hosts.
Host Command: Use to execute a user-defined OS script.
Patch: Finds and applies a patch or patch set.
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 jobsChapter 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. |
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 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.
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.
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.
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.
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 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,
Task 1 (OS Command job type) performs an operation on Host 1.
If Task 1 is successful, run Task2 (SQL Script job type) against Database 1 and Database 2.
The Job System's multitask functionality makes it easy to create extremely complex operations.
