cancel
Showing results for 
Search instead for 
Did you mean: 

BW on HANA - Value of HASH 1 partition on ODS

patrickbachmann
Active Contributor
0 Kudos

Hi folks,

I've been doing enterprise HANA on single node for past 3 years (prior to that a traditional BW developer for 10 years) and now recently our BW system was converted to BW on HANA and I'm starting to look into helping some of the BW guys performance tuning particularly with partitioning on the HANA modeling side of the BW system.  I've discovered that all of the ODS tables I'm looking at thus far are HASH 1 partitioned.  Our BW system is multi node so I'm wondering if that has anything to do with this whatsoever.  To me a HASH 1 partition is like not having a partition at all but rather like a single table with no partitions; wouldn't that be the same?  I'm sure it's something I'm just not familiar with yet and it's setup this way for a good reason (I hope!).

Thanks for any insight you may have on this.

-Patrick

Accepted Solutions (1)

Accepted Solutions (1)

lucas_oliveira
Advisor
Advisor
0 Kudos

Hello Patrick,

Chances are that the landscape redistribution was not performed for this system or these DSOs are just too small to be considered for repartitioning/redistribution.

This redistribution process is either triggered during migration, manually at scheduled maintenance window or even automatized with SAP DDO now.

It is not recommended to change the partition specification manually (e.g. from a SQL Editor run 'alter table ...'). The redistribution process will take into account so many different variables that would be really unpleasant  for you to handle on your own.

There are quite a few discussions and blog posts here in SDN. Some of them will point into the recent FAQ about distribution which I find a great start (parallel to the Administration Guide):

2143736 - FAQ: SAP HANA Table Distribution for BW


More details on the landscape redistribution process can be found on the notes below:


1908075 - BW on SAP HANA: Table placement and landscape redistribution

1908073 - BW on SAP HANA: Table distribution and table partitioning

1958216 - HANA landscape redistribution configuration

Super-mega-advice on DSOs that will grow considerably and/or fast: use BW SPO feature before anything. It will save you from loads of headache in the future. I've seen some disturbing scenarios in that regard.  That advice counts for anything that can go SPO in fact. More details on that topic in SAP Note 2019973 - 'BW on HANA - Handling BIG data tables'.

Finally, if you want to check the history of changes on a redistribution process, query HANA_LandscapeReorg_Details from SAP Note 1969700 can help.

BRs,

Lucas de Oliveira

patrickbachmann
Active Contributor
0 Kudos

Hi Lucas,

Thanks for the wealth of information!  Based on some of the record counts outlined in some of this documentation I was able to discover an ODS with HASH1 partition in our development environment was actually a HASH9 in production so that mystery is solved for me.  The only other thing I'm curious about is for these very small ODS (ie: I've seen some with almost zero records) they are still HASH1 partition.  So my question is HASH1 partition the equivalent to no partition at all?  ie: I consider a table with no partition to only have a single part in the parts/partition tab of table definition.  Similarly HASH1 partition I see only a single part in the parts/partition tab of the table definition.  So I'm wondering what's the point, or perhaps that's just the default behavior for BW ODS. 

Thanks,

-Patrick

lucas_oliveira
Advisor
Advisor
0 Kudos

Hi Patrick,

As far as I could test locally, yes this would be the standard behavior for standard DSOs.

I understand that behavior can be changed by following steps of Note 2069235. However, so far that's a Pilot Note. So if you want to apply the changes contained in the Note, open an SAP support incident (component HAN-DB-ENG-BW) so that they can check your scenario.

In short, having HASH 1 <key> from start is perfectly fine for standard DSOs unless you expect large amounts of data in the short term. Then, before considering the Note, I'd still emphasize the usage of SPOs. Seriously, this can save you from major headache with a little more modeling/admin time.

Finally and just for the record: please make sure your DSOs are not IMO anymore (see 1849498).

BRs,

Lucas de Oliveira

patrickbachmann
Active Contributor
0 Kudos

Thanks for all your help!

-Patrick

Answers (0)