There are three types of Updates that can occurs to the database, depending upon the priorty given to the work.
V1 – Synchronous update
V2 – Asynchronous update
V3 – Batch asynchronous update
These are different work processes on the application server that takes the update LUW (which may have various DB manipulation SQLs) from the running program and execute it. These are separated to optimize transaction processing capabilities.
Synchronous Updating (V1 Update)
The statistics update is made synchronously with the document update.
While updating, if problems that result in the termination of the statistics update occur, the original documents are NOT saved. The cause of the termination should be investigated and the problem solved. Subsequently, the documents can be entered again.
Asynchronous Updating (V2 Update)
With this update type, the document update is made separately from the statistics update. A termination of the statistics update has NO influence on the document update (see V1 Update).
Asynchronous Updating (V3 Update)
With this update type, updating is made separately from the document update. The difference between this update type and the V2 Update lies, however, with the time schedule. If the V3 update is active, then the update can be executed at a later time.
If you create/change a purchase order (me21n/me22n), when you press ‘SAVE’ and see a success message (PO…. changed..), the update to underlying tables EKKO/EKPO has happened (before you saw the message). This update was executed in the V1 work process.
There are some statistics collecting tables in the system which can capture data for reporting. For example, LIS table S012 stores purchasing data (it is the same data as EKKO/EKPO stored redundantly, but in a different structure to optimize reporting). Now, these tables are updated with the txn you just posted, in a V2 process. Depending on system load, this may happen a few seconds later (after you saw the success message). You can see V1/V2/V3 queues in SM12 or SM13.
V3 is specifically for BW extraction. The update LUW for these is sent to V3 but is not executed immediately. You have to schedule a job (eg in LBWE definitions) to process these. This is again to optimize performance.
V2 and V3 are separated from V1 as these are not as realtime critical (updating statistical data). If all these updates were put together in one LUW, system performance (concurrency, locking etc) would be impacted.
Serialized V3 update is called after V2 has happened (this is how the code running these updates is written) so if you have both V2 and V3 updates from a txn, if V2 fails or is waiting, V3 will not happen yet.
BTW, ‘serialized’ V3 is discontinued now, in later releases of PI you will have only unserialized V3.
In contrast to V1 and V2 Updates , no single documents are updated. The V3 update is, therefore, also described as a collective update.
Creating Update Modules
Update Modules can be created as follows:
1. ChooseTools – > ABAP Workbench,Function Builder.
2. To be able to call a function module in an update work process, you must flag it in the Function Builder. When you create the function module, set the Process Type attribute to one of the following values:
Update with immediate start
Set this option for high priority (“V1”) functions that run in a shared (SAP LUW). These functions can be restarted by the update task in case of errors.
Update w. imm. start, no restart
Set this option for high priority (“V1”) functions that run in a shared (SAP LUW). These functions may not be restarted by the update task.
Update with delayed start
Set this option for low priority (“V2”) functions that run in their own update transactions. These functions can be restarted by the update task in case of errors.
Unlike V1 and V2 updates, V3 updates (or collective runs) are not started directly. The update is performed by a background job (report RSM13005). In this case, the update requests are not updated separately, but rather all modules of the same type are updated in a single database transaction. As the database can operate with far fewer database transactions, system performance is dramatically improved. Background jobs should be started in Customizing of the relevant applications that use the V3 update.
Summing Up !
V1: The update should be performed soon. The update record is protected by R/3 locks. The update is critical for the operational consistency of the system.
V2: The update does not have to be performed soon. The update is not protected by locks. The update modules do not contain “vital” data.
V3: As V2, but, you use report RSM13005 to start the updates.
Note that the V3 update offers an advantage with regard to speed when considering its disadvantages. Report RSM13005 also eliminates some of the disadvantages of the V3 update.