SAP BW Delta Queue 研究--V1/V2/V3 R3 Update Model

對於R3系統中經常出現的V1/V2/V3更新方式一直存在疑惑，最近查了一些資料特總結如下便於更清晰對其瞭解，有什麼不當之處敬請各位指出… V1 - Synchronous update
V2 - Asynchronous update
V3 - Batch asynchronous update

對於資料庫表的更新如下：
1. V1 UpdateàApplication tables (R/3 tables) R/3系統各功能模組庫表；
2. V2 UpdateàStatistical tables (for reporting purpose)主要用於R/3系統報表功能；
3. V3 UpdateàUpdate tables臨時存放區域，只有在V3更新模式中使用；
4. V3 Collective RunàDelta queue BW系統的資料抽取介面；

這是在應用程式伺服器上執行更新LUW（Logic Unit of Work）三種不同的方式，透過分開採用這三種更新方式，可以實現更最佳化事務處理能力；
舉一個簡單例子說明：
在我們建立一個採購訂單（ME21N）時，當我們點選儲存按鈕系統提示成功資訊時，SAP系統更新Application tables (R/3 tables)（EKKO/EKPO）儲存記錄，此時執行的是V1的更新方式；
在系統中會存在一些系統統計資料收集庫表Statistical tables (for reporting purpose)為了實現撲捉資料呈現報表功能，像LIS系統的Table S012儲存採購相關資料，它會像EKKO/EKPO一樣儲存相同的重複資料，但它會有不同資料結構主要為實現報表功能，這些表資料也會被更新，此時完成的是V2更新方式，它的執行根據系統當時的負載程度會晚幾秒鐘相對於V1的執行，我們可以透過T_Code：SM12或者SM13檢視V1/V2/V3的更新狀態；

V3更新方式主要為BW資料抽取服務的，更新的LUW會臨時存放在Update Tables裡，需要透過後臺的Background Job（V3 Collective Run）定期把資料抽取到Delta Queue中，這種處理方式對系統效能更加最佳化；

Summary:

V2/V3更新方式和V1更新方式分開處理，由於他們不是實時關鍵部份，如果把這三個更新放在一起作為一個LUW來處理，就會非常影響系統效能；

V3更新會在V2更新完成之後執行，因此當系統V2更新失敗後，V3更新動作也不會執行的；

[@more@]

[轉載]SAP BW Delta Queue 研究--V1/V2/V3 R3 Update Model

相關文章