Centralized and Distributed Update Processing

From R/3 Release: 2.2A to: 3.0F

Table of Contents
Summary
Introduction
R/3 Update Processing Before Release3.0
o Central Instance Update Processing
o Distributed Update Processing
R/3 Update Processing as of Release3.0
Parameters for Update Processing
o rdisp/vbname
o rdisp/vb_dispatching
o rdisp/vb_included_server
Resource Conflicts in Update Processing
Update Process Monitoring Tools
o Update Manager
o Workload Monitor
o Work Process Overview
Further Information
Copyright
Summary
This article explains strategies for configuring update processingin R/3. It dea
ls with the update processing done in update workprocesses, where V1 and V2 upda
tes are executed.
The article is divided into the following topics:
Centralized and Distributed Update Processing: Introduction
R/3 Update Processing Before Release 3.0
R/3 Update Processing as of Release 3.0
Parameters for Update Processing
Resource Conflicts in Update Processing
Update Process Monitoring Tools
Further Information
Introduction
The R/3 System allows business data to be changed in real time. Update processes
are the means by which the physical changes to the database are performed in R/
3. You need to configure update processing so as to ensure:
High system availability
High system response time
Optimum throughput for updates in time-critical applications
R/3 Update Processing Before Release3.0
Processing can be either central instance or distributed as follows.
Central Instance Update Processing
Placing all update processes on a central instance is the most common configurat
ion. The central instance is located on the same server as the database and the
enqueue service. This ensures high availability because the database is availabl
e to keep the R/3 System running, and application servers can be shut down indep
endently.
Distributed Update Processing
This is where each instance processes its own update requests locally. Distribut
ed update processing can be used to:
Avoid a CPU bottleneck on the update server for system with a high workload
Separate applications to avoid a conflict between time-critical and non-time-cri
tical updates.
The disadvantage of distributed update processing is that each separate instance
does not have the combined capacity of all update processes. Consider the follo
wing comparison:
Central Instance
Update Processing If there are 10 update processes on the central instance
, the update requests of the whole system can be distributed among these process
es.
Distributed
Update Processing If there are 2 update processes on each of 5 servers, ea
ch server has only 2 processes it can use. If all update processes are blocked o
n one server, the updates cannot be switched to the other servers, but are store
d in the wait queue.
See also R/3 Note 7209.
R/3 Update Processing as of Release3.0
Automatic update dispatching distributes update work among all available instanc
es. This automatically optimizes system availability for update processing. The
update workload is distributed according to the number of update processes confi
gured for each instance(divided by the total number of available update processe
s), regardless of the current workload of that instance.
Update dispatching is activated by default through parameter rdisp/vb_dispatchin
g= 1. This is the best configuration for most installations. Sometimes it is use
ful to reserve some update processes exclusively for special data, by withholdin
g these processes from update dispatching.
For example, special data can be the time-critical data of customer telephone or
ders. One of the R/3 instances, instance A, can be separated from the update dis
patching function and reserved for updates of telephone orders. Ensure that:
update requests created on instance A are processed by the local update processe
s. The instance profile should contain theentry:
rdisp/vb_dispatching = 0, rdisp/vbname = ($myname).
no other instances process their update requests on instance A. The file DEFAULT
.PFL should contain the entry:
rdisp/vb_included_server = <List of instances to be used for updates>.
See also the R/3 Knowledge Products CD System Management. Look under Design Work
load Balancing and Dynamic Update Distribution.
Parameters for Update Processing
rdisp/vbname
Before R/3 Release 3.0
Parameter rdisp/vbname assigns the instance to be usedfor update processing.
For local update processing, rdisp/vbname = ($myname).
For central update processing, the parameter in the file DEFAULT.PFLis set to a
central update instance.
As of R/3 Releases 3.0
Parameter rdisp/vbname assigns the instance to be used for update processing whe
n the dispatcher is not activated, that is, when rdisp/vb_dispatching = 0.
If rdisp/vb_dispatching = 1, the parameter rdisp/vbnamemust indicate an instance
configured for update processing andshould be set in the DEFAULT.PFL for all in
stances.
rdisp/vb_dispatching
This parameter can be used as of R/3 Release 3.0.
The default is 1, which means that update dispatching is activated.
To separate the update processing capacity of an instance fromthe update dispatc
hing process, set this parameter to 0 in theinstance profile. Ensure that no V2
processes are defined in theinstance profile. See R/3 Note 74550.
rdisp/vb_included_server
This parameter can be used as of R/3 Release 3.0.
The default setting lists all instances performing update processing.Parameter r
disp/vb_included_server excludes an update processinginstance from update dispat
ching.
Do not use this method only to improve application throughput.You can improve th
roughput by other methods that do not reducethe number of update processes avail
able to the update dispatchingfunction. For example, start dialogor background p
rocessing using the ABAP/4 command SET UPDATE TASKLOCAL.
Resource Conflicts in Update Processing
You can help prevent a resource conflict by using a distributedupdate configurat
ion in R/3 Releases prior to 3.0, or changingthe setup for update processing as
of Release 3.0. A resourceconflict may occur when:
A time-critical application creates online update requeststhat have to compete w
ith a system-wide update load
A job rapidly generates a large number of update requests,causing a blockage. Fo
r example, when a time-critical interfaceto an external system is used, or durin
g Batch Input.
A resource conflict can result in differing numbers of updaterequests being bloc
ked, depending on the type of update processingbeing used:
Type of Update Processing Performance During Resource Conflict
Updates generated by Batch Input sessions using table APQD. These ar
e synchronous, which means that the work process waits until each update request
has been processed before it creates the next update. Thus during runtime a max
imum of one update work process can be blocked.
Synchronous updates generated
by Batch Input sessions using the ABAP/4 command CALL TRANSACTION USING.
For a synchronous update, a maximum of one work process can be blocked.
Asynchronous updates generated
by Batch Input Sessions using the ABAP/4 command CALL TRANSACTION USING and exec
uted in background mode. After every hundredth update, the system
waits until all 100 updates are performed, thus limiting the potentially blocke
d updates to 100 in number.
Asynchronous updates generated
by Batch Input sessions using the ABAP/4 command CALL TRANSACTION USING and exec
uted in dialog mode. This type of update processing can lead to a blo
ckage, because the system continues rapidly generating update requests instead o
f waiting for update processing to be completed.
Update Process Monitoring Tools
Update Manager
Use transaction code SM13. The Update Manager displays VBLOG update log tables,
in particular VBHDR, VBMOD and VBDATA. If update throughput is optimal, the tabl
es do not have many entries, and display only recent update requests.
If there is a bottleneck in update processing, the list of pending updates with
INIT status grows, as does the number of lock records, which you can display usi
ng transaction code SM12.
If there is a critical database error, update processing is automatically deacti
vated. Notify the system administrator.
Workload Monitor
Use transaction code ST03. The Workload Monitor lets you monitor update performa
nce using response time statistics. Total response time for each update is displ
ayed divided into database time, processing time and wait time.
Long database times can be caused by an overall database performance problem or
by exclusive database locks.
Compare processing time with the corresponding CPU time. If processing time is c
onsiderably longer than CPU time, this may indicate a CPU bottleneck. See SAP Tr
aining WorkshopBC315 on Workload Analysis.
Long wait times either mean that update processes are taking too long to make ch
anges to the database, or that not enough update processes are available.
Work Process Overview
Use transaction code SM66. Choose Select Process Update, then under Status selec
t all options except Only waiting for semaphore. To display work process utiliza
tion, select CPU.
Update work process utilization is optimal, if the last update process for each
instance used hardly any CPU time, while the first listed update process used mu
ch more CPU than all the other update processes.
If CPU time is similar for all update processes, not enough update processes are
available.
This indicates a bottleneck. Increase the number of update processes.
If the update processes for an instance have used no CPU time, despite updates h
aving occurred, check the parameter settings.
See also:
Transaction RZ11 using rdisp/vb* in the online documentation.
R/3 Notes in CSP and OSS Systems:
R/3 Note 7209 on Parameters for R/3 Release 2.2
R/3 Note 51234 on No Update Server Found
SAP TechNet Knowledge Base Article
Topic: System Monitoring
Subtopic: Workload Balancing
Keywords: Update processing, Workload Monitor, Monitoring, Update Manager,
VBLOG, synchronous, asynchronous