HANA-Partitionierung: Performance richtig steuern

Herr Sander, Partitionierung klingt für viele zunächst nach einem sehr technischen Spezialthema. Warum ist sie aus Ihrer Sicht trotzdem ein zentrales Thema für den stabilen und performanten Betrieb von SAP-HANA-Systemen?

Matthias Sander: Partitionierung hat direkten Einfluss auf Performance, Parallelisierung und Skalierbarkeit und ist deshalb weit mehr als ein rein technisches Spezialthema. In den meisten produktiven SAP-Systemen sind große Tabellen heute der Normalfall und nicht die Ausnahme. Ohne ein geeignetes Partitionierungsdesign kann es schnell zu unnötigen Vollzugriffen, Hotspots und einer eingeschränkten Parallelverarbeitung kommen. Das wirkt sich unmittelbar auf die Stabilität und Leistungsfähigkeit des Systems aus. Deshalb ist Partitionierung ein fester Bestandteil eines stabilen System-Designs. In der Praxis wird die Bedeutung dieses Themas häufig erst dann richtig sichtbar, wenn Systeme wachsen, Datenmengen stark zunehmen oder Lastspitzen auftreten. Gerade dann zeigt sich, ob ein System sauber auf Skalierbarkeit und performante Verarbeitung ausgelegt ist.

In welchen Situationen merken Unternehmen typischerweise, dass sie sich mit HANA-Partitionierung beschäftigen sollten — eher bei Performance-Problemen, beim Systemwachstum oder erst im Rahmen von Migrationen?

In der Praxis findet das Thema meistens erst bei Performance-Problemen Aufmerksamkeit. Wenn die Reports langsamer werden, sich die Batch-Fenster verlängern oder Lastspitzen zu Engpässen führen. Eigentlich beginnen die Probleme aber oft früher durch kontinuierliches Tabellenwachstum. Die Migrationen auf SAP HANA oder generell Plattformwechsel machen das Ganze dann sichtbar, sind aber eher selten der eigentliche Auslöser. Am besten berücksichtigen Unternehmen Partitionierung bereits beim Wachstum großer Tabellen – und nicht erst unter Zeitdruck.

Sie begleiten seit vielen Jahren reale SAP-HANA-Systemlandschaften. Welche Missverständnisse rund um Partitionierung begegnen Ihnen in der Praxis besonders häufig?

Ich höre oft: ‚SAP HANA regelt das automatisch‘, ‚Partitionierung verbessert immer die Performance‘, ‚Das Thema betrifft nur sehr große Systeme“ oder „Cloud-Betrieb nimmt uns diese Entscheidung ab“. Häufig wird nur auf Tabellengröße geschaut, aber nicht auf Zugriffsmuster, Datenverteilung und zukünftiges Wachstum.

Gibt es typische Tabellen oder Szenarien, bei denen Partitionierung besonders schnell spürbare Effekte bringt? Woran erkennt man solche „Quick Wins“?

Ja, Partitionierung kann besonders bei bestimmten Tabellen und Szenarien sehr schnell spürbare Effekte bringen. Typische Beispiele sind technische Tabellen wie EDID4 oder CDPOS, aber auch Bewegungsdaten, BW-nahe Tabellen oder generell Tabellen, die stark wachsen. Quick Wins zeigen sich meist dort, wo einzelne Tabellen bereits deutlich auffallen: etwa durch wiederkehrend langsame Reports, verlängerte Delta-Merge-Laufzeiten, hohe Last auf bestimmten Tabellen oder dadurch, dass sich Tabellen technischen Limits nähern. Das sind typische Hinweise darauf, dass eine Partitionierung kurzfristig Entlastung bringen kann. Die Effekte entstehen vor allem durch eine bessere Parallelisierung, gezieltes Partition Pruning und kürzere Delta-Merge-Laufzeiten. Dadurch müssen nicht immer große Datenmengen verarbeitet werden, sondern das System kann gezielter auf relevante Bereiche zugreifen. Gerade bei stark wachsenden oder häufig belasteten Tabellen kann Partitionierung deshalb ein sehr wirksamer erster Optimierungsschritt sein.

Partitionierung kann helfen, sie kann aber vermutlich auch falsch eingesetzt werden. Was macht ein schlechtes Partitionierungs-Design aus — und welche Folgen kann es im Betrieb haben?

Ein schlechtes Partitionierungs-Design entsteht häufig dann, wenn die Partitionierung nicht zum tatsächlichen Zugriffsmuster passt. Typische Fehler sind eine falsch gewählte Partitionierungsspalte, eine reine Orientierung an der Datenmenge oder eine ungeeignete Anzahl und Struktur der Partitionen. Im Betrieb kann das spürbare Folgen haben: Es entstehen Hotspots, Datenzugriffe bleiben unnötig breit, Partition Pruning greift nicht wie gewünscht und die Parallelisierung fällt schlechter aus. Außerdem kann der Betriebsaufwand steigen, etwa bei Reorganisationen. Deshalb sollte Partitionierung nicht nur technisch möglich sein, sondern auch zur Nutzung der Tabelle passen.

Welche Rolle spielt das Zusammenspiel von Datenvolumen, Abfrageverhalten und Systemarchitektur bei der Entscheidung für eine Partitionierungsstrategie?

Das Datenvolumen zeigt, wann Partitionierung technisch notwendig wird. Das Abfrageverhalten entscheidet dann, ob eine HASH-, RANGE- oder Multi-Level-Strategie sinnvoll ist. Die Systemarchitektur beeinflusst schließlich, wie die Last verteilt werden kann. Eine gute Partitionierungsstrategie entsteht immer im Zusammenspiel aller drei Faktoren.

Viele SAP-Landschaften wandern in Betriebsmodelle wie RISE with SAP, SAP SAP Enterprise Cloud Services (ECS) oder Private Cloud. Wird Partitionierung dadurch einfacher — oder verschiebt sich nur die Verantwortung?

In Cloud- oder ECS-Modellen wird häufig per Service-Request umgesetzt. Über die Architektur entscheidet aber der Kunde. Er muss dann auch Fragen beantworten, wie welche Tabelle, welche Methode, welche Spalte, wie viele Partitionen. Zumeist verschiebt sich nur die operative Ausführung, weshalb beim Kunden dennoch Know-how vorhanden sein muss.

Wenn Änderungen in Cloud- oder ECS-Umgebungen häufig über Service-Requests laufen: Warum sollten Kundinnen und Kunden trotzdem selbst ein Grundverständnis für Partitionierung und Designentscheidungen haben?

Der Kunde kennt Anwendung, Wachstum, Lastprofil und Geschäftsprozesse. Fehlt ihm das Grundverständnis für Partitionierung und Design-Entscheidungen, wächst das Risiko für falsche Anforderungen, unnötige Iterationen und suboptimale Designs. Deshalb bleibt internes Know-how auch im Cloud-Betrieb entscheidend!

Gibt es aus Ihrer Projekterfahrung eine Anekdote oder ein Beispiel, bei dem eine vergleichsweise kleine Partitionierungsanpassung eine große Wirkung hatte?

Da gibt es viele Beispiele aus produktiven Systemen. Im Gedächtnis geblieben ist mir z. B. ein Fall wiederkehrender Performance-Probleme, wo die Ursache zunächst in der Hardware oder im SQL gesucht wurde. Am Ende war die Ursache aber eine ungeeignete Partitionierungsstrategie einzelner großer Tabellen, die miteinander per SQL gejoined wurden. Mithilfe einer gezielten Repartitionierung konnten eine bessere Parallelisierung und stabilere Laufzeiten erreicht werden. Ein Hardware-Upgrade war gar nicht nötig. In einem anderen Fall hatte ein Kunde zu viele Partitionen angelegt und das Partition Pruning konnte aufgrund eines falschen Designs nicht greifen, was zu einer deutlich erhöhten CPU-Last geführt hat.

Wenn Sie SAP-Basis-Administrator:innen, HANA-DBAs oder Systemarchitekt:innen einen einzigen Rat zum Thema HANA-Partitionierung mitgeben könnten: Welcher wäre das?

Verstehen Sie zuerst, wie auf Ihre Daten zugegriffen wird. Und entscheiden Sie erst danach über die Partitionierungsstrategie.

Vielen Dank für das Gespräch!