In Release 3.0 and later, more than one update server can be supported SAP system. When an update request is created, the update manager automatically chooses a "suitable" update server. To attain an efficient load distribution, all the update servers are subjected to static evaluation and the update requests are distributed by turns. Update dispatching of this kind is factory-set to active in Release 3.0.
As well as distributing load, update dispatching also improves the availability of the updating service and so contributes to an increase in overall system availability. If, for example, an update server has to be brought down, the update manager recognizes this and dispatches updates to the remaining servers.
You can define factors to control the weighting of individual servers. To do this, you maintain the rdisp/vb_factor parameter as follows:
<Server Name> must be the name of server that is of type Update (see SM51).
<Factor> can be any floating-point number not equal to 0. The factory set default factor is 1. Several "S=,F=;" tuples may be defined.
The following formula is used to weight an update server: f(s):
To distribute update requests, each server maintains a list of active update servers. The first update server is allocated the first f(s) requests, and then it is the turn of the next server on the list.
The dispatching of update2 requests involves first checking that one or more servers have update2 work processes (that is, offer the update2 service). If several servers have update2 work processes, requests are distributed among them in a similar way to update1 requests. If there is no server offering the update2 service, update2 requests are dispatched to the regular update servers and handled by update1 work processes.
The following parameters control dispatching:
| Parameter | Value | |
| rdisp/vb_dispatching | 0 Dispatching not active | |
| 1 Dispatching active | Default: 1 | |
| rdisp/vb_factor | update server weighting control | |
| (see above) | ||
| default: Factor 1 | ||
| rdisp/vb_refresh_info | time in secs between update | |
| server list refreshes | ||
| Default: 600 seconds | ||
| Time set can be manually overriden | ||
| and refresh activated using | ||
| transaction SM13 | ||
| (Administration -> Reset). | ||
| rdisp/max_vb_server | Max. No. of update | |
| servers considered for dispatching, | ||
| default: 50 servers | ||
| rdisp/wp_no_vb2 | No. of update2 work processes at server | |
| default: 0 work processes |
Previously, when an update server was brought down, any update requests allocated to it either had to be restarted manually, or they were carried out when the server in question was restarted. Release 3.0 implements the automatic re-dispatch of pending requests in these circumstances, provided, of course, another update server is active. Automatic re-dispatching means that the loss of an update server does not cause any noticeable deterioration in overall system availability.