HANA News Blog

Dynamic Range Partitioning - Threshold Option

Jens Gleichmann • 23. Dezember 2024

Dynamic range partitioning

With RANGE partitioning (like mentioned in the blog series), the data is divided into individual sections based on one or more characteristics. This allows you to determine exactly which data should be written to a partition. The most common use cases here are partitioning based on time or number values. In order to be able to determine the optimal size and, above all, the characteristics, in-depth application knowledge is required. Collaboration with the relevant specialist department is usually essential.

If partitioning is set up according to RANGE, regular maintenance must take place (e.g. definition of new partitions for the coming year for time-based areas, deletion of old partitions after archiving).

The big advantage is the flexibility and scalability with RANGE. Even if one range is not fitting your requirement any more you can just repartition the affected partitions. There is no need to repartition all data of the table. Only the required data / partitions will be touched. But this applies only for the standard (offline) option. The online option will always redistribute all the data.


Design

Range partitionings should always include an additional partition called OTHERS. This partition has no range definition and is the landing zone for records which cannot be assigned to a defined range partition. If a lot of records are saved into an OTHERS partition you should create a range for this data records or check what is going wrong. This means also proper monitoring is an important task when using partitioning.


When you create an OTHERS partition there is a risk that over time it could overflow and require further maintenance. Using the dynamic range feature the others partition is monitored by a background job and will be automatically split into an additional range partition when it reaches a predefined size threshold. 


There are automatisms in place which called dynamic range partitioning.

Pitfalls RANGE partitioning

Since RANGE partitioning can be significantly more complex than HASH partitioning, there are also more pitfalls to consider. It may not be distributed evenly like for HASH designs. You are responsible to design it along the rules of partitioning.

You have to analyze the data quality of your partition attribute. If you just use a time attribute because it is the only one means not that it is the only way. If the attribute is not used in your queries you may will end up in a bad performance for this table, because no pruning can be used. 

All additional options regarding dyn. range partitioning have certain limitations and besides benefits also some negativ impacts if you have not analyzed and monitored them well.


Threshold option

Tables with a dynamic others partition are monitored by a configurable background job which checks the current size of the partition in comparison to the defined limit and makes adjustments as required. If the OTHERS partition has exceeded the defined limit then all records in the OTHERS partition at the time the job runs are added to the new partition, the corresponding SQL statement is ADD PARTITION FROM OTHERS.

If you define a dyn. threshold of 50 Mio, a new range will be created with the min. value and the max. of the OTHERS partition.

You have defined ranges from 0 to 400,000. If you insert rows above the value 400,000 for CHANGENR they will be saved to the others partition. If the record count of the OTHERS partition (NOT the value of CHANGENR) will reach 50,000,000 a range will be created with the min value 400,000 and may be an odd number like 500,042 but again to illustrate it simple 500,000. A new empty OTHERS partition will be created for new entries without valid range as safe harbor.

It still can happen that a range can run full due to heavy usage of a certain number. This means multiple records of a CHANGENR. In this case, you still need to repartition your table and can adjust the threshold to a lower value.


Usage

This means this option can be useful if you are not aware of the min. / max. values of a partition and the only indicator is the records length and thus the partition size which leads to a certain number of records per partition.


Syntax

ALTER TABLE T ALTER PARTITION OTHERS DYNAMIC THRESHOLD 300000000;

SAP Documentation


Parameters

Partition parameters [partitioning] section of indexserver.ini :

dynamic_range_default_threshold (Default = 10000000)

dynamic_range_check_time_interval_sec (Default = 900s)


How you can check if threshold option is active?

SELECT TABLE_NAME, DYNAMIC_RANGE_THRESHOLD from TABLE_PARTITIONS


Pitfalls Threshold Option

Using the THRESHOLD property empty partitions are also removed during this process.

The creation of a new partition automatically stops the growing of existing partitions. You have to find out the right number of records for the threshold. This can be 300,000,000 records but this can also only 50,000,000 it depends on the scenario and usage of the table. It can also change over time due to higher workload. A proper monitoring is essentially for using RANGE partitioning. Do you have such a monitoring in place which monitors empty partitions, size of partitions, number of records per partition etc.? No? Let's get in touch to avoid unwanted situations (bad performance, error due to 2 billion records, right partition design, right threshold values etc.).


SAP HANA News by XLC

More time to switch from BSoH to S/4HANA
von Jens Gleichmann 7. Februar 2025
Recently handelsblatt released an article with a new SAP RISE option called SAP ERP, private edition, transition option. This option includes a extended maintenance until the end 2033. This means 3 years more compared to the original on-prem extended maintenance. This statement was confirmed by SAP on request of handelsblatt, but customers receive more details, such as the price, in the first half of the year. This is a quite unusual move of SAP without any official statement on the news page. Just to raise more doubts? Strategy? However a good move against the critics and the ever shorter timeline. Perhaps it is also a consequence of the growing shortage of experts for operating and migrating the large number of systems.
Performance degradation after upgrade to SPS07
von Jens Gleichmann 3. Februar 2025
With SPS06 and even stronger in SPS07 the HEX engine was pushed to be used more often. This results on the one hand side in easy scenario to perfect results with lower memory and CPU consumption ending up in faster response times. But in scenarios with FAE (for all entries) together with FDA (fast data access), it can result in bad performance. After some customers upgraded their first systems to SPS07 I recommended to wait for Rev. 73/74. But some started early with Rev. 71/72 and we had to troubleshoot many statement. If you have similar performance issues after the upgrade to SPS07 feel free to contact us! Our current recommendation is to use Rev. 74 with some workarounds. The performance degradation is extreme in systems like EWM and BW with high analytical workload.
Optimize your SAP HANA with NSE
von Matthias Sander 15. Januar 2025
When it comes to optimizing SAP HANA, the balance between performance and cost efficiency is critical. I am happy to share a success story where we used the Native Storage Extension (NSE) to significantly optimize memory usage while being able to adjust the sizing at the end. The Challenge: Our client was operating on a 4 TB memory SAP HANA system, where increasing data loads were driving up costs and memory usage. They needed a solution to right-size their system without compromising performance or scalability. The client wanted to use less hardware in the future. The Solution: We implemented NSE to offload less frequently accessed data from memory. The activation was customized based on table usage patterns: 6 tables fully transitioned to NSE 1 table partially transitioned (single partition) 1 table transitioned by specific columns
SAP HANA NSE - a technical deepdive with Q&A
von Jens Gleichmann 6. Januar 2025
SAP NSE was introduced with HANA 2.0 SPS04 and based on a similar approach like data aging. Data aging based on a application level approach which has a side effect if you are using a lot of Z-coding. You have to use special BADI's to access the correct data. This means you have to adapt your coding if you are using it for Z-tables or using not SAP standard functions for accessing the data in your Z-coding. In this blog we will talk about the technical aspects in more detail.
The SAP Enterprise Cloud Services Private Cloud Customer Center (PC3) - a new digital delivery
von Jens Gleichmann 5. Januar 2025
The SAP Enterprise Cloud Services Private Cloud Customer Center (PC3) - a new digital delivery engagement model dedicated to manage service delivery for RISE with SAP S/4HANA Cloud, private edition customers.
Proactive maintenance for SAP RISE will start now in 2025
von Jens Gleichmann 5. Januar 2025
Proactive maintenance for SAP RISE will start now in 2025 with minor tasks like updating SPAM/SAINT and ST-PI / ST-A/PI. For those companies which are familiar with frequent maintenance windows, they are good to have such time frames to hold the systems up-to-date and secure. However, for larger companies where such frequent maintenance windows are not common because every minute of downtime is costly and may only really be necessary once, the situation is quite different.
Dynamic Aging for NSE - combined with Threshold and Interval option
von Jens Gleichmann 28. Dezember 2024
Dynamic Aging makes it possible to automatically manage at which point in time older partitions can be moved to the 'warm' data store. The data in a new OTHERS partition is 'hot' data, that is, stored in memory with the load-unit attribute implicitly set to COLUMN LOADABLE. As an extension of the Dynamic Range Partitioning feature Dynamic Aging makes it possible to automatically manage when older partitions can be moved to the 'warm' data store (Native Storage Extension) with the load-unit attribute for the partition set to PAGE LOADABLE. Warm data is then stored on disk and only loaded to memory when required. Dynamic Aging can be used with both THRESHOLD mode (defining a maximum row count number in partition OTHERS) and INTERVAL mode (defining a maximum time or other numeric interval between each new partition). For example, for a partitioned table which is managed by dynamic partitioning and containing date/time information, you can specify an age limit (for example six months) so that when data in an ol
automatic maintenance of the 'others' partition
von Jens Gleichmann 28. Dezember 2024
You can create partitions with a dynamic others partition by including the DYNAMIC keyword in the command when you create the partition, this can be used with either a THRESHOLD value to define a maximum row count number or an INTERVAL value which can be used to define a maximum time or other numeric 'distance' value. The partition can be either a single level or a second level RANGE partition and dynamic ranges can be used with both balanced and heterogeneous partitioning scenarios.
A success story regarding BW/4HANA and different data tiering and optimization methodes.
von Jens Gleichmann 20. Dezember 2024
A success story regarding BW/4HANA and different data tiering and optimization methodes. 1) Removed overhead in key attributes which reduced the PK size (often more than 50% of the overall table size) 2) optimized the partitioning design 3) used NSE for write optimized ADSOs 4) introduced NSE for several ADSOs 5) optimized usage of inverted individual indexes
ACDOCA table growth - how to handle it
von Jens Gleichmann 10. Dezember 2024
ACDOCA table growth - how to handle it in a S/4HANA system
more
Share by: