Question:
Hi all,
in a few recent papers on BW scaleabilty SAP is saying that one element of it is to split up info cubes e.g. into plan/actual or yearly infocubes.
I've got a SEM-PA InfoCube that contains 16 million records per year. I wonder whether there is a rule of thumb that tells you when to split a big infocube into several yearly ones with a multicube on top
Further question that arises: If you have several annual cubes and you are using delta update, how then do you assign the records to "their" cube. What I can think of is having an ODS filled with delta and from their full-updating the yearly cubes with year/period as selection criteria of the info packages.
Any suggestion is appreciated.
Thanks a lot.
MG.
Answer:
I would suggest splitting when performance becomes an issue, or be pro-active if you expect millions of rows.
As for updating you can have all the cubes as data targets for the one infosource. Then in each cubes update rules you decide if that record is to be loaded to that cube (based on year in your case).
Answer:
Did you participate in the recent Knowhow network topic on Scalability by Ron Silberstein? You can find the transcript and presentation on service.sap.com
I thought your title referred to the scalability of the infrastructure.
_________________
Keep smiling
Answer:
Hi,
The Silberstein paper is one of those that are mentioning the splitting up of info cubes along the time dimension.
Now, what I am looking for is a thumb rule (based on no. of records) when to split a big cube into smaller yearly cubes. That would allow to make this design decision BEFORE actually running into the performance issue and then trying to cope with it.
Thanks.
MG
Answer:
Hello MG,
If you have Early Watch set up (it's a free service), you would get regular reports (pro-active) and know how the system is performing and know pro-active when to take action. Ask your basis to set up Early watch. You can see your reports in OSS or SAPNet.
_________________
Keep smiling