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

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@]

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/443058/viewspace-1044448/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/443058/viewspace-1044448/