If the number of records per partition in first-level range partitioned tables in DataStore objects (advanced) (aDSOs) becomes too high, you can now use a dedicated ABAP report to manually configure the second-level hash partitioning for these tables. This lets you distribute the records across existing partitions more evenly, leading to a more efficient data partitioning.
The number of hash partitions in first-level hash partitioned tables can be adjusted with the SAP HANA landscape redistribution, however, this mechanism doesn't support first-level range partitioned tables. Therefore, a new ABAP report RSO_DTO_ADAPT_2LEVEL_HASH_PART is shipped. It lets you manually adjust the number of hash partitions for already first-level range partitioned ADSO tables, helping you to prevent a partition overflow from occurring due to the 2 billion record limit per partition.
You can configure a limit of records for all partitions of one or several ADSOs using one of the following options:
- Current maximum number of records: This gets the current maximum record count by comparing all tables and partitions, and calculates the new number of hash buckets based on this value.
- Expected number of records: You set a custom value for the number of records, e. g. two billion records:
Note
Use Current Maximum Number of Records if you aren't sure how many records your tables even contain or if you only have vague information on why a partition overflow occurred.
You can run a simulation mode and check the SQL statement that will be applied before actually running the database statement.
For more information, refer to: