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更新动作也不会执行的；

更多内容请参考我的空间：
http://space.itpub.net/?9381143



[ 本帖最后由 magiclhq 于 2010-1-28 21:53 编辑 ]

http://forums.sdn.sap.com/thread.jspa?threadID=331913