cancel
Showing results for 
Search instead for 
Did you mean: 

data load takes long time at Find or Take SIDs step

Former Member
0 Kudos

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,

Accepted Solutions (1)

Accepted Solutions (1)

RamanKorrapati
Active Contributor
0 Kudos

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

Former Member
0 Kudos

Thakns Raman,

But I don't get the master data seperately ..

some values for the charasticts are received such loads only.

Previous load are taking 1 min and few seconds for this step.

However I have referesh the stats of the cube last night and that seems to be of some help. (I don't know how but it did).

now its taking average time.

Thanks for the help.

RamanKorrapati
Active Contributor
0 Kudos

Hi Virani,

May be during your loads, some others loads or specials load may be scheduled. that also may cause.

You can check the time when you load was started and check other jobs which are trigger at the same time.

Thanks

Answers (2)

Answers (2)

Former Member
0 Kudos

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? 

Former Member
0 Kudos

My cube to cube load is taking long in "Find or take SIDs" step.

There is transformation step with one to one mapping from one cube to other.

I turned ON Number Range Buffering also.  No Luck.

This is a everyday load.  Take about 6.5 hours to complete.

Any advise please?

Former Member
0 Kudos

Did you make sure you are loading all the relevant master data - texts, attributes before you are doing the transactional loads?  If the cube load can't find the SID, it has to go load the new SID into the SID table first before putting it in the cube SID.  That kills your load.  Make sure to run hier/attr change run after any ATTR loads too.

Also if you have any master data lookups, in your rules, make sure you load those SID objects prior too.

Check transfer routines.  make sure they are select single * coded so there is no open cursor required for looping.

0 Kudos

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,

Former Member
0 Kudos

Hi ,,

I will recommend to refresh statisticts for the target cube..

because it reads the current cube for the exisitng SIDs and if not found creates the new one.

Even in one to one mapping if the characterstics values is not present in the traget cube create a SID for it.

and yes we are on SP9.

Cheers

AL

0 Kudos

Hello,

We refreshed already statistics, and increase number range buffer for dimension & master data, but it's still much more longer in SP9 than in SP5, something has changed in the way how SID are retrieved.

If we desactivate bitmap conversion index at DB level, situation is better but it does not explain why between SP5 and SP9 we have a such difference in term of performance.

Regards,

Ozgu
Explorer
0 Kudos

Hi,

We have same problem in our cubes. It takes nearly 1 hour for 50.000 records.

What is the improvement percantage of deactivating bitmap conversion index at DB level?

Regards,

Ozgu