Any real reason for logical partitioning over physical?

Question

Hi!
I have seen a number of scenarios where SAP BI (assuming BI 7.0 for the rest of the discussion), running in high volume scenarios, have been cluttered by a lot of logically partitioned cubes joined by multi providers....
Obviously the disadvantage of using logical partitions is that it increases maintenance efforts: you need a new update rule for each logical partition (cube) , then you need to manually add/delte cubes from the multiprovider, filtering data in the update rules to reach the correct cube based on time characteristic etc etc...
I have seen one clear advantage which is the parallelization of queries run against a multiprovider - assuming you wan't to all underlying cubes ... but are there any other advantages which overcome the mainenance overhead?
For me it feels like using physical database partitions in the same cube would be the correct decision in 90% of the cases. It seems to me that the underlying RDBMS should be able to handle itself to:
1) Parallellize a query over several physical partitions if needed.
2) Be smart enough to only query the needed partition if the query is restricted based on the partitioning characteristic.
Please correct me anyone? - When is logical partitions really motivated?
Best regards,
Christian
Edited by: Christian on May 15, 2008 3:55 PM

Answer 1

Hi,
This is a great question. Generally it is very difficult to understand the real motivation for the physical partioning - multiple cubes. You are right, it definitely increases the maintenance overhead. And you have already pointed out both the advantages and disadvantages.
Physical Partitioning is more useful where we have huge amounts of data. Imagine a cube with 3 or 4 GB of data - which are not usual - but possible.  The Table Partioning is useful with small infocubes, less than 1 GB. With bigger Infocubes, Table level partitioning may not provide the required level of performance. If we have too many small partitions, that would also reduce the perfomance. If we have too few  partitions, the query performance will not be as much as we want. In this scenario, we can use Physical partitioning (Multiple Cubes) combined with Table Level Partitioning to achieve the required performance levels. On top, we can even think of using Aggregates for further betterment of the performance.
While all the above seems to be relevant for older versions of BW (upto 3.5), BI 7.0 has the BIA (BI Accelerator), which works on the Blade Server with all the data cached directly on the main memory. I am not sure how much this would impact the data modeling - I have not started working on the BIA as yet.
rgds
naga