SQL-Performance für SAP Analytics
Stand 2026-09-03
Ein Calculation View, der in der Entwicklung in 120 ms läuft, kann in der Produktion 45 Sekunden brauchen, sobald eine skalare UDF, ein nicht beschnittener Join oder eine schlecht partitionierte Faktentabelle HANA aus seinem spaltenorientierten Fast Path drängt — und die Lösung ist fast nie ein SQL-Rewrite, sondern eine strukturelle Änderung. Dieses Modul lehrt, eine PlanViz-Ausgabe zu lesen, zu isolieren, ob die Verlangsamung an einem Push-down-Fehlschlag, einer Partitionierungs-Diskrepanz, einem verpassten Join-Prune oder veralteten Optimizer-Statistiken liegt, und die Calculation-View- oder Partitionierungsänderung zu verordnen, die das Problem dauerhaft löst. Berater, die das an einem produktiven HANA-System live können — nicht nur einen SQL-String tunen —, sind jene, die Kunden für Performance-Sanierungsarbeit binden, abgerechnet mit 1.200-1.800 €/Tag, weit über dem ursprünglichen Migrationsumfang hinaus.
Was Sie lernen
- Push-down-Fehlschläge in HANA-Calculation-Views mithilfe von PlanViz und M_EXPENSIVE_STATEMENTS diagnostizieren und strukturelle Lösungen verordnen, die Aggregation und Filterung in der spaltenorientierten Engine belassen
- HANA-Tabellenpartitionierungsstrategien (Range, Hash, Range-Hash-Subpartitionierung) entwerfen, die zu BW/4HANA- und Datasphere-Abfragemustern passen, einschließlich Delta-Merge-Tuning für Echtzeit-InfoProvider-Szenarien
- Join-Pruning-Bedingungen — Join-Typ, Eindeutigkeitsbeschränkungen, Kardinalitätsangaben — sowohl in grafischen Calculation Views als auch in Datasphere-Analytic-Models anwenden, um unnötige Dimensions-Joins zur Laufzeit zu eliminieren
- Den kostenbasierten Optimizer von HANA durch disziplinierte Aktualisierung der Spaltenstatistiken pflegen und durch Speicherdruck verursachte Performance-Degradationsmuster von Problemen der Planqualität unterscheiden
Warum SQL-Performance in SAP Analytics anders zählt
SAP-Analytics-Workloads sitzen an einer ungewöhnlichen Schnittstelle: spaltenorientierte In-Memory-Engines, Abstraktionen der semantischen Schicht und gemischter OLTP-/OLAP-Verkehr, der sich über den Tag hinweg verschiebt. Eine Abfrage, die auf einem isolierten Entwicklungs-Tenant in 120 ms läuft, kann 45 Sekunden dauern, wenn SAP HANA unter gleichzeitiger Last von SAC-Dashboards, BW/4HANA-InfoProvidern und Datasphere-Replication-Flows steht, die alle dieselben Tabellen treffen. Der Unterschied liegt selten in der Abfrage selbst — fast immer sind es Push-down-Fehlschläge, fehlendes Partition Pruning oder nicht materialisierte Calculation-View-Ebenen, die eine zeilenweise Auswertung erzwingen.
Dieses Modul lehrt Sie, diese Probleme auf der Ebene der HANA-SQL-Engine zu diagnostizieren und zu beheben — nicht auf der Ebene der Abstraktionen der SAP-Dokumentation.
Voraussetzungen
- Fortgeschrittene praktische Erfahrung in SAP-Analytics-Projekten
- Zuerst die Kernkonzepte wiederholen: C040, C004, C087
Lernergebnisse
- Ein realistisches Szenario durcharbeiten: Die BW/4HANA-Migration eines europäischen Versicherers ging planmäßig live, aber das tägliche S&OP-Dashboard in SAC braucht jetzt 45 Sekunden zur Aktualisierung statt der im UAT versprochenen 5 Sekunden.
- Das Anti-Pattern erkennen und vermeiden: Die falsche Schicht optimieren — Wochen damit verbracht, eine BW-Abfrage in SAP GUI zu optimieren, während der eigentliche Engpass ein skriptbasierter Join drei Ebenen tiefer in einer Calculation View ist.
- Die Kernentscheidung des Moduls anwenden: Wo zuerst nachsehen, wenn eine Abfrage langsam ist — wählen Sie: Zuerst HANA instrumentieren — PlanViz plus M_EXPENSIVE_STATEMENTS —, bevor Sie die BW-Abfrage oder das SAC-Modell anfassen.
- Die Beherrschung mit dem KPI verfolgen: Antwortzeit der Abfrage unter Last (Ziel: die UAT-Baseline unter repräsentativer gleichzeitiger Produktionslast erreichen oder übertreffen; Warnsignal: Die Lösung wird ausschließlich im Leerlauf validiert).
Vollständiges Modul für Mitglieder. Das vollständige Modul ergänzt: den Entscheidungsrahmen · das durchgehende Szenario · die KPI-Scorecard · die Anti-Muster · die Codeblöcke · die Wissenskontrolle · die Schemata.