Vergleich von parametrisierten Abfrageplänen in SAP HANA Cloud mit dem SQL Analyzer

Kontext: Parametrisierte Abfragen und Leistungsschwankungen

Eine parametrisierte Abfrage kann für einige Eingabewerte schnell und für andere langsam laufen, da die Datenverteilung schief ist. Der Optimizer kompiliert einen Plan pro Anweisung, und dieser Plan mag für einen kleinen Selektivitätsbereich optimal, aber für einen großen schlecht sein. Beispielsweise kann eine Tabelfunktion, die einen Regionsparameter akzeptiert, für die Region DE 50 Zeilen in 20 ms zurückgeben, aber für die Region GLOBAL 2 Millionen Zeilen in 4 s. Der Unterschied ist nicht unbedingt ein Fehler in der Abfrage; es handelt sich oft um eine selektivitätsabhängige Planwahl. Der erste Schritt besteht darin, den Ausführungsplan für jeden Parametersatz zu erfassen und diese mit dem SQL Analyzer zu vergleichen. Ziel ist es zu entscheiden, ob die Schwankung durch die Planauswahl verursacht wird und ob die Aktivierung von Plan Variants oder das Umschreiben der Abfrage die richtige Lösung ist.

Der SQL Analyzer ist ein Set aus Ansichten, Tabellen und Graphen, mit denen Sie jede SQL-Abfrage analysieren können. Sie können in eine Graphausführung eintauchen, den Zeitablauf von Abfragekompilierung und Ausführung analysieren, visualisieren, welche Tabellen verwendet wurden, sehen, wie viele Datensätze jeder Schritt verarbeitet hat, und die Sequenz der Operatoren prüfen. Er ist nicht auf Calculation Views beschränkt; er kann SQL analysieren, das in Tabelfunktionen und SQL-Konsolenanweisungen definiert ist. Zur Nutzung müssen Sie die Erweiterung SAP HANA Performance Tools zum Development Space hinzufügen, was nur erfolgen kann, wenn der Development Space gestoppt ist. Der analysierende Benutzer benötigt die Systemberechtigungen TRACE ADMIN und INIFILE ADMIN. Der Workflow beginnt damit, das parametrisierte SQL in eine SQL-Konsole zu setzen, dann eine Plandatei mit Analyze Generate SQL Analyzer Plan File zu generieren und schließlich die Plandatei in der HANA SQL Analyzer-Ansicht zu öffnen.

Plandateien können aus dem eingebetteten SAP HANA Database Explorer generiert werden, wobei die Plandatei direkt in der SQL Analyzer-Ansicht geöffnet wird, oder aus externen Tools, wobei die Plandatei heruntergeladen und in die Explorer-Ansicht von SAP Business Application Studio hochgeladen werden muss. Der Speicherort generierter Plandateien ist fest und kann nicht geändert werden. Wenn Sie eine Plandatei später analysieren möchten, können Sie über die Explorer-Ansicht oder über den externen Datenbank-Explorer unter Catalog Database Diagnostic Files DB Instance ID other darauf zugreifen. Der entscheidende Punkt ist, dass Sie für jeden Parameterwert, den Sie vergleichen möchten, eine separate Plandatei benötigen. Ein einziger zwischengespeicherter Plan reicht nicht aus, wenn die Selektivität zwischen den Parameterwerten variiert.

Der Vergleich sollte sich auf die Ausführungszeit auf Schrittebene, die verarbeiteten Datensätze und die Operatorsequenz konzentrieren. Ein Schritt, der deutlich länger dauert als andere, oder ein Schritt, der weit mehr Datensätze verarbeitet als erwartet, ist ein Engpass. Die Operatorsequenz verrät Ihnen, ob der Optimizer eine andere Join-Reihenfolge, einen anderen Zugriffspfad oder eine andere Processing-Engine gewählt hat. Wenn der Plan für einen langsamen Parameterwert abweicht, können Sie entweder Plan Variants aktivieren, damit HANA mehrere Pläne basierend auf Filter-Selektivitätsclustern zwischenspeichert, oder die Abfrage umschreiben und das Modell restrukturieren, sodass der Optimizer über alle Selektivitätsbereiche hinweg einen stabilen Plan erstellt. Die Entscheidung hängt davon ab, ob der Optimizer die Selektivitätscluster unterscheiden kann und ob die Abfragestruktur grundsätzlich effizient ist.

Plan Variants ermöglichen es SAP HANA, mehrere Ausführungspläne für eine parametrisierte Abfrage basierend auf der Selektivität von Tabelfiltern zu cachen. Der Optimizer wertet Prädikate aus, kompiliert Pläne und assoziiert Filterwerte mit Clustern. Dies reduziert Leistungsschwankungen und gewährleistet eine stabilere Abfrageleistung. Plan Variants helfen jedoch nur, wenn der Optimizer Parameterwerte in unterschiedliche Selektivitätscluster gruppieren kann. Wenn die Abfragestruktur für alle Eingaben grundsätzlich ineffizient ist oder der Optimizer die Cluster nicht unterscheiden kann, wird das Planmanagement allein das Problem nicht lösen. In diesem Fall bleibt das Umschreiben der Abfrage oder die Restrukturierung des Modells die einzige Option.

Die Monitoring-Views M_SQL_PLAN_VARIANTS und M_SQL_PLAN_VARIANT_STATISTICS können verwendet werden, um aktive Plan Variants zu überwachen und entsprechende Ausführungsstatistiken einzusehen. Diese Ansichten helfen zu verifizieren, dass der Optimizer die erwarteten Cluster erstellt hat und dass die Pläne verwendet werden. Sie helfen auch dabei, die durch Plan Variants erzielten Leistungsverbesserungen zu messen, einschließlich reduzierter Schwankungen. Die Entscheidung zum Umschreiben sollte auf den Belegen aus den Plandateien basieren, nicht auf Annahmen über die Datenverteilung.

Ein konkretes Beispiel ist eine Tabelfunktion mit einem Regionsparameter. Für Region DE gibt die Abfrage 50 Zeilen in 20 ms zurück; für Region GLOBAL 2 Millionen Zeilen in 4 s. Platzieren Sie beide parametrisierten Aufrufe in der SQL-Konsole, generieren Sie zwei Plandateien, öffnen Sie diese nebeneinander im SQL Analyzer und beobachten Sie, dass der Optimizer für GLOBAL einen vollständigen Column-Store-Scan mit einem Nested-Loop-Join gewählt hat, anstatt der Indexsuche plus Hash-Join, die für DE verwendet wurde. Dies bestätigt, dass der Plan je nach Parameterwert variiert, und legt nahe, entweder Plan Variants zu aktivieren oder die Join-Reihenfolge und den Filter-Pushdown umzuschreiben.

SELECT * FROM TABLE(TABLE_FUNCTION(:region)) WHERE region = :region;

Begründung: Plan Variants versus Umschreiben der Abfrage

Eine parametrisierte Abfrage wird mit einem einzigen Ausführungsplan zwischengespeichert, aber dieser Plan ist ein Kompromiss. Wenn sich die Selektivität eines Filters ändert, kann sich auch der optimale Plan ändern. Wenn der Optimizer die Selektivitätscluster nicht unterscheiden kann, wählt er möglicherweise einen Plan, der für einige Werte gut und für andere schlecht ist. Dies ist die Grundursache für SQL-Leistungsschwankungen. Plan Variants adressieren dies, indem sie SAP HANA erlauben, mehrere Pläne basierend auf der Selektivität von Tabelfiltern zu cachen. Der Optimizer wertet Prädikate aus, kompiliert Pläne und ordnet Filterwerte Clustern zu. Das bedeutet, das System kann einen Plan für einen kleinen, selektiven Bereich und einen anderen Plan für einen großen, unselektiven Bereich vorhalten.

Die Einschränkung, nur einen Ausführungsplan zu cachen, besteht darin, dass er sich nicht an Änderungen der Datenverteilung anpassen kann. Ein Plan, der für ein kleines Ergebnismenge optimal ist, kann für eine große Menge schrecklich sein, weil er einen Nested-Loop-Join oder einen Full Scan verwendet. Plan Variants lösen dies durch separate Pläne für jeden Selektivitätscluster. Der Optimizer entscheidet, welchem Cluster ein Parameterwert angehört, und nutzt den entsprechenden Plan. Dies reduziert Schwankungen und stabilisiert die Leistung. Die Monitoring-Views M_SQL_PLAN_VARIANTS und M_SQL_PLAN_VARIANT_STATISTICS zeigen die aktiven Varianten und Statistiken, sodass die korrekte Clusterbildung verifiziert werden kann.

Plan Variants sind jedoch keine universelle Lösung. Sie helfen nur, wenn der Optimizer Selektivitätscluster unterscheiden kann. Wenn die Abfragestruktur für alle Eingaben grundsätzlich ineffizient ist oder der Optimizer die Parameterwerte nicht in unterschiedliche Cluster trennen kann, wird das Planmanagement die Leistung nicht verbessern. In diesem Fall ist die einzige Option, die Abfrage umzuschreiben oder das Modell zu restrukturieren. Ein Umschreiben kann die Join-Reihenfolge ändern, Filter nach unten schieben oder eine Tabelfunktion durch ein effizienteres Konstrukt ersetzen. Die Entscheidung sollte auf den Plandateien des SQL Analyzers basieren.

Der Workflow besteht darin, Plandateien für jeden Parameterwert zu generieren, diese im SQL Analyzer zu vergleichen und dann zu entscheiden, ob Plan Variants oder ein Umschreiben erforderlich sind. Wenn die Plandateien unterschiedliche Operatorsequenzen, Datensätze oder Schrittzeiten zeigen, unterscheidet der Optimizer bereits die Parameterwerte. Die Aktivierung von Plan Variants kann dann die Schwankungen reduzieren. Wenn die Plandateien denselben Plan zeigen, dieser aber für einen bestimmten Parameterwert langsam ist, unterscheidet der Optimizer die Cluster nicht, und ein Umschreiben ist wahrscheinlich erforderlich.

Die entscheidende Unterscheidung liegt zwischen Planmanagement und Abfragestruktur. Plan Variants verwalten mehrere Pläne, beheben aber keine ineffiziente Grundstruktur. Wenn der Optimizer keine Selektivitätscluster unterscheiden kann oder die Datenschiefe extrem ist, muss die Abfrage umgeschrieben werden. Die Belege aus dem SQL Analyzer sollten die Entscheidung leiten. Die Plandateien zeigen, ob der Optimizer unterschiedliche Pläne wählt und ob diese stabil sind. Sind die Pläne stabil, aber für einen bestimmten Wert langsam, liegt das Problem in der Struktur. Sind die Pläne unterschiedlich, aber der langsame Plan wird für einen großen Selektivitätsbereich gewählt, könnten Plan Variants ausreichen.

Die Monitoring-Views liefern die notwendigen Belege. M_SQL_PLAN_VARIANTS zeigt aktive Varianten, M_SQL_PLAN_VARIANT_STATISTICS die Ausführungsstatistiken. Damit lässt sich prüfen, ob die erwarteten Cluster erstellt wurden. Dies ist wichtig, da Plan Variants Overhead verursachen können und der Nutzen die Kosten übersteigen muss. Die Entscheidung zum Umschreiben sollte auf Plandateien und Monitoring-Views basieren, nicht auf Annahmen.

Im Beispiel der Tabelfunktion mit Regionsparameter: Für DE (50 Zeilen, 20 ms) und GLOBAL (2 Millionen Zeilen, 4 s) zeigt der SQL Analyzer für GLOBAL einen Full Column-Store-Scan mit Nested-Loop-Join statt der Indexsuche mit Hash-Join bei DE. Dies bestätigt die Planabweichung und legt entweder Plan Variants oder ein Umschreiben der Join-Reihenfolge und des Filter-Pushdowns nahe.

SELECT * FROM M_SQL_PLAN_VARIANTS WHERE SCHEMA_NAME = '<container_schema_name>' AND OBJECT_NAME = '<calculation_view_or_function>';

Konkrete Illustration: Vergleich von Plandateien im SQL Analyzer

Der Workflow beginnt mit dem Platzieren des parametrisierten SQL in einer SQL-Konsole. Die Abfrage muss nicht ausgeführt werden; es genügt die Generierung der Plandatei. Nutzen Sie die Menüoption Analyze Generate SQL Analyzer Plan File, wählen Sie ein Dateipräfix und speichern Sie. Der Ort ist fest vorgegeben. Wenn die Konsole aus dem eingebetteten SAP HANA Database Explorer geöffnet wurde, öffnet sich die Datei sofort in der HANA SQL Analyzer-Ansicht. Bei Generierung aus anderen Tools (z. B. Data Preview) muss die Datei heruntergeladen und in die Explorer-Ansicht von SAP Business Application Studio hochgeladen werden. Die Erweiterung SAP HANA Performance Tools muss im gestoppten Zustand des Development Space hinzugefügt worden sein.

Nach dem Upload wird die Datei ausgewählt, um die Ergebnisse im Hauptfenster anzuzeigen. Die SQL Analyzer-Ansicht zeigt den Ausführungsplan als Graph mit Ausführungszeit auf Schrittebene, verarbeiteten Datensätzen und der Operatorsequenz. Man kann in die Graphausführung eintauchen, den Zeitablauf von Kompilierung und Ausführung analysieren und die Anzahl der verwendeten Tabellen visualisieren. Ziel ist es, Schritte zu identifizieren, die signifikant länger dauern, weit mehr Datensätze verarbeiten als erwartet oder deren Operatorsequenz zwischen Parameterwerten variiert. Dies sind Anzeichen für eine selektivitätsabhängige Planwahl.

Für das konkrete Beispiel generieren Sie zwei Plandateien: eine für Region DE und eine für Region GLOBAL. Öffnen Sie beide nebeneinander im SQL Analyzer. Für DE sollte der Plan eine Indexsuche und einen Hash-Join mit wenigen Datensätzen zeigen. Für GLOBAL sollte der Plan einen Full Column-Store-Scan und einen Nested-Loop-Join mit einer großen Menge an Datensätzen zeigen. Die Schrittzeiten und Datensätze bestätigen den Unterschied. Dieser Beleg zeigt, dass der Optimizer für den langsamen Parameterwert einen anderen Plan gewählt hat, was Plan Variants oder ein Umschreiben erforderlich macht.

Der Fokus sollte auf der Operatorsequenz liegen, da diese verrät, ob der Optimizer eine andere Join-Reihenfolge, einen anderen Zugriffspfad oder eine andere Engine gewählt hat. Ein Full Column-Store-Scan statt einer Indexsuche ist ein häufiges Zeichen für ein Selektivitäts-Mismatch. Ein Nested-Loop-Join statt eines Hash-Joins ist ein weiteres Zeichen. Die Datensätze pro Schritt zeigen die Datenmenge. Wenn ein Schritt Millionen von Zeilen verarbeitet, obwohl es nur Dutzende sein sollten, ist dies der Engpass. Die Timeline hilft zu sehen, ob die Verzögerung in der Kompilierung, der Ausführung oder bei einem spezifischen Operator liegt.

Nach dem Vergleich entscheiden Sie über Plan Variants oder Umschreiben. Zeigen die Dateien unterschiedliche Pläne und kann der Optimizer die Cluster unterscheiden, reduzieren Plan Variants die Schwankungen. Zeigen die Dateien denselben Plan, der aber für einen Wert langsam ist, unterscheidet der Optimizer die Cluster nicht, und ein Umschreiben ist nötig. Die Views M_SQL_PLAN_VARIANTS und M_SQL_PLAN_VARIANT_STATISTICS verifizieren die Aktivität der Varianten und die Übereinstimmung der Statistiken mit den erwarteten Selektivitätsclustern.

Beispiel: Region DE (50 Zeilen, 20 ms) vs. Region GLOBAL (2 Mio. Zeilen, 4 s). In der SQL-Konsole zwei Plandateien generieren, nebeneinander im SQL Analyzer öffnen. Beobachtung: GLOBAL nutzt Full Column-Store-Scan und Nested-Loop-Join, DE nutzt Index-Seek und Hash-Join. Dies bestätigt die Planvarianz und legt Plan Variants oder ein Umschreiben der Join-Reihenfolge/Filter-Pushdown nahe.

EXPLAIN PLAN FOR SELECT * FROM TABLE(TABLE_FUNCTION(:region)) WHERE region = :region;

Anwendbarkeitsgrenzen

Der SQL Analyzer erfordert die Erweiterung SAP HANA Performance Tools im Development Space, die nur im gestoppten Zustand hinzugefügt werden kann. Dies ist eine Voraussetzung, die vorab geprüft werden muss. Der analysierende Benutzer benötigt die Systemberechtigungen TRACE ADMIN und INIFILE ADMIN. Da dies Systemberechtigungen sind, werden sie Anwendern in Produktionsumgebungen möglicherweise nicht gewährt, wodurch der Workflow nicht für alle Nutzer verfügbar ist. Plandateien aus externen Tools müssen manuell hochgeladen werden, was den Workflow verlängert. Der feste Speicherort der Dateien kann den Prozess zudem komplizieren.

Plan Variants helfen nur, wenn der Optimizer Parameterwerte in unterschiedliche Selektivitätscluster gruppieren kann. Sie beheben keine grundsätzlich ineffizienten Abfragestrukturen. Wenn der Optimizer die Cluster nicht unterscheiden kann oder die Datenschiefe extrem ist, löst Planmanagement das Problem nicht. In diesem Fall bleibt nur das Umschreiben der Abfrage oder die Restrukturierung des Modells. Die Monitoring-Views M_SQL_PLAN_VARIANTS und M_SQL_PLAN_VARIANT_STATISTICS helfen bei der Verifizierung der Cluster, ändern aber nicht die zugrunde liegende Struktur.

Die Entscheidung zwischen Plan Variants und Umschreiben muss auf den Belegen der Plandateien basieren. Unterschiedliche Pläne bei unterscheidbaren Selektivitätsclustern sprechen für Plan Variants. Gleiche Pläne bei unterschiedlicher Performance sprechen für ein notwendiges Umschreiben. Die Monitoring-Views liefern Belege, ersetzen aber nicht das Verständnis der Abfrage und der Datenverteilung.

Beispiel: Region DE (50 Zeilen, 20 ms) vs. Region GLOBAL (2 Mio. Zeilen, 4 s). Zwei Plandateien generieren, im SQL Analyzer vergleichen. Ergebnis: GLOBAL nutzt Full Column-Store-Scan und Nested-Loop-Join, DE nutzt Index-Seek und Hash-Join. Dies bestätigt die Planvarianz und legt entweder Plan Variants oder ein Umschreiben der Join-Reihenfolge und des Filter-Pushdowns nahe, um einen stabilen Plan über alle Selektivitätsbereiche zu gewährleisten.

SELECT * FROM M_SQL_PLAN_VARIANTS WHERE SCHEMA_NAME = '<container_schema_name>' AND OBJECT_NAME = '<calculation_view_or_function>';