In einem BW/4 HANA System nimmt man generell an, dass auch die Query Funktionen in der HANA ausgeführt werden und damit von den Geschwindigkeitsvorteilen der HANA profitieren. Trotzdem kommt es öfter zu langen Laufzeiten von Queries, insbesondere nach Änderungen oder Erweiterungen an den Queries. In diesem Blog soll nach einem kurzen Überblick über mögliche Ursachen eine vorhandene Analysemöglichkeit vorgestellt werden. Aufgrund des Umfangs dieses Themas kann dieser Blog keinen vollständigen Überblick über das Thema geben, sondern nur einen Teilbereich abdecken.
Ausgangsszenarien
Vielen dürfte so etwas bekannt vorkommen: Anfangs lief die Query noch sehr schnell und performant. Aber nach einer gewissen Zeit oder nach einer Erweiterung der Query (um wenige Kennzahlen, Formeln, etc.) schnellen die Antwortzeiten extrem in die Höhe. Nicht nur die Anwender, sondern auch die BW Berater fragen sich erstmal, warum u.U. sogar nur eine Kennzahl ein dermaßen schlechteres Verhalten bei den Antwortzeiten hervorrufen kann. Dabei unterscheidet sich auf den ersten Blick die vorgenommene Erweiterung oder Änderung kaum von den bisherigen Funktionen in der Query, beispielsweise nur durch eine weitere Formel mit einer Ausnahmeaggregation. Die Query hat bei anderen Formeln und Kennzahlen, auch mit Ausnahmeaggregationen, dieses Verhalten nicht gezeigt. Daher stellt sich bei den Beteiligten die Frage, was die Ursachen sein können und wie diese einfach analysiert werden können.
In meinem konkreten Beispiel ging es um eine Query, die um drei Kennzahlen erweitert wurde. Diese drei Kennzahlen basierten auf einem Zähler und zwei Formeln, die aufeinander aufbauten. Dabei wurde auch mit der Ausnahmeaggregation gearbeitet. Wurde nun die letzte Kennzahl in den Aufriss der Query genommen, so ist die Antwortzeit von unter 20 Sekunden auf mehr als 3 Minuten angestiegen.
Faktoren für eine Ausführung in der HANA
Bevor ich weiter auf das konkrete Beispiel eingehe, möchte ich zunächst eine kurze, nicht vollständige Auflistung von Faktoren, die eine Ausführung einer Query bzw. von Query-Bestandsteilen in der HANA verhindern und den Umweg über den langsamen OLAP erzwingen, darstellen. Faktoren hierfür können auf mehreren Ebenen vorliegen und u.a. sein:
- Stand des Systems: HANA Revision, BW Release bzw. aktueller Patch Level
- Datenmodell und genutzte InfoProvider
- Einstellung in den InfoProvidern und der Query
- Definition von einzelnen Strukturelementen der Query
Ich möchte diese Punkte nachfolgend kurz erläutern und Hinweise auf weiterführende Quellen geben.
Stand des BW-Systems
Der Stand des Systems betrifft dabei die HANA Datenbank selbst, als auch den Release- bzw. Versionsstand des BW/4 HANA Systems. Vor allem bei der Verwendung von Ausnahmeaggregationen in einer Query ist das von Bedeutung. Bei niedrigen Versions- / Releaseständen des BW/4 HANA Systems können noch nicht alle Ausnahmeaggregationen direkt auf der HANA Datenbank ausgeführt werden. Mittlerweile (ab SAP HANA 1.0 SP12 oder höher) können diese aber alle auf der HANA Datenbank ausgeführt werden. Eine Übersicht, welche Ausnahmeaggregationen und welche Formeloperationen beim jeweiligen Versions-/ Releasestand unterstützt werden, findet sich in der SAP Hilfe (zum jeweiligen Stand) unter dem Pfad: Analyse > Analytische Query modellieren > Mit Query arbeiten > Query im Editor definieren > Laufzeiteigenschaften der Query (Registerkarte Runtime Properties) ändern > Laufzeitprofileigenschaften > Operationen in SAP HANA > Ausnahmeaggregation in der SAP HANA.
Für einzelne Ausnahmeaggregationen müssen u.U. bestimmte Voraussetzungen erfüllt sein. Ein Beispiel dafür wäre „erster / letzter Wert“. Der OSS Hinweis 2156123 beschreibt dies näher.
Datenmodell und genutzte InfoProvider
Das Datenmodell, auf dem die Query basiert, und die dort genutzten InfoProvider der Query haben ebenfalls einen Einfluss auf die möglichen Operationen in der HANA. Wird ein Calculation View als Grundlage genutzt, so verhindern dort mögliche NULL Werte ggf. die Ausführung in der HANA. Neben dem Calculation View hängt es auch noch von der Einstellung im CompositeProvider bei den verwendeten Merkmalen ab, je nachdem, ob für das Merkmal der Ausnahmeaggregation die referentielle Integrität bestätigt wurde oder nicht.
Ein Push-Down auf die HANA kann durch die Definition des CompositeProviders selbst verhindert werden, zum Beispiel bei der Existenz sogenannter „Ambiguous Joins“, also wenn Non-Unique Joins definiert wurden (mit Kardinalitäten wie 1:n, n:m) oder aber bei Definitions-Problemen wie dem CMP-Problem.
Ausführliche Erläuterungen zu den genannten Punkten finden sich in einem wunderbaren Beitrag im SAP SCN Wiki mit dem Titel „How to check why exception aggregation is not pushed down to HANA DB“. Hier werden diese Punkte ausführlich besprochen und nebenbei das CMP-Problem bei einem CompositeProvider an einem verständlichen Beispiel erläutert.
Einstellungen in der Query und beim CompositeProvider
In der Query selbst können ebenfalls Einstellungen vorgenommen werden, welche eine Ausführung in der HANA ermöglichen oder verhindern. Dies trifft auch für die entsprechenden Einstellungen im CompositeProvider zu, auf dem die Query basiert. Diese Einstellungen finden sich in den Query-Einstellungen im Tab „Laufzeiteigenschaften“ unter Laufzeitprofileigenschaften im Punkt Operationen in SAP HANA.
Der SAP Standard ermöglicht hier drei Einstellungen: Defensiv (J), Standard (M) und Offensiv (P). Je nach gewähltem Modus (hier in der Query oder im CompositeProvider) führt das System nach einer Prüfung die Operationen in der SAP HANA aus oder nicht. Um Ausnahmeaggregationen auf die HANA drücken zu können ist mindestens die Einstellung „Standard (M)“ erforderlich.
Für den Fall, dass im System die hier genannten Optionen nicht angezeigt werden, sondern andere Werte mit Ziffern – bspw. „Expert: Ausnahmeaggregation (6)“, dann wurde das System schon über einen RSADMIN Parameter auf diesen Expertenmodus umgestellt. Der OSS-Hinweis 2505732 und die Erläuterungen in der SAP Hilfe „Operationen in SAP HANA unter Laufzeitprofileigenschaften“ gehen detaillierter auf diesen Modus ein.
Mit diesem Parameter kann letztlich eine feinere Steuerung der Ausführungen von OLAP Berechnungen auf der HANA erreicht werden. Für Ausnahmeaggregationen ist mindestens der „Level 7 (In der SAP HANA berechnete Formeln)“ bzw. „M (Standard)“ erforderlich.
Definition von einzelnen Strukturelementen der Query
Auch einzelne Strukturelemente können einen Push-Down auf die HANA verhindern. Dazu zählen u.a. die Ausnahmeaggregation auf Kennzahlen wie Bestandskennzahlen, Kennzahlen mit Binnenumsatzeliminierung sowie Währungs- und Mengenumrechnungen bei einer Kennzahl, wenn die Umrechnung ein InfoObjekt zur Ermittlung der Zielwährung/-einheit nutzt. Auch die Art der Formel kann verhindern, dass die Berechnung auf die HANA gedrückt werden kann. So werden kommutative Formeln mit Berechnung vor der Aggregation in der HANA berechnet, ebenso wenn das Formelergebnis keine Währung oder Einheit beinhaltet bzw. nur von einem Operanden die Währung oder Einheit übernimmt. Die Details werden in der SAP Hilfe unter diesem Pfad aufgeführt: Analyse à Analytische Query modellieren à Query im Editor definieren à Laufzeiteigenschaften der Query à Laufzeitprofileigenschaften à Operationen in SAP HANA à Ausnahmeaggregation in der SAP HANA.
Des Weiteren kann die Ausführung bei einer Ausnahmeaggregation nicht auf die HANA gedrückt werden, wenn virtuelle Merkmale vorliegen oder das künstliche Merkmal 1CUDIM im CompositeProvider enthalten ist. Weitere nicht unterstütze Funktionen bzw. unterstützte Funktionen in einer Query werden ebenfalls wieder in der SAP Hilfe unter dem Punkt Ausnahmeaggregationen in der SAP HANA zum jeweiligen Releasestand aufgeführt.
Analyse
Nicht immer ist die Ursache bei der Analyse so ersichtlich wie im Fall einer kurz zuvor vorgenommen Änderung. Ist der Auslöser nicht bekannt bleibt nur die klassische Analyse. Hier kann man pragmatisch vorgehen und die Query Stück für Stück auf- oder abbauen, bis die Ursache vorliegt bzw. nicht mehr vorliegt. Oder man geht etwas systematischer vor und nimmt die Analysen auf den verschiedenen Ebenen vor. Im vorliegenden Fall konnte gezeigt werden, dass die Laufzeiten im Datenmodell akzeptabel waren. So lief eine Anfrage im CalculationView nicht signifikant länger, wenn die betreffenden Merkmale / Kennzahlen in die Datenabfrage aufgenommen wurden. Auch die Abfrage der Laufzeiten der Query über die bekannte Laufzeitanalyse der Query (mit der Transaktion RSRT à Ausführen und Debuggen à Allgemeine Ausführungsmöglichkeiten à Statistikdaten anzeigen) zeigt, dass die Laufzeiten im Event-ID 3200 OLAP-Datentransfer anfallen. Unter dieser Event-ID werden u.a. Formelberechnungen und Ausnahmeaggregationen zusammengefasst. Eine Übersicht über die Event-IDs findet sich in der SAP Hilfe zum BW/4HANA unter dem Pfad Betrieb à Query-Laufzeit-Statistik à Übersicht der Statistik-Events (Tabelle RSDDSTATEVENTS).
In diesem Blog möchte ich mich auf den Teil der Laufzeit konzentrieren, der die Ausführung in der Query betrifft. Bei der Ausführung der Query in der Transaktion RSRT gibt es eine weitere, weniger bekannte Möglichkeit, auf die hier hingewiesen werden soll. Unter dem Button „Ausführen + Debuggen“ gibt es die Option „Ausführen und Erklären“.
Wird diese Option gewählt, so können verschiedene Protokolle ausgewählt werden. In unserem Fall der Analyse der Laufzeiten vermuten wir einen Zusammenhang mit Formeln und Ausnahmeaggregationen und wählen deshalb das Protokoll für „Ausnahmeaggregationen in SAP HANA“ aus.
Damit kann man nun die Query wie gewohnt in der RSRT ausführen.
Dieses Vorgehen ist auch im OSS Hinweis 2400004 – Prüfen des SAP-HANA-Pushdowns von OLAP-Funktionen wie Ausnahmeaggregation ausführlich beschrieben.
Geht man aus dem Ergebnisbild der Query zurück (-> PF3) so erscheint das Protokoll. Hier findet man verschiedene Schritte und Informationen. Das Ergebnisbild variiert je nach Query und Query-Definition.
Hier fallen diese Punkte auf:
- Query/Optimizer Informationen – Allgemeine Anmerkungen zur Query, u.a. Query-Eigenschaften wie Operationen in SAP HANA
- Strukturelemente, deren Formelausnahmeaggregation in SAP HANA durchgeführt werden können
- Strukturelemente, deren Formelausnahmeaggregation NICHT in SAP HANA durchgeführt werden können
Das Protokoll erlaubt also einen Blick darauf, wie die Ausführung einer Query erfolgt und ob alles auf der SAP HANA ausgeführt werden kann oder nicht. Dabei spielen nicht nur einzelne Kennzahlen und Formeln (mit/ohne Ausnahmeaggregationen) eine Rolle, sondern auch Einstellungen an der Query und den beteiligten InfoProvidern sowie die des zugrunde liegenden Datenmodells, wie bereits oben beschrieben.
Unter den Strukturelementen kann man die Kennzahlen und Formeln erkennen, die in der SAP HANA ausgeführt werden können oder nicht. Hier lassen sich die teuren Formeln mit Ausnahmeaggregation erkennen, welche nicht in der SAP HANA ausgeführt werden.
Unter dem Schritt 0 kann es auch zu Hinweisen kommen, dass Ausnahmeaggregationen für diese Query in SAP HANA nicht möglich sind. In meinem Beispiel hat die Query das künstliche Merkmal 1CUDIM in den freien Merkmalen. Dieses Merkmal verhindert die Ausführung in der HANA für die gesamte Query.
Teilweise werden aber auch die entsprechenden OSS-Hinweise angegeben, wie ein Verweis bspw. auf den OSS-Hinweis 2271658.
Mit Hilfe dieses Protokolls erhält man sehr schnell eine Übersicht über allgemeine Gründe (wie Ursachen am Datenmodell durch mögliche NULL-Werte, Einstellungen am CompositeProvider) als auch über detailliertere Gründe, wie wenn zum Beispiel nur eine Formel der Query nicht auf der HANA ausgeführt werden kann.
Fazit
Im Einzelfall ist es nicht einfach zu ermitteln, welche OLAP-Schritte in einer Query in der HANA ausgeführt werden und welche nicht. Auch mit einem ausführlichen Studium der Hilfen und Blogs findet man nicht verlässlich (und nicht mit überschaubarem Aufwand) alle Einflussfaktoren, welche eine Ausführung auf der HANA Datenbank verhindern. Die hier beschriebenen Einflussfaktoren kann man sich gedanklich immer wieder in Erinnerung rufen, wenn man eine Query erstellt bzw. Queries lange Laufzeiten aufweisen und analysiert werden. Auf jeden Fall ist die gezeigte Analysemöglichkeit bei der Ausführung der Query in der RSRT eine interessante Möglichkeit, schnell und mit einfachen Mitteln zu ersten Ergebnissen zu gelangen und damit einen Ansatzpunkt für Verbesserungen zu haben. Natürlich hängt die Laufzeit einer Query nicht nur von diesen Faktoren ab. Aber es ist ein Baustein von vielen auf dem Weg zu performanten Berichten.