【正文】 tored in this database. Application Servers Application servers that execute batch jobs are also part of the batch architecture. Each server has an instance of the scheduling tool installed, which allows the local monitoring and logging of batchrelated information and the reporting of this information to a centralized location. The servers interact with the appropriate backend databases to access the data that is used in the batch job. The local scheduling tool starts the job assigned to it by the event processor and sends pletion information or errors to the centralized scheduling tool. Monitor and Printer A monitor connected to the management server permits interaction with the scheduling tool and thus the batch process. Scheduling tools typically have the ability to graphically display performance, status, and execution results information. From the monitor, the capacity manager should be able to manually control the batch process. The printer is used by the capacity manager to generate operational reports that are used to assess system performance and processing errors or any other information the capacity manager deems useful. Batch Processing This section provides an introduction to batch processing. It describes how a scheduled batch run is executed and what resulting information is recorded. Figure 3. Batch process hierarchy Before discussing scheduled batch runs, it is useful to first understand the hierarchy of the batch process and the contents of a batch script. Figure 3 shows the batch process hierarchy. A batch run consists of multiple independent batch jobs that are scheduled for execution on a recurring basis. A large anization may execute multiple batch runs throughout the day depending on the resources required to process them. Each batch job consists of multiple batch job steps that control specific activities of job execution. An anization typically processes numerous batch jobs. To ensure a consistent approach to the execution of each job, a batch job skeleton should be devised that Batch Job Batch Run Batch Job 1 Batch Job 2 Batch Job 3 Batch Step 1 Batch Step 2 Batch Step 3 Service Management Function 13 contains the standardized code required for each job。 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