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中記錄的標識後，再從新運行增量信息包。