System Profile Parameters for the Update

rdisp/vb_dispatching

Activates Update Dispatching with Load Balancing (1, 0).

Do not change this value unless instructed to do so by SAP.

1

rdisp/vbname

Specifies the name of the update server that processes updates if load balancing is switched off.

If rdisp/vb_dispatching = 0, then updates are processed only by the server in rdisp/vbname. If the parameter is set wrong (not to an update server, then this is reported in the installation check (transaction SICK).

-

rdisp/vb_delete_after_execution

Determines whether updates records are automatically deleted after successful processing.

Value 2 turns automatic deletion off. This value may be set to tune update and database performance. If set, then report RSM13002 with the parameter DELETE = X should run at least once daily in the background processing system to prevent the update tables from becoming too large.

1 (automatic deletion activated)

rdisp/max_vb_server

Maximum number of update servers permitted in the SAP system.

50

rdisp/vb_included_server

List of SAP update servers to be used to process updates in accordance with load balancing principles. Update servers that do not appear in the list are not given updates to process.

-

(All active update servers are included in the load balancing mechanism)

rdisp/vbdelete

Specifies the number of days after which update records are deleted.

When this period elapses, an update record is deleted regardless of its status (processed, unprocessed, error, etc.).

Setting the parameter to 0 deactivates automatic deletion. This value should be set only temporarily and only if you need to keep an incorrect record for further analysis.

50 (50 days)

rdisp/vbmail

Determines whether to send an express mail to a user whose update has failed.

If an update is terminated prematurely, the system sends an express mail via SAP Mail to the user that created the update. The value 0 deactivates automatic mailing.

1 (active)

rdisp/vbreorg

Determines whether update servers, when they are started, check for and delete incomplete update records. Incomplete records can be created if a transaction registers one or more update components, a database commit is generated by a change of screen in the generating transaction, but the transaction is terminated abnormally, causing a rollback.

Incomplete records have no significance, but occupy space in the database. For this reason, this reorganization is active by default.

You can deactivate reorganization by setting the parameter to 0. In this case you should still ensure that report RSM13002 is run regularly in the background to delete incomplete update records.

1 (active)

rdisp/vbstart

Determines whether unprocessed or unfinished (status run, Update components not processed, etc.) update requests are automatically processed when an update server is started. By default, these records (usually with status auto) are processed.

Value 0 deactivates automatic processing. Normally, only SAP may change the value of this parameter.

1

rdisp/vb_context

Lets you determine how the U1 update dispatching is done. You can interpret this parameter as a bit map:

• Bit 0 : For dispatching the database group should be kept

• Bit 1 : During dispatching, an update server must be chosen that has the current language installed.

The value 3 (both bits are set) means that an update server is selected during update dispatching that is in the same database group and has the current language installed.

Only make changes to correct errors

3 (both bits set)

rdisp/vb2_context

Like rdisp/vb_context, this parameter controls update dispatching for V2 updates.

3 (both bits set)

rdisp/vb_factor

Dispatching update requests occurs in a simple process, as described in Dispatching with Load-Balancing.

This parameter lets you determine the number of update work processes relevant for dispatching, for example, to assign more update requests to faster servers. This number is determined by the current number of update processes and the value of rdisp/vb_factor.

After processing the U1 update requests, the U2 part is “dispatched”.

The parameter value must have the following syntax: rdisp/vb_factor = S=<instance name>,F=<factor>; … S=<instance name>,F=<factor>;

rdisp/vb_key_comp

With parameter rdisp/vb_key_comp the structure of the update key can be changed. Normally, the key consists of data, time, microseconds, host name, system number, and the work process number.

To maintain a more efficient index structure, using the parameter settings you can bring forward changeable elements.

/HOST/SYNR/WPNR/DATE/TIME/STMP/

rdisp/vb_refresh_info

This defines the time span after which the context of an update server is redetermined. The number of update work processes of the server, and the code page, and DB node of the servers are part of the context.

The context of the update server can change due to changes in the operating types. Therefore, the context is read again only every hour.

3600 (1 hour)

rdisp/vb_v2_start

This specifies whether the V2 phase of an update request is automatically processed after the V1 phase, or is triggered later by a background job.

Possible values:

• 1: V2 phase is started immediately after the V1 phase

• 2: V2 phase is not started automatically

1