Ihre HANA DB wächst stetig und stößt bei manchen Tabellen an Grenzen bei denen eine Partitionierung unausweichlich ist. Es gibt aber weitere Gründe wie Steigerung der Performance oder NSE (Native Storage Extension - HANA Data Tiering) bei denen Partitionen einzusetzen Sinn macht.
Das Design der SAP erlaubt der HANA DB lediglich 2 Milliarden Einträge pro Partition / Tabelle (Column Store). Bei größeren Tabellen ab 20GB kann es aber bereits vorher Sinn machen zu partitionieren. Der Delta Merge benötigt mehr Zeit bei großen Tabellen/Partitionen und hält dadurch Sperren länger als nötig.
Wer ein älteres System auf HANA betreibt hat evtl. frühere ineffiziente Partitionierungsdesigns aktiv. Es wurde damals nach dem Primärschlüssel partitioniert. Dies hat negative Effekte auf die Performance.
Sie haben kundeneigene Tabellen und noch kein passendes Design? Gerne helfen wir mit einer Analyse weiter, das optimale Attribut dafür zu finden.
Wir unterstützen Sie bei den Wartungen und verkürzen durch unser optimiertes Vorgehen die Laufzeit der Partitionierung.
Es ist jeder Zeitpunkt möglich. Jedoch je früher destro besser. Unabhängig davon, ob das HANA System migriert wird oder eine Conversion bevor steht. Ebenso sollte das System bereits auf HANA laufen gibt es zu jeder Zeit die Möglichkeit einer Analyse basierend auf Größe und Wachstum der Tabellen, aber auch im Kontext Performance.
Eine Analyse der Designs sollte stetig (min. 1 pro Jahr) durchgeführt werden. Wir bieten dies auch im Kontext unserer HANA Health Checks mit an.
Wir führen zusammen mit Ihnen die Analyse durch und berücksichtigen das Wachstum und die Parametrisierung des Systems. Die Durchführung der Wartung können Sie anschließend selbst durchführen.
Bei korrektem Design mit Rücksicht auf Ihre Anwendungen und User (SQL Anweisungen) kann ein Partitioning Pruning erfolgen. Es werden also komplette Partitionen aus der Selektion entfernt.
Der Delta Merge wird beschleunigt, da es zu jeder Partition ein eigenes Main und Delta gibt. Dadurch wird der Merge-Vorgang beschleunigt als auch der darauf folgende Optimize Compression Lauf.
Inserts können lediglich eine CPU pro Spalte und Partition verwenden. Der Einsatz von mehreren Partitionen kann sich positiv auf die Performance derartiger SQLs auswirken.
Nein, NSE (Native Storage Extension) kann auch ohne Partitionierung eingesetzt werden. Meist wird es aber kombiniert mit zeitlichen Attributen. Dadurch kann man diese Zeitscheiben perfekt trennen und in den den warm Store verdrängen.
HANA Alerts / Alarmierungen:
ID: 17
Record count of non-partitioned column-store tables Determines the number of records in non-partitioned column-store tables. Current table size is not critical. Partitioning need only be considered if tables are expected to grow rapidly (a non-partitioned table cannot contain more than 2.147.483.648 (2 billion) rows).
ID: 20
Table growth of non-partitioned column-store tables Determines the growth rate of non-partitioned column-store tables.
ID: 27
Record count of column-store table partitions Determines the number of records in the partitions of column-store tables. A table partition cannot contain more than 2.147.483.648 (2 billion) rows.
Sollten Sie eine dieser Meldungen erhalten, sollten Sie zeitnah das Datenvolumen reduzieren oder eine Partitionierung durchführen.