本文转自华强大哥!
目前BW Delta Queue支持的三种常见Update Method有:
1. "direct delta" update method
2. "queued delta" update method
3. "unserialized V3 update" update method
Method 1:"direct delta"
当每一单据存入数据库的同时也被作为单独的一个LUW写入BW Delta Queue,
这种更新模式优势:
a.不需要在OLTP后台设定Job定期来拉取数据写入Delta Queue;
b. Delta Queue抽取结果不会受V2 Update结果影响;
这种更新模式弊端:
会比较大的影响OLTP R3系统的性能的同时写入Delta Queue>;
这种更新模式建议适用于每天修改和新增单据数量小于10000笔的OLTP系统中;
Method 2:" queued delta "
当V1 Update完成之后,抽取数据会被自动写入extraction queue,然后通过后台Job定期写入BW Delta Queue,累计10000笔单据作为一个LUW存在Delta Queue;
这种更新模式优势:
可以保证单据的顺序对列;
数据更新性能比较好;
不会受V2 Update结果影响;
Method 3:" unserialized V3 update "
当抽取的数据记录比较大并且不要求顺序的情况下可以使用此种更新模式;
这种更新模式优势:
a.相对其它的更新模式来讲对系统性能影响最小;
这种更新模式弊端:
a.更新成功与否会受V2 Update更新成功与否影响;
b.
BW段需要特殊设定来存储数据;
Summary
Method 2:" queued delta "是比较流行并且推荐使用的更新模式;
*********************我是分割线*************************
對於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更新动作也不会执行的;
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/22464099/viewspace-689417/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/22464099/viewspace-689417/