cancel
Showing results for 
Search instead for 
Did you mean: 

BW on HANA. Bad design. Partitioning on in-mem InfoCubes

Former Member
0 Kudos

Partitioning of SAP HANA Optimized InfoCubes -  strange approach from SAP BW developers.

No longer required or allowed (i.e. using a time characteristic to split the data into disjoint partitions)

•Four partitions are automatically created behind the scenes

   •Partition 1 – non-compressed requests

   •Partition 2 – compressed requests

   •Partition 3 – reference points for inventory data

            - Created regardless of inventory/non-cumulative key figures present

   •Partition 4 – historic movements of inventory data

            - Created regardless of inventory/non-cumulative key figures present

So we get only 2(!) partitioning - one for non-comp, second- for compressed requests.

That not enough. Why SAP do this...

Why we can't using physical partitioning pluses ?  it's not logical. We must store billions of records in one partition ?

Is there any news that SAP change this strange situation with partitioning ?

Accepted Solutions (0)

Answers (4)

Answers (4)

Former Member
0 Kudos
Former Member
0 Kudos

Note 1719282 - SAP POS DM 1.0 Partitioning Information

Manual partitioning))

I am still shore - partitioning - good and useful feature but in BW - very poor with it.

lbreddemann
Active Contributor
0 Kudos

Hi Mikhail,

actually I don't see it as critical as you seem to.

With BW 7.3 you can easily use semantic partitioning for InfoProviders including the in-memory-optimized InfoCube.

By that you can easily overcome the (current) 2 billion row limitation of compressed data.

Another thing is: the benefit of partition pruning is relatively smaller for HANA than for other databases, as all filtered columns are always used as filters (basically a "perfect" star query filter) on column level.

A much bigger advantage could be achieved if the partition scheme would allow for partitions containing data that is not used anymore could stay on disk instead of being loaded to RAM for query execution.

As HANA did not have the feature back when the in-memory optimized cube was designed, this is currently not available.

Again, with semantic partitioning you get this already today, too.

And as it is with most many implementation decisions: they are not 'logical or 'compulsory'.

- Lars

Former Member
0 Kudos

Hi Lars, you are like a child.

I am definally shore thats it will be good if we have ability to choose about phisical partitioning DSO or Cube or not.

About SPO

SPO - delta loading from SPO type of DSO not possible

https://ideaplace.brightidea.com/ct/ct_a_view_idea.bix?c=132CDA79-5610-40B5-BFC6-E7F5DC4CFB1D&idea_i...}

About BW on HANA

Hana told itself - split, tables to big. Safe resources.

Former Member
0 Kudos

Dear Mikhail,

I think that you have already put your idea on the idea place and now you have to wait. Let's see if SAP will implement your proposal in SAP BW powered by HANA. However, if it is important for you that this will be implemented soon I think you should contact your account executive resp. send a developement request to SAP via SMP. This also not guarantee that this will be implemented, but I think this the best way.

Best Regards,
Marcel

Former Member
0 Kudos

Marcel.

Thanks for recomendation, but i think it's not worked.

BW is very old system)

former_member184768
Active Contributor
0 Kudos

Hi Mikhail,

There seems to be a workaround for the SPO Delta. Please refer to the following document on the same.

http://scn.sap.com/docs/DOC-25591

Regarding the physical partitioning of the tables, I am not completely sure if this should be done manually or let HANA handle it internally.

Also there has been a discussion somewhere that partitioning might have negative impact on the performance and it is advisable to keep the entire table content on the single blade itself.

I'd be very keen on understanding this in details from experts like Lars.

Regards,

Ravi

Former Member
0 Kudos

Thanks for link. We evaluate them.

> Regarding the physical partitioning of the tables, I am not completely sure if this should be done manually or let HANA handle it internally.

I am too.  But unfortunatelly there are not so many materialas about HANA internals.

Former Member
0 Kudos