http://www.cnblogs.com/helileng/archive/2010/10/15/1852237.html

轉載

SAP的進程種類分：前臺進程、後臺進程、打印進程、更新進程、隊列進程

其中更新進程分兩種，V1和V2,如下圖顯示：

更新方式決定了它的處理模式，首先在對話框程序中的所有V1的要求是可以獨立的數據庫LUW中。只有當他們成功地執行處理，才會觸發獨立LUWs V2的請求。

（→V1的- / v2更新階段）

v2更新模式用於數據庫鏈接到V1的變化（主要的變化），但不一定要在執行相同的DB LUW的變化（例如，統計更新）。

V1的更新模式，可重新啟動或不重新啟動。如果出現了更新錯誤，您可以手動重新啟動該更新，使用事務SM13。這樣做之後，已經清除了有問題的應用程序錯誤。 如果出現了錯誤，v2更新模式可以隨時重新啟動處理。

collective run是V2更新模式的一個特殊類型，所有的修改請求不直接被更新，而是在V1更新之後，但只有在收集程序RSM13005（總體規劃前）被調用後。

下圖是一般的V1和V2的更新請求工作原理

V1的請求是通過V1的更新模式創建的。對於同步或異步的V1更新模式是被創建在VBLOG表中，對於本地更新來說，V1的請求是保留在主內存中。而V2的請求總是存儲在VBLOG表。

下圖是更新的執行

V1的請求處理在一個V1的更新工作進程中作為一個獨立的數據庫LUW，如果V1的更新已成功，系統將刪除V1的要求和所有的相關鎖，設置一個DB Commit和觸發器
在V2的更新

V2的請求也是執行在V2的工作進程中，也是獨立的數據庫LUW。如果系統中沒有V2的更新進程，那麽V2的更新會用V1的更新進程。如果V2執行成功，將刪除VBLOG中的數據並執行DB COMMIT。V2的更新不會產生鎖

如果V1的請求發生錯誤，所有的相關鎖就會被刪除，發生數據庫回滾時，會給創建LUW的用戶發送郵件，同時在VBLOG的標記為不正確的錯誤消息，V2進程不會被觸發。

同樣，V2也是這樣。

更新中的鎖設置

從程序使用_scope對話框創建鎖定= 2（默認）被轉移到V1的更新任務在提交工作（等待）。在V1的更新結束後，它們會自動刪除，不論V1的升級成功或更新是否發生錯誤而終止
與終止消息的問題。所以鎖不必須刪除，不管在程序中還是在更新模式中。而V2是不會產生任何鎖的。

每次變化更新到數據庫中，記錄被改變的物理數據庫鎖定到當前數據庫的結束LUW中（提交或DB數據庫回滾）。這同樣適用，SELECT... FOR UPDATE的

修改和更新模塊：

1.創建表的時候，應該建立鎖機制為其他用戶

2.

SM13 中 V1 和 V2 的區別