BW基于ALE的主数据增量机制分析

1     概述

前段时间在项目中碰到一个问题，地点物料0MAT_PLANT_ATTR属性主数据由于有两个多月没有作增量更新，致使在以后的每次增量抽取活动中由于抽取的数据量过大使得在源系统的进程中发生short dump。

发如今这问题后，为避免增量抽取的数据量过大，先给0MAT_PLANT_ATTR从新作了一次无数据传输的初始化和FULL REPAIR UPDATE，而后再从新再作增量抽取。可是发如今源系统端的数据抽取进程中仍是发生了short dump，错误的缘由也是同样要抽取的数据量过大，致使内存发生错误，如图1.2。

 

 

图1.2

为何0MAT_PLANT_ATTR在作了初始化之后，在作增量抽取时仍是会发生数据量过大致使内存溢出的错误呢，在网上查了相关资料以及给SAP发了 MESSAGE后获得了答案。原来在BW中有一部分主数据的抽取是基于ALE增量机制，该类型的增量数据保存在表BDCPV中，由字段PROCESS标识 数据是否已经抽取过，如图1.3所示。按正常状况，数据源作完初始化后，应该将初始化时间点前的全部数据都打上已处理标记，这样下次增量抽取时就能够避免 重复抽取这部份数据，可是显然SAP因为某些缘由（应该算是SAP的一个BUG）忽略了这一点，致使数据抽取出现异常（固然必定要数据量够大时才会出现问 题）。这一类型的主数据增量不会保存在队列中，即虽然在RSA7中能够看到数据源0MAT_PLANT_ATTR，可是查不到任何数据，这一类数据源也不 支持重复增量。

2     查看数据源的增量处理类型

在源系统端运行TCODE: RSA2，能够查看该数据源是否支持ALE指针增量机制，怎么鉴别一个数据源所对应的消息类型呢，能够经过表ROOSGEN来查看。查到数据源对应的消息类型后，还须要查看该消息类型是否已经激活，能够经过表TBDA2查看。

3     主数据和BDCPV之间的关系

以物料属性0MATERIAL_ATTR数据源为例，说明一下主数据更新和表BDCPV之间的关系。物料属性的更新在MM01中进行，当咱们增长或修改了 某一个物料后，数据不但保存在MARA，并且还会将修改的数据保存到表BDCPV中，当咱们在MM01中新增长一个物料后，表BDCPV中也增长了一条数 据记录，消息类型为RS0059（每一个系统都有本身的消息类型，不是统一的），在CREATETIME为20091211103441时，表MARA也生 成了一条新数据（Change ID为‘I’）。

物料属性0MATERIAL_ATTR数据源执行FULL UPDATE或DELTA PROCESS时，extractor function module会使用不一样的方法读取相应的数据，如图3.1所示，当是Full或Initial的时候，数据从Base Table中读取，当是Delta时，数据从BDCPV中读取。

图3.1

4     增量抽取出现错误时的处理办法

在其余类型的增量数据处理中，若是当前的增量处理出现失败的状况，通常的处理办法是将当前请求置红，将目标数据中的请求删除，这样在下次作增量抽取时会自 动从新抽取此次没有抽成功的数据。可是在基于ALE的增量抽取机制中不支持重复抽取，所以不能简单的置红删除。而是须要先将错误请求置绿，处理好 BDCPV中记录的标识后，再从新运行增量信息包。