Semantically Partioned Objects (SPO)

[Former Member]

Hi,

I have been looking to using SPO to "partition" data out in years e,g, 2011, 2012, 2013 etc.

I have some questions I hope someone could answer

- What is the difference between SPO and the "Partitioning" option on an InfoCube (additional functions -> repartitioning)?

- Pre SAP 7.3 I would have created different cubes under the multi-provider for each year. Then used a SAP user exit in the bex query to restrict to relevant infoprovider based on a selection from the user. Is this possible via SPO?

- As I understand there is obviosuly and overhead on SPO and any partitioning. If I have partitoon the data by year for 2011, 2012, 2013, 2014. Then we get to 2015 a new partitoon will need to be created and setup. Correct?

- What happens if I have only created partiton for 2011 - 2014 and we hit 2015 and new partition is not created. I am assuming I should create a catch all partiton?

- My understanding is that if use a number of InfoCubes under a multiprovider when the partitions a queried multiple "queries" are generated for each of the cubes and in turn speeding the reporting process ? Is this still the case using an SPO

Sorry for all the questions but they are all related to what I am looking into.

Thanks,

[Former Member · Accepted solution]

Hi Leo,

SPO is a logical partitioning and partiotning option is done on database level.

SPO is justa simplification of the former modelling where you had to create different cubes or DSO for a yearwise parttioning.

SPO helps you to save time creating all objects with just different selections.

Of course you can stilluse the 'old' modelling technique instead of SPO.

With SPO you do the same modelling as before, you build tghe query on top of a multi having SPO as part provider and restricting your queries with appropriate filters. The filter should match the SPO partitions otherwise the query will be executed using all partitions of the SPO. This can be much slower than to filter e.g. for 2012-2014 and query optimizer knows to execute query only on partitions for 2012 to2014 of SPO. Of course querys are executed in parallel if possible and enough system resoources are available,

The SPO creates two dummy partitons, like the physical partitioning on a database. One partition fpr all years before 2011 and one partition for all years after 2014. So no need for you to define a "catch all" partition, SPO does it itself.

For rolling years you can define a dynamic partition.

Hope SPO got abit clearer.

Regards,

Jürgen

[Former Member · Accepted solution]

Hi,

thanks for your response. A few questions

- When you say partitioning is done at the database level? What do you mean? Does that just improve performance because the data is partitioned at the DB but in this case we cannot force filter data sets as we can with SPO using filters in queries?

- When you say i can create a dynamic partotion? How do you do this? This would also mean re-creating process chains etc?

Cheers,

[Former Member · Accepted solution]

Hi Leo,

- When you say partitioning is done at the database level? What do you mean? Does that just improve performance because the data is partitioned at the DB but in this case we cannot force filter data sets as we can with SPO using filters in queries?

Physical Partitioning is done on database level. The database creates own areas for the data which can be accessed faster. But this is completely independent of SPOs and filters. You can do a comination of logical partitioning with a SPO and physical partition on database to get the most performance.

- When you say i can create a dynamic partotion? How do you do this? This would also mean re-creating process chains etc?

For creating a dynamic SPO see . You need to re-create process chains only if you already use a static SPO and wants to chnage it to a dynamic SPO. Yuu define transforamtions, DTPs and process chain when you create your SPO as further opotions. Please try it yourself on a demo or sandbox system.

Regards,

Jürgen  

[former_member197660]

Hi Leo

Just to add what Juergen mentioned, find the comments:

- What is the difference between SPO and the "Partitioning" option on an InfoCube (additional functions -> repartitioning)?

Ans: SPO's are physically separated entities in database like if you have created SPO for 4 years then there will be 4 infocubes created in database.

Whereas  partitioning of infocube is a logical partitioning of data in fact table base on Calmonth/Fiscal year period.

Advantage of SPO's is you can create partitions based on characteristics and the data flow can be automated too however the partitioning of infocube is based on only Time dimension.

In general they both are completely different entities.

- Pre SAP 7.3 I would have created different cubes under the multi-provider for each year. Then used a SAP user exit in the bex query to restrict to relevant infoprovider based on a selection from the user. Is this possible via SPO?

Ans: Yes, with SPO you can define/create individual cubes for the desired number of years and also identify them technically individually for reporting purpose.

- As I understand there is obviosuly and overhead on SPO and any partitioning. If I have partitoon the data by year for 2011, 2012, 2013, 2014. Then we get to 2015 a new partitoon will need to be created and setup. Correct?

Ans: Yes, a new partition is required before you expect data for new year to flow in, in general new data will not be loaded in SPO if the new partition is not available due to the restriction of partition value in DTP.

- What happens if I have only created partiton for 2011 - 2014 and we hit 2015 and new partition is not created. I am assuming I should create a catch all partiton?

Ans: As mentioned above you have to create partition before you expect the data however it is no problem as the new data will not be loaded to existing partitions due to filters in DTP selections.

- My understanding is that if use a number of InfoCubes under a multiprovider when the partitions a queried multiple "queries" are generated for each of the cubes and in turn speeding the reporting process ? Is this still the case using an SPO

Ans: In general yes the query will try to find the data from relevant cube based on partitions thus expediting the reporting. However performance of query depends on several factors thus it depends on the data and query setup too.

Hope it helps !!

Regards

Ashish