Andreu,
Here is my input...
- Which is the maximum number of records an InfoCube can have?
I do not think BW has any restrictions as to how many records an Infocube can have.
- At what amount of records is recommended to split InfoCubes? (Millions, tens of millions, hundreds of millions)
With the increasing size of fact table, performance goes down. So, obviously if the number reaches 100 million, query performance will take a hit. Generally, for better performance, it would be a good design to see that cube size doesn't go beyond 20-25 million and if does, consider splitting into two.
- Which is the better option for splitting InfoCubes? On time basis, Company ...
In most of the cases, this is done on timely basis, like Cube for 2003, Cube for 2004, Cube for 2005 etc and then a multiprovider on top of these. Because most of the report requiremnts will need to see data in 1 year at a time and maintenance and archiving will be easier, as you'll be dealing with only the current year cube. But there could be other affecting factors also, depends on individual situation...
- A part from Aggregation, which are the main issues to consider for performance?
COMPRESSION will reduce the number of records and also removes the table partitions (based on requeast ID), which improves performance.
Maintain Indexes and DB stats.
Efficient query design. Do not place a lot of chars in 'rows'. Place them in 'Free Chars' instead. Users will expand if needed. Use restrictions in the 'filter' whenever possible.
restrict the use of 'NAV' attributes, if possible.
If there is any code for 'user exit vaiables' or virtual infoobjects, try to eliminate the SELECT statements or reduce the DB access if not avoidable.
Hope it helps
Gova
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.