Konzeptkarte

HANA-Performance-Tuning

Stand 2026-07-23

Redaktion: Cédric-Olivier Mâry, alleiniger Redakteur und verantwortlich für die Veröffentlichung — 27 Jahre im SAP-Ökosystem. Wie diese Seiten entstehen und wo Automatisierung eingesetzt wird.

Was ist HANA-Performance-Tuning?

HANA-Tuning unterscheidet den Architekten, der Query-Pläne liest, vom Junior, der „das Datenvolumen" verantwortlich macht – fünf Stellhebel verwandeln eine 5–50-Sekunden-Abfrage in eine mit 100–500 ms.

Worum es geht

HANA Performance Tuning ist die ingenieurtechnische Disziplin, Abfragen in 100–500 ms statt in 5–50 Sekunden laufen zu lassen. Sie unterscheidet den Senior-Architekten (der Query-Pläne liest, Partitionen entwirft, weiß, wann eine Hierarchie zu flachen ist) vom Junior-Berater (der „das Datenvolumen“ verantwortlich macht). Für SAP-Analytics-Berater im BDC-Zeitalter — in dem Datasphere auf HANA Cloud aufsetzt (Begleitkonzept C001) — ist HANA-Fluency die architektonische Währung, die Modellierungsentscheidungen in Millisekunden umsetzt und Millisekunden in Nutzerakzeptanz.

Die fünf Tuning-Hebel in Prioritätsreihenfolge. (1) Column-Store-Eignung — bestätigen, dass Tabellen spaltenorientiert sind (Standard, aber Legacy-Migrationen behalten manchmal Row-Store bei). 10–100-facher Unterschied in der Scan-Geschwindigkeit. (2) Push-down-Erhalt — Query-Pläne zeigen, ob der HANA-Optimizer Prädikate und Projektionen in die Speicherschicht geschoben hat. Script Views (Begleitkonzept C004) brechen Push-down; als SQL neu schreiben. (3) Partitionsdesign — Faktentabellen nach FISCAL_YEAR partitionieren (2–5 Mio. Zeilen/Partition optimal). Partition Pruning vermeidet das Scannen irrelevanter Daten. (4) Statistiken + Indexierung — Statistiken auf Join-Spalten sammeln; invertierte Indizes auf filterintensiven Spalten anlegen. (5) Materialisierung vs. Föderation — föderiert ein Datasphere View 5+ Quellen, das Join-Ergebnis materialisieren; die Abfragelatenz sinkt um das 5–20-Fache.

Die Query-Plan-Diagnose. Der Plan Visualizer von HANA Studio zeigt den Operatorbaum je Abfrage. Ihn zu lesen erfordert 5–10 Minuten Übung. Zu prüfen sind: Tabellen-Scans (Scan-Größe relativ zur Gesamttabellengröße — > 50 % = Filter nicht heruntergeschoben), Join-Algorithmen (Hash-Join vs. Nested-Loop — Nested-Loop bei > 10K Zeilen = Problem), Ergebniszeilen-Volumen je Operator (oberster Operator = Gesamtergebnis; Zwischenspitzen = schlechte Join-Reihenfolge). Der Senior-Architekt investiert 30–60 Minuten je Diagnose einer langsamen Abfrage und benennt den konkret verantwortlichen Operator.

Warum es zählt

Script Views brechen Push-down still und leise — allein das Umschreiben als SQL kann einen Sprung in der Latenz bewirken, den keine noch so große Hardware-Skalierung beheben würde.
5+ Quellen in einem Datasphere View zu föderieren, ohne das Join-Ergebnis zu materialisieren, kostet das 5- bis 20-Fache an Latenz — eine Entscheidung, die zur Modellierungszeit fällt, kein Laufzeitproblem, das man später flicken kann.
Ein Senior investiert 30–60 Minuten in das Lesen des Operatorbaums im Plan Visualizer je langsamer Abfrage und benennt den exakt verantwortlichen Operator — vage Diagnosen wie „das ist langsam“ überstehen diese Disziplin nicht.

Kernpunkte

Fünf Tuning-Hebel: Column-Store · Push-down · Partition · Statistik/Index · Materialisieren-vs-Föderieren.
Der Plan Visualizer ist das Diagnosewerkzeug; ihn zu lesen erfordert 5–10 Minuten Übung.
Push-down-Erhalt: keine Script Views im AM-Abhängigkeitsbaum.
Partitionsdesign: FISCAL_YEAR + 2–5 Mio. Zeilen/Partition optimal.
Materialisieren ab 5+ föderierten Quellen (5–20-fache Latenzverbesserung).
Calculation Views ≤ 2 Ebenen tief.
Tuning-ROI: 100- bis 1000-fach gegenüber Kapazitätserweiterung.
DAC-Overhead: 3–5 ms/Regel × N gestapelt.
HANA Performance Tuning ist erst gemeistert, wenn es eine konkret benannte Buyer-Entscheidung verändert.
Beginnen Sie mit dem semantischen Vertrag und dem Kontrollmodell, bevor Sie das Tool vorführen.

Begriffe auf dieser Seite

Column-Store: HANAs Standard-Speicherlayout: Spalten separat gespeichert, optimal für analytische Scans. 10–100-fach schneller als Row-Store.
Push-down: Der Optimizer schiebt Prädikate und Projektionen in die Speicherschicht. Script Views brechen das.
Plan Visualizer: Werkzeug in HANA Studio, das den Operatorbaum je Abfrage zeigt. Das primäre Diagnosewerkzeug.
Partition Pruning: Der Optimizer überspringt irrelevante Partitionen beim Scan. Erfordert Partitionsdesign (typischerweise FISCAL_YEAR).
Materialisieren-vs-Föderieren: Kompromiss: die föderierte Multi-Source-Abfrage ist langsamer, aber die Daten sind aktuell; der materialisierte Join ist schneller, aber mit Kopieraufwand.
Cold Cache: Die erste Abfrage des Tages ist langsamer, weil die Daten noch nicht im HANA-RAM liegen. Hot-Modelle nach Zeitplan vorwärmen.
Calculation-View-Verschachtelung: Geschichtete HANA Views, bei denen jede Ebene Optimierungskomplexität hinzufügt. Auf ≤ 2 Ebenen begrenzen, für die Lesbarkeit.
DAC-Overhead: Kosten pro Regel für das Umschreiben der Abfrage: 3–5 ms pro Regel und Abfrage. Gestapelte Regeln summieren sich.

Quellen

Vollständige Karte für Mitglieder. Was die vollständige Karte ergänzt: den vollständigen Entscheidungsrahmen · den Vergleich SAP · Snowflake · Databricks · Fabric · die häufigen Fallstricke und ihre Behebung · die Kurzreferenz · die Architekturschemata · die Codeblöcke.

In der App öffnen →