We have added search box. Key in SAP OSS Notes no. or keyword to search

Note: Please share your thoughts on any sap oss note by replying .

SAP Note 24092 - Distribution of background jobs on application server

SAP Note 24092 - Distribution of background jobs on application server
Share this post:
Ma.gnolia DiggIt! Del.icio.us Yahoo Furl Technorati Reddit


Request: How are background jobs distributed to the servers?

Other terms

Target server

Reason and Prerequisites

There is some ambiguity as to what is processed when and where. Jobs are hanging in the status 'released'.

Processing of jobs with a predefined start time:

On every server with at least one background work process, a background processing scheduler runs periodically (the period is defined by the parameters rdisp/btctime): On every run, this checks whether background work processes are free on its application server. If this is the case, pending jobs are selected from table TBTCS (job queue) and are distributed to the processes according to the following criteria (in order of priority):

    1. Jobs with class A have priority over jobs with class B, which has priority over class C.
    2. Jobs that are especially scheduled for this server have priority over jobs of the same class that are not scheduled for a particular server.
    3. If two jobs are equal after having applied the criteria mentioned above, jobs with a longer waiting time have priority. This gives a maximum job throughput per hour per server (only for short-running jobs) of:
    Jobs/Hour = No. of background processes * 3600 / 'rdisp/btctime'

The background processing schedulers work independently of each other. If a background work process is free on more than one background processing server, the server chosen is the one whose background processing scheduler is randomly activated first.

Processing of jobs with start time "immediately:"
  • Job with target host: The target host is checked immediately, to see whether at least one background work process is free for the required job class. If so, a request then is sent to the host to start the job immediately. If no work process is free, the job is put in the job queue with the current date/time, in the same way as any other job with a predetermined start time.
  • Job without target hosts: A host is randomly chosen from the list of all available hosts where free background work processes are available for the required job class. If no free work processes can be found, the job is also put in the job queue with the current date and time.
Processing of event-started jobs:
  • If an event is triggered in the SAP system, the event scheduler is immediately started. The event scheduler runs on a particular application server (see below). It selects all jobs that have been waiting for the triggered event. The event scheduler can only start jobs on the server on which it is running. If there are insufficient background processing resources on this server, the system changes the remaining jobs to time-controlled jobs.
    Even jobs that have a different target server are changed to time- controlled jobs.

    There are three ways of triggering an event in the SAP System. When an event is triggered, the server on which the event scheduler is running is also specified (explicitly or implicitly):

    1. BP_EVENT_RAISE function
    The TARGET_INSTANCE parameter specifies the server on which the event scheduler is running. If this parameter is empty, the event scheduler runs on the server specified in the rdisp/btcname profile parameter. In this case, the profile parameter is analyzed on the server on which BP_EVENT_RAISE was called.

    2. Transaction SM64
    The system calls BP_EVENT_RAISE internally with an empty TARGET_INSTANCE parameter (see 1).
    In future releases, it may be possible to specify the TARGET_INSTANCE parameter.

    3. sapevt program
    This is a program written and executed in C; it is located by default in the same directory as the kernel executables. If an event is triggered using sapevt, the event scheduler runs on the application server that has been active for the longest time.
Processing of jobs with start time 'After job' or 'At operation mode'.
  • Both start conditions are executed using events, so the system behaves in exactly the same way as with event-started jobs.
  • When defining operation modes (RZ04), you can reserve one or more background work processes for jobs with class A.
    This is done as follows: RZ04 -> "New operation mode" -> save -> doubleclick on the name of the operation mode -> "New instance" -> "Current settings" -> cursor to "Job-Cl.-A" -> "More" -> save.
    The individual background work processes will still be equal. Reserving n background work processes for jobclass A means that jobs of class B and C will only run on this server if there are at least n+1 free background work processes.
    The number of background work processes reserved for job class A must of course be smaller than the total number of background work processes (shown on the same screen); otherwise jobs of classes B and C won't run. The new operation mode can only be activated if it is scheduled with Transaction SM63.
  • Note concerning the workload:
    Since the job schedulers run independently on each application server, a job WITHOUT a target computer can be taken from any scheduler and run on the corresponding application server. Thus, the workload is distributed equally on all servers.
If the jobs you plan always have a defined start time and want free work processes on several servers, it is possible that one server is used more than the others. Imagine this situation: The batch scheduler on two separate servers is set to 60 seconds. When the scheduler on server A always becomes active at xx:xx:10 and the one on server B at xx:xx:20, server A will always come to the fore, since background jobs are planned for full minutes. If, for any reason, you want to divide the jobs equally between two servers, you will need to change the parameter rdisp/btctime: e.g., 61 seconds for server A and 62 seconds for server B.

Each scheduler distributes as many jobs as there are background work processes on the corresponding application server. When the scheduler is running, the system load on the respective application server is not considered. Therefore the number of configured background work processes should not cause any performance problems - even if all background processes are used


Post a Comment