Background processing is one of the very important factors in SAP system administration. It plays a key role in maintaining good system performance and availability.

Determining the schedule of the background jobs in a system landscape has to be done cautiously keeping in mind the resource availability, average number of dialog users, on/off peak hours, volumes of batch job. It has to be designed in such a way that the entire business cycle is completed in a span of 24 hours. The performance of an SAP system is also dependent on the state of batch processes in the system and memory and CPU resources consumed by them. Some batch jobs trigger parallel child processes which might run longer. Batch job design has to be done considering such situations as well because in some cases the number of child processes triggered is a lot which impacts other jobs and the system performance. Hence, effective batch job management in an SAP landscape contributes majorly towards healthy performance of the system.

Batch job analysis in a landscape where there are no external schedulers available is discussed in this post. This is mainly useful in a case where the number of jobs is high. It does not need any specific configuration. It is available with the ST-A/PI plugins.

Batch job analysis can be performed by collecting batch job execution data (mainly runtimes & delays) for a period of time say a week.  Data has to be collated such that any spikes are highlighted accurately. There can be two different types of spikes occurring here –

  1. The number of jobs in a given hour is too high
  2. The runtime of a particular job is high

Spike in the number of jobs can be identified by segregating the data on an hourly basis for seven days. Spike in the runtime of a particular job can be identified by segregating the data based on jobs. If any of these spikes is recurring, it is a possible threat for future performance issues.

On the SAP system, issue with batch jobs can be primarily identified by checking two things –

  1. Look for delay in the start time of the jobs. Each application server has a time scheduler which is responsible for triggering time-based jobs. This time scheduler by default runs every 60 seconds which can also be changed using the profile parameter rdisp/btctime. Delays till the time scheduler runs the next time, usually occur on any system. This maximum value of delay cannot fall under 30 seconds.
  2. Check for long running jobs and frequently failed ones. It is a good practice to have threshold runtime values for all the jobs. Actual run time can then be compared with the threshold value and see if there are huge deviations.

In-depth analysis of batch job execution along with runtime, work process utilization, number of jobs can be done through Background Job Analysis tool from transaction ST13. It is part of ST-A/PI Plugin and is available in all those systems with recent ST-A/PI Plugin. It helps in identifying system bottlenecks caused by background jobs. It presents the runtime of jobs, number of jobs in a time span, work process utilized by the job, DB and app server idle percentage in a graphical representation.


List view (for large number of shorter jobs) –

  

BJA1.png

Graphical view –

BJA2.png

For a maximum duration of 24 hours, batch job analysis can be performed at once using this tool. To get a graphical view, jobs whose runtime is atleast five minutes or more has to be selected. Jobs with lesser runtime are represented against ‘SJ’ row. Database server idle percentage and application server idle percentage, system and user utilization are displayed against ‘DB’ and ‘APPL’ sections. Work process utilization by each of the jobs (excluding shorter jobs) can also viewed from the result. It aids in finding overloaded or minimally loaded time frames and plan future loads accordingly. 

For example, when there was a huge delay for large number of jobs on a particular day in a landscape, this tool helps in finding the job which occupied the background processes, how many processes were occupied at that point in time etc.,. The only constraint is that the retention for the job logs has to be considered while performing batch job analysis.

With the growing usage of external schedulers like SAP CPS for batch management, faster and reliable analysis and forecasting of batch jobs is possible. Features of Redwood like in-built calendar and forecasting options, dashboards and monitoring trees are helpful to a great extent while performing analysis of huge number of jobs.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply