Scenario faced by someone.
Platform: BW3.5
Scenario:
ODS ZA was updated by 3 other source ODSs, ZB, ZC, ZD using delta for about a year. ZA, ZB, ZC, ZD are in the process chain loading daily.
ODS ZE was newly added to be updated from ZB. Init was done on the weekend for ZE. Delta was added to the same process chain.
The process chain stopped with error at ZA activation on Monday with the following message.
ODS object ZA was built incorrectly. Cannot update request REQU_[xxxxxxxxxxxxxxxxx](88,109)
Message no. RSM1147
Diagnosis
Request 87,880 has still not been uploaded.
I checked 88,109, it’s a request from ZB. I couldn’t see anything missing in between ZB and ZA.
So, what is 87,880? Where can I find the reference of Request ID?
The answer is in table RSICCONT. It provides the request ID and which data target the request was loaded.
As it turned out, 87,880 was updated to ZE. It is the init request. So BW thinks the init done on ZE should also be done on ZA. However, that’s not what I intended to do. My intention was to bring ZE up to the current data and delta ZA and ZE at the same time. Looks like I missed a step. I should have also init ZA without data transfer so that both ZA and ZE are ready for delta. At this point, the delta is not acceptable by ZA. I can either full load ZA or make sure ZA data is current and do an init without data transfer on both ZA and ZE.
I looked into PSA for change logs of 8ZB. Luckily, I can load by order ID.
So I deleted the error delta in ZA
Then I did a full repair load from ZB to ZA for the same order ID range as the delta.
Then init without data transfer on both ZA and ZE.
The problem was fixed.
It would not be an easy fix if no pattern to be found for repair full load with range, which means, you might have to do full load without range. So lesson learned:
If multiple delta exists from the same source, and if they are not init at the same time. Make sure to do an init without data transfer for all data targets if the new one is aded.
Platform: BW3.5
Scenario:
ODS ZA was updated by 3 other source ODSs, ZB, ZC, ZD using delta for about a year. ZA, ZB, ZC, ZD are in the process chain loading daily.
ODS ZE was newly added to be updated from ZB. Init was done on the weekend for ZE. Delta was added to the same process chain.
The process chain stopped with error at ZA activation on Monday with the following message.
ODS object ZA was built incorrectly. Cannot update request REQU_[xxxxxxxxxxxxxxxxx](88,109)
Message no. RSM1147
Diagnosis
Request 87,880 has still not been uploaded.
I checked 88,109, it’s a request from ZB. I couldn’t see anything missing in between ZB and ZA.
So, what is 87,880? Where can I find the reference of Request ID?
The answer is in table RSICCONT. It provides the request ID and which data target the request was loaded.
As it turned out, 87,880 was updated to ZE. It is the init request. So BW thinks the init done on ZE should also be done on ZA. However, that’s not what I intended to do. My intention was to bring ZE up to the current data and delta ZA and ZE at the same time. Looks like I missed a step. I should have also init ZA without data transfer so that both ZA and ZE are ready for delta. At this point, the delta is not acceptable by ZA. I can either full load ZA or make sure ZA data is current and do an init without data transfer on both ZA and ZE.
I looked into PSA for change logs of 8ZB. Luckily, I can load by order ID.
So I deleted the error delta in ZA
Then I did a full repair load from ZB to ZA for the same order ID range as the delta.
Then init without data transfer on both ZA and ZE.
The problem was fixed.
It would not be an easy fix if no pattern to be found for repair full load with range, which means, you might have to do full load without range. So lesson learned:
If multiple delta exists from the same source, and if they are not init at the same time. Make sure to do an init without data transfer for all data targets if the new one is aded.
Posts
0 comments:
Post a Comment