Skip to Content
author's profile photo Former Member
0
Former Member

data load takes long time at Find or Take SIDs step

Posted on Jul 08, 2013 at 10:48 AM 267 Views

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,

Add a comment
10|10000 characters needed characters exceeded

Assigned Tags

Related questions

3 Answers

  • Best Answer
    author's profile photo Raman Korrapati
    Raman Korrapati
    Posted on Jul 08, 2013 at 01:18 PM
    2

    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

    Add a comment
    10|10000 characters needed characters exceeded

    Comment on This Answer
  • author's profile photo HRIS Support - Compte France
    HRIS Support - Compte France
    Posted on Jul 12, 2013 at 07:30 AM
    0

    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,

    Add a comment
    10|10000 characters needed characters exceeded

    Comment on This Answer
  • author's profile photo Former Member
    Former Member
    Posted on Sep 28, 2015 at 09:15 PM
    0

    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
    10|10000 characters needed characters exceeded

    • Former Member Former Member
      Aug 23, 2016 at 08:13 PM

      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.

    Comment on This Answer

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.