【正文】 Job scheduling prises four main processes and a number of subprocesses as follows: ? Batch architecture ? Management server ? Capacity database (CDB) ? Application servers ? Monitor and printer ? Batch processing ? Job scheduling activities ? Monitoring ? Analyze ? Tuning ? Implementation ? Event management ? Asneeded request handling ? Schedule changing ? System backup ? Archiving ? Auditing ? Capacity manager log entry ? Reporting ? Documentation and training 8 Job Scheduling The following figure shows a process flow for job scheduling. Figure 1. Process flow diagram for job scheduling Batch Architecture Before a discussion of daily operational batch activities can begin, the basic ponents that make up the batch architecture should be understood. A batch architecture consists of the processes and ponents used to effectively manage batch processing. This section is a brief introduction to the typical ponents found in batch architecture. The purpose of the batch architecture is to optimize processing (improve response time and utilization of system resources) by executing batch runs during offpeak periods. The architecture should provide the capacity manager with an easy to use interface and permit a standard and centralized approach to batch scheduling, monitoring, control, and error correction. The architecture should be highly scalable in order to meet the future needs of the anization. It should also be highly available, with minimal downtime, and minimize impact to online operations, which usually are operating concurrently with the batch operations. Some anizations may decide to have backup ponents, such as the event server, to ensure the pletion of all missioncritical batch jobs. Activ ities Training Start Batch Architecture Batch Processing Job Scheduling Documentation and End Service Management Function 9 Figure 2 shows the basic ponents of the batch architecture, which include the management server, capacity database (CDB), monitor, printer, application servers, and databases. In addition to the monitor attached to the management server, each application server should have a monitor to permit viewing of local batchprocessing activity。 however, the capacity manager should address all warnings as soon as possible because they may lead to future job processing failures. If an error causes a job to be stopped, some scheduling tools attempt to automatically recover from the problem and begin processing the job from the beginning of the job step that was executing when processing was stopped. Recovery is useful when processing very long batch jobs because jobs that are interrupted do not have to be restarted from the beginning. If recovery is not possible, the job needs to be restarted. If the scheduling tool cannot restart or recover from a failed job (or restart or recover in a specific instance), the capacity manager has to manually initiate restart or recovery procedures. This situation is covered more extensively in the next section. Job Scheduling Activities Ideally, the batch architecture should be configured in such a manner that capacity manager interaction is kept to a minimum. However, there are still many daily tasks that the capacity manager must perform, including: ? Monitoring ? Analysis ? Tuning ? Implementation ? Event management ? Asneeded request handling ? Schedule changing ? System backup ? Archiving ? Auditing ? Capacity manager log entry ? Reporting Service Management Function 15 Each of these activities is an integral part of the job scheduling process. The monitoring, analysis, tuning, and implementation activities form an iterative process as shown in Figure 5. Inputs to the process include resource utilization and OLA thresholds against which the batch architecture is monitored. These are ongoing activities whose goal is to optimize the performance and utilization of the architecture. The remaining activities are performed in response to an event, request, or requirement. Figure 5. Iterative activities for resource management and service performance management of the batch architecture Monitoring Monitoring is a key activity involving the improving of daily batchprocessing performance and the planning for future capacity requirements. It is important that the utilization of each resource and service is monitored on an ongoing basis to ensure the optimum use of the hardware and software resources and that all agreed service levels can be achieved. The collected information (metrics) is typically stored in the capacity database (CDB). The metrics are analyzed for trends and are used to tune or adapt the system architecture and to aid in planning the job timing and interdependencies when adding new batch jobs in the future. Tuning Analysis (via Change Reports Exception Utilization Resource Reports Exception OLA Batch (CDB) Database Capacity Thresholds OLA Batch Thresholds Utilization Resource Monitoring Management) Implement 16 Job Scheduling Metrics that are typically collected include: ? CPU utilization. ? Memory utilization. ? Disk utilization. ? Network utilization. ? File store utilization. ? Batch duration profiles. ? Dependent subsystems (that is, database servers). ? Queue length (maximum and average). ? Transactions. ? Transactions per second. ? Transaction response time. ? Percentage CPU usage per transaction. The data should be gathered at total resource utilization levels and a detailed profile for the workload for each system ponent, resulting from batch processing, should be developed. This information should be used in conjunction with similar information about system ponents designated for online users. This plete picture helps the capacity manager assess how bat