Can anyone tell me if it is still wise and usefull to partition a Cube when using the BIA too? Does the BIA read the Cube data different (faster) if the Cube is partitioned or is using BIA enough and has partitioning no influence of performance.
hope anyone can help me with this !
I assume we are talking about using the DB range partitioning feature to partition the E fact table on either 0FISCPER or 0CALMONTH. If that's the case, I have to agree with Srikanth for the reasons outlined.
I haven't upgraded to BI 7.0 with BIA yet, but it sound like Sascha is talking about some sort of partitions on the BIA.
Couple of other advantages of partitioing the E fact table, depending on criteria used, having the E fact table partitioned could help with performance on Selective Deletion and Archiving runs.
Hi Steven, I agree with Srinkath. It is wise to have a partitioning strategy for the InfoCube in place, even If you use BIA.
One additional aspect is the maintainability of the Database. I believe it is much more easy to administrate and reorganize the Database, if the InfoCube is partitioned.
I hope this help, Michael
Yes, I say its wise to use partitioning on cubes, irrepective of whether it is on BIA or not. This has the following advantages.
1. Parellel initial fill of BIA is only possible if partitions on E table exist. Otherwise, it will be one job for entire E table to fill the indexes on BIA.
2. There might a chance where Blades go down sometimes or incase you wish to upgrade the BIA hardware. We can ensure business continuity inspite of BIA non availability. (Minimize runtime to certain extent in case BIA doesnot function).
3. There will not be any change from read performance perspective. Because the Fact data is maintained as a single object in BIA.
So better we always have the same partitioning strategy as earlier.
Hope this helps.