1) The
update work process handles database update operations
2) SAP
transactions usually consists of several dialogue steps i.e., it creates a log
record for dialogue step in SAP transaction in the VBLOG table for database
update.
3) Update
work process later process the log record at the end of the SAP transaction.
4) Update
Service
i) Create update request
ii)
Send update message
iii) Read update request
iv)
Implement update request
5) While
doing the updating object has to be locked for not execute other requests at
the same time. Otherwise it might leads
to database inconsistency.
6) The
locking mechanism will be taken care by enqueue work process.
7) Dialogue
work process updates the data to the temporary tables. From temporary tables
update work process update the data directly to the database.
8) The
list of temporary tables are
i)
VBHDR : Contains header information
ii) VBMOD: contains modification of updated data
iii) VBDATA: contains actual updated data
iv) VBERROR: Error information will be stored
v) VBWORK: work list for mass processing
9) Update
process are of three types
i)
Local
Update: in this dialogue work process will update the data
directly to database. This case occurs when dialogue work process dealing a
small transaction.
ii)
Asynchronous
Update: This case occurs when dialogue work process is writing
the data to the temporary tables.
iii)
Synchronous
Update: This case occurs when update work process will write the
temporary table data to the database.
10) In each and every system there are two update
work processes. Those are UPD and UPD2.
11) UPD will take care of all critical updates and
UPD2 will take care of all non critical updates.
12) The
configuration of update work process depends on dialogue work process in
general we need one update work process for each and every 5 dialogue work
processes.
13) From
SM13 T-code we will check the all update processes.
14) Update
process status are
1) Cancelled
2) To
be updated
3) V1
executed
4) V2
executed
15) While running update processes there are four
update stages
1) I
(INIT): It will initialize the update records
2) N
(RUN): Update is started in main memory
3) O(AUTO): When we got any update errors after solving those errors the update
process starts automatically.
4) F
(Error): Error in the process
16) From SM14 we can activate or deactivate the update
process.
17) The update errors will occur when
i)
DB Errors
ii)
Program Errors
iii)
Table overflow
iv)
Network issues
v)
When less number of work processes are
configured
Update
Work Process Profile Parameters:
1)
rdisp/wp_no_vb:
number of update work processes
Default
value: 0
Recommended:
2
2) rdisp/vbmail:
Send mail in case of an update error
If
update errors occur, the user is informed by the sending of an Express mail.
You can deactivate this mail:
Parameter value = 1: A mail is sent
Parameter value = 0: No mail is sent
3) rdisp/vbname:
Name of the update server
4) rdisp/vbreorg:
deletion of old update requests
This
parameter specifies whether incomplete update requests should be deleted as an
update server is started. This type of request can occur if a transaction has
already saved function modules in the update tables and executed an implicit
COMMIT WORK at a screen change, after which a rollback occurred. As these
incomplete update requests can never be executed and only occupy space in the database,
you should delete them from time to time.
Alternatively
to deleting incomplete update requests at the start of an update server, you
can use background job rsm13002 to delete them. In this case, you can set the
parameter to 0. This means that no reorganization is performed when the update
server is started.
Default
value: 1 (a reorganization is executed when the update server is started).
5) rdisp/auto_vb_stop:
DB errors will stop update task automatically
Update
automatically stops when database errors occur.
The
possible values are:
0 No automatic stop
1 Automatic stop
Default:
1
6) rdisp/vb_lock_mode:
handling of sap enqueues after update error
This
parameter defines the handling of the SAP locks inherited by the update process
after update terminations. There are three variants: - the locks are released.
This should mean that important system resources do not remain locked after update
termination. The parameter value for this variant is RELEASE.
·
The locks remain in place. The parameter
value for this variant is HOLD.
·
The locks only remain in place if the update
was externally and was previously in
the status PREPARE. The parameter value for this variant is HOLD_AFTER_PREPARE.
Default value:
RELEASE
7) rdisp/vbdelete:
Delete old update requests
The
parameter specifies the duration in days, after which an update request is
deleted. At the end of this period, the update requests are deleted
irrespective of their status. If the parameter has the value 0, the update
requests are not deleted.
Default
value: 50 days
8) rdisp/vb_stop_active:
You
can deactivate the SAP update as follows: - By manual deactivation (SM14 or
SM13 Update records -> Update -> Deactivate)
-
When severe database problems occur, the system deactivates the update process.
This
parameter is used to switch off the ability to deactivate the update process.
If the value is set to 1, updating can no longer be deactivated.
Default
value: 1
9) rdisp/vb_mail_user_list:
List of users to receive mails in case of update errors
This
parameter controls which users receive an express mail "Update
terminated" when an update terminates. Usually only the affected user
receives the mail. Other or additional users can be specified. This can be
used, for example, to ensure the administrator receives all mails.
The
parameter must be entered in the profile using the syntax:
rdisp/vb_mail_user_list = <usr1> [,
<usr2> ] ...
If
the affected user is to receive the mail, use the name $ACTUSER.
Examples:
·
rdisp/vb_mail_user_list = $ACTUSER, ADMIN1,
ADMIN2 The mail is sent to the affected
user and to the users ADMIN1 and
ADMIN2.
·
rdisp/vb_mail_user_list = ADMIN. The mail is
sent to the user ADMIN.
10) rdisp/vbstart: Perform update startup actions
This
parameter controls the start-up behavior of an update server. During startup,
the update server checks in its request to see if it contains any update
requests that have not yet been executed (status init). If this is the case,
these requests are flagged and then executed. You can use this parameter to
deactivate this automatic starting:
Parameter value 1: The automatic starting is
active
Parameter value 0: The automatic starting is
not active
Default
value: 1
