Distributed Processing of Updates (SAP Library - Updates in the SAP System (BC-CST-UP))

Distributed Processing of Updates

An update server performs the task of distributing the update requests (uniformly) among the different update work processes.

The update server, therefore, acts as an intermediary that receives the update request and distributes it to the update work processes.

Therefore, every SAP application server that contains update work processes provides the update service.

Note

In SAP systems in which the code pages of the SAP application servers have different character sets, the update work processes change their code pages dynamically in line with the code page of the update request to be processed.

Update distribution can be deactivate and configured with parameters of the SAP System profile. Further information can be found in the section entitled Main System Profile Parameters for Updates or in the update profile parameters in transaction RZ11 (use the search string rdisp/vb* in RZ11 to search for the parameters).

Therefore, in the profile of every SAP instance, you can define how update requests for this instance should be handled. The options are as follows:

The update requests can be distributed across the available update servers (Update Dispatching with Load Distribution).

They can be processed by a single update server (update dispatching deactivated and rdisp/vbname set).

They can be dispatched within the update group that belongs to the instance (Configuring Update Groups).

Types of Update Work Process

There are two types of update work process, one for V1 updates (listed as Update processes in transaction SM50/SM51 display) and one for V2 updates (listed as Upd2 in transaction SM50/SM51 display).

Caution

There must be at least one V1 update work process in the SAP System; there can, however, be more. If there is more than one process, update processing is distributed among the work processes on the basis of a load balancing algorithm (see also Update Dispatching with Load Balancing).

V2 processes are optional. These are used to avoid performance problems with time-critical V1 updates by splitting V2 update component processing. (V2 update components usually contain statistical data and are, therefore, less time critical). Further information can be found in the section entitled The Update Process and V1 and V2 Update Modules. If there is no V2 work process, both types of update component are processed in the V1 work process. V2 work processes are also used if collective runs are carried out.