UPDATE PROCESS

[samarjeet_singh]

UPDATE PROCESS

It is used to update the database.

Types of Update Mechanism-:

• Local Update-:

       The process of updating records by a dialog process directly/locally on the database. It is also called as Single Step update.

• Asynchronous Update-:

If a transaction contains more than a dialog step then Intermediate commits are pasted in temporary tables, without updating permanent transaction tables.

• Synchronous Update-:

Once all the dialog steps of a transaction are committed then update process reads temp tables and updates permanent tables synchronously.

Types of Update processes-:

1. V1
2. V2
3. V3

Parameter-:

                        rdisp/wp_no_vb

V1-:

            It is used to handle the time critical updates. There should be at least one update process of type V1 is required on the system. It is configured by the parameter

                        rdisp/wp_no_vb

V2-:

            It is used to handle non-time critical updates (requests). It is configured by the parameter

                        rdisp/wp_no_vb2

If VB2 work processes are not configured these tasks are dealt with V1 work process.

V3-:

            These are reserved by SAP and used for BW Updates, Logistics Updates.

PROCESS FLOW-:

1. The user request is submitted to the dispatcher.
2. The dialog process handles the user request.
3. When dialog process identifies the update/insert/modify then it communicates with server to obtain a lock on the record so that no user should update (however other users can display the record)
4. The dialog process updates all the dialog steps in TEMPORARY tables

VBHDR-:       Update Header

                          VBDATA-:     Update Data

                          VBMOD-:       Update Modules

                          VBERROR-:  Update Errors

And once it is committed then however the task to update which can be displayed SM13

    5. The update process updates the database permanent tables based on the update Modules (VBMOD). Update Modules specify the modularity to update one or more tables based on the functionality.

Example-:

                  A sales document that is created in VA01 is updated into more than 140 tables.

    6. Updates records are released from SM13

When the records are committed by the dialog process the records are displayed in SM13 with STATUS “INIT”

• If the update is running the update then its status is “RUN”
• If the update is thrown into an error then the status is “ERROR”
• If the update are restarted after an update deactivation/activation the updates are updated with status “AUTO”

There should be at least one update process for the 5 Dialog work process.

*** “INIT” for longer time-:

                                              The update processes are not sufficient or existing processes are held with transactional updates (expensive updates) or the updates are blocked with deadlocks.

1. Error (No retry)àThe update process has been cancelled and cannot be restarted.

Update Process Deactivation-:

                                                    Whenever there is a problem with database like (table space overflow, archive stuck) then the updates hangs, to avoid this situation set the update to deactivate using parameter.

rdisp/vb_stop_active = 0

                                    by default it is 1

                                   FLOW

1. User submits the request for an update.
2. The request is received by dispatcher and keeps it in wait queue.
3. Based on freely available dialog process, the dispatcher allocates a process to user request.
4. When dialog identifies update then it communicates with enqueue process to obtain lock on the record, so that no other user modifies it and has only a display access.
5. If the update request is made on the application server (dialog instance) then dialog communicates with message server àenqueue serveràprovides lockàmessage serveràback to dialog.
6. Dialog process updates each of the dialog steps in the temporary tables (VBHDR,VBDATA,VBMOD,VBERROR)
7. Dialog process obtains a transaction ID from number range interval table NRIV (the number ranges are configured by functional team in transaction SNRO).
8. The dialog transfers the task to update process to update the database with status “INIT”
9. Update process updates the database.

UPDATE ERROR and ISSUES

1.      Program errors which can be resolved by applying patches/support packages, notes etc.

2.      Table space overflow (ORA-1653 and ORA-1654) add data file/resize data files.

3.      Max extents reached (ORA-1631 and ORA-1632) add extents.

4.      Update deactivated after KERNEL upgrade. Check whether right KERNEL version is deployed (if required roll back KERNEL).

5.      Update is terminated due to an error (if the error is resolved it will restart with status “AUTO”). If it is not restarted then select the record in SM13 and                repeat update (starts with Auto) but now the update is throwing an error INSERT_DUPLICATE RECORD FAILED. If the record exists then                     

         Insert_duplicate record error occurs.

6.      Dead locks issue inform SAP (SAP provides NOTES to resolve the deadlocks).

7.      Kernel issue (if kernel is old or outdated or updated then error may occurs).

UPDATE REORGANIZATION

These are used to housekeep the temporary tables (VB* tables)

Run the report RSM13002 to delete the old update requests.

Set the parameter

                                    rdisp/vbreorg = 1

This parameter specifies whether incomplete (error) update requests should be deleted as an update server is started. As these incomplete updates requests can never be executed and only occupy space in the Database, you should delete them from time to time by executing report.

                                    RSM13002

Update Parameters

1.      rdisp/wp_no_vb

2.      rdisp/wp_no_vb2

3.      rdisp/vb_stop_active (to allow update to get deactivated during an error)

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;

Set it to “0” to deactivate it, in case of an error.

4.      rdisp/vbdelete  =30/50 days

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.

            UPDATE ADMINISTRATION

It is used to monitor the status of the update mechanism. Check as part of monitoring and update the check list.

When update is deactivated it will write the error logs into SM21 an ST22. Analyze the error log with high priority (critical) and resolve the issue.

Update process stuck the entire system

The user requests are handles by Dialog process and handover the updates to update process. If updates are slow/deactivated/issue with database then all updates hangs subsequently the entire system hangs.

1. Check SM66, SM50, SM21, and ST22 for any critical errors in the system.
2. Check the reasons for the update stuck and resolve the error. If V2 processes are not configured then V1 handles the tasks of the V2.

Regards

Samar