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中记录的标识后，再重新运行增量信息包。