Hi All,
My cube to cube load is taking time in "Find or take SIDs" step.
I guess this step is newly introduce in 7.3 or it could have replaced Generating SIDs.
This step takes 60% of the load runtime.
I already have buffering active on my dimention SID number range.
Any advice.
Regards,
Hi Virani,
If you schedule respective master data loads before this transaction loads.
then it may won't take that much time.
1. load master data loads and ACR thru process chains
2. run transactional data loads.
Thanks
Hello,
Which is the BW Support Package you are using currently?
Since we have upgraded to 7.3 SP9 (from SP5) we have this issue for one our our infocube.
In our transformation, there is no read master data, just direct mapping between 2 cubes.
Even if I launched a brconnect to refresh statistics of this cube, result is still the same.
I was wondering if it cannot be a regression link to our last SP upgrade?
Regards,
We removed the "parallel processing" of the DTP into Infocubes. It appeared to get a table lock when trying to retrieve the SIDs. Don't know if this is a flaw but we saw 3 entries in SM12 equivalent to the parallel processing in batch we have set as 3. If we set it at 1, it loads fine and doesn't get hung up.
We are already loading the master data ahead of the Trans data process chain so that is not the cause. This only happened on certain loads. Not the same issue on the same load twice. Instead we split the DTPs into 3 loads using the data selection criteria and set the loads to run serially. It loaded find then.
Just FYI on the work around.
Sure would be nice to determine why it does this as I would have thought parallel processing would have catered for this. why does it happen on some loads and not others? why if I run the same DTP twice on the same day, it can run fine the first time, then lock up the second?
Add a comment