Partitioning rules

Question

Should partitioning be performed at the Cube and RDBMS level? Is this an AND or an OR issue where you can do both or only either one?
What are the things to look out for when partitioning?
What are some of the rules?

Answer 1

First - Partioning concept is related to Performance in BI.
Nor mallally it leads to Data loading Performnce & Query Performnce.
Plz find some of the points below related to Cube Partioning.
F-Fact tables and partitioning :
Similar to PSA tables the partitioning of F-fact tables is done automatically. The key difference is the partitioning key. SAP BI will create a new partition for every new load job which inserts data into the F-fact table of an InfoCube. The so-called request id is included in the InfoCube in the form of the package dimension. Therefore the key in the F-fact table which is used to join to the package dimension is also the partitioning key. In the example under b, 18 load jobs inserted test rows into the PSA table. These rows were loaded into the InfoCube via a Data Transfer Process DTP. Figure 11 shows 4 load requests in the InfoCube and figure 12 shows that there are 4 corresponding table partitions in the F-fact table. But how did we get 4 requests in the F-fact table while there are 18 requests in the PSA Table ? Here are a two things to consider in order to understand how a DTP inserts data into a F-fact table :
1. when a DTP in delta mode will be started immediately after a request was loaded into the PSA table it will create a new partition in the F-fact table to store the data.
This is what happened with the first three requests ( ID 413, 415 and 417 ) which can be seen on figure 11. It also shows that depending on the load pattern there might be partitions of very different size within the same fact table.
2. when <n> requests are loaded into the PSA table before the DTP starts then the
DTP will combine all of them into one request in the F-fact table. This is what happened with the other 15 PSA requests in the PSA table. Each of them had 110K rows. Figure 11 shows the total number of rows under u201CTransferredu201D for request ID 433. In addition to this the DTP will aggregate the data from the PSA requests by its key columns. In the sample the 15 PSA requests which were loaded into the InfoCube via one single DTP had 110K rows each and were identical regarding the customer dimension as well as the time dimension ( only two dimensions in the cube ). Aggregation in this case means that all rows with
the same dimension values will be combined and the u201Ckey figuresu201D will be calculated ( depending on the aggregation type u2013 typically u201Csumu201D ). That‟s why we see 1650000 rows transferred but only 110000 rows inserted into the InfoCube.
E-Fact tables and partitioning :
For E-fact tables a customer has the freedom to define the partitioning strategy based on the time dimension. Either month or fiscal year can be used to specify the partitions. The option can be found under u201CExtrasu201D -> u201CDB Performanceu201D when editing an InfoCube in the Administrator Workbench ( transaction RSA1 ). This can only be done as long as the InfoCube is empty and no data was loaded. NetWeaver 7.x offers a re-partitioning tool which allows to change the partitioning for InfoCubes which contain data.
Table partitioning and delete performance:
The main benefit of range table partitioning in SAP BI is the maintenance of huge tables. Especially when it‟s necessary to delete requests the difference might be factor 10, 100, 1000 or even more depending on the amount of data. With SQLServer2000 you found the appropriate delete statements in a ST05 trace for getting rid of a request. Now u2013 with table partitioning activated u2013 a ST05 trace will include the corresponding alter table / switch commands to delete a partition ( see figure 23 and 24 ). What took minutes or hours before now will be done within seconds. To get rid of a partition it‟s necessary to u201Cswitchu201D it out. This is a pure meta data operation and will convert the partition into a normal table which can be dropped. Afterwards a merge command is required to adapt the partition function. In the current implementation this might take some time which is still much less than deleting all the rows. There is a workaround available to avoid moving data during the merge by switching out the next partition too and switch it back in afterwards. But this is not feasible for SAP. The deletion of a request in a F-fact table will automatically delete the corresponding requests in all aggregates which were built on top of this InfoCube. But this works only as long as the u201Ccompression flagu201D ( described under item 4, ) is turned off. Otherwise all aggregates have to be recalculated or completely rebuilt which has a massive performance impact on the whole system. Therefore it‟s recommended to turn the flag off in case requests are deleted on a regular basis.
Figure
Regards
Ram.