Development Knowledge – Teil 2: ABAP Performancetuning – SQL-Trace

blog-featureimage-tipps-tricks

Wie im ersten Blog versprochen, werde ich in diesem Teil auf den SAP-SQL-Trace eingehen und die Analysemöglichkeiten des Traces beschreiben. Ich werde nicht auf die Spezifika der einzelnen von SAP unterstützen Datenbanksysteme eingehen, sondern nur die datenbankunabhängige Sicht des Applikationsservers beschreiben. So gelten die Aussagen dann für alle von SAP unterstützten DB-Systeme. Vorab: Wunder kann der Trace nicht vollbringen, aber wertvolle Hinweise, die die Performance von Programmen deutlich verbessern können.

SAP HANA, ein In Memory Konzept, dass neben der vollständigen Pufferung aller Daten im Hauptspeicher, ein spaltenorientiertes Datenbankkonzept nutzt, stellt weiter Ansprüche an die Entwicklung – auch ein Thema, dass ich in einem zukünftigen Blog aufgreifen werde. Besonders für SAP HANA, aber auch alle anderen SELECT-Anweisungen gilt:

SELECT * macht jeder gern …       – das ist aber schon immer ein schlechter Ansatz

Fast niemand benötigt bei Datenbankzugriffen alle Spalten einer Datenbanktabelle. Das vollständige Lesen aller Tabellenspalten kostet Zeit und Speicher und führt im Falle SAP HANA zu sehr deutlichen Performanceverlusten. Leider hat sich das „*“ in der Feldliste auch innerhalb von SAP-Programmen recht fest etabliert, weil man sich ja vorher nicht überlegen musste, welche Spalten wirklich relevant sind – liest man alle, fehlt eben keine. Für eigene Programme sollte jeder Developer genau überlegen, welche Spalten relevant sind und nur genau diese Lesen.

Der Datenbankview auf Fertigungsauftragsköpfe, CAUFV, ist über 4 kB breit. Warum sollte ich 4 KB Lesen, wenn mich nur die Auftragsnummer und die Auftragsart interessieren, also nur 23 Byte (Unicode). Das spart Transportzeit und Speicherplatz und ermöglicht SAP HANA wieselflinke Zugriffe.

Der SQL Trace

Was der Trace nicht liefern kann, ist die Aussage ob es möglicherweise „bessere“ Tabellen für den Zugriff gibt. SAP liefert nämlich einige Indextabelle aus, die Zugriffe besser gruppieren als die Originaltabellen. Ein gutes Beispiel ist die recht häufig gestellt Anfrage nach Vertriebsbelegpositionen zum Material, also die Frage „In welchen Positionen wurde das Material XYZ verkauft?“

In fast allen Programmen wird hierzu die Tabelle VBAP konsultiert, deren Standardindizes aber das Feld Materialnummer nicht enthalten. Damit dauert ein derartiger Zugriff sehr lange, bzw. ist technisch gesehen mit großen Zugriffkosten verbunden. Gestaltet man den Zugriff nun aber zweiteilig und nutzt die Indextabelle VAPMA, findet über das Material ein sehr schneller Primärzugriff statt. Die so ermittelte Menge an Auftragspositionen kann dann effizient für weitere Analysen verwendet werden. Eine Auswahl an Indextabellen werde ich wiederum in einem meiner folgenden Blogs beschreiben.

Transaktion ST05 – SQL-Trace.

sql-trace

Nach dem Aktivieren des Traces werden alle Datenbankzugriffe des angemeldeten Benutzers aufgezeichnet; Einschalten mit Filter ermöglich es, auch andere Benutzer zu verfolgen.

Im nachfolgenden Beispiel wird die Transaktion MB51 (Materialbelege anzeigen) mit sehr ungünstigen Selektionskriterien aufgerufen. Wir wollen wissen, welche Materialbelege in einen bestimmten Zeitraum und mit bestimmten Bewegungsarten durchgeführt wurden. Der Trace zeigt hierfür eine Zugriffszeit von fast 55 Sekunden. Die Funktion EXPLAIN zeigt uns dann, was die Datenbank für diesen Zugriff alles leisten musste; die dargestellten Ausführungspläne sind datenbankabhängig und können sich in der Art der Darstellung unterscheiden. Für das Verständnis des Traces benötigt man keine großen Datenbankkenntnisse (die aber natürlich nicht schaden). Es reicht in fast allen Fällen aus, die verwendeten Indizes anzuschauen und zu beurteilen, ob diese denn passen.

trace-liste

EXPLAIN zeigt folgende Zugriffe:

explain

Zwei Tabellen, Materialbelegkopf- und Positionen wurden per JOIN vereint. Neben den Primärindizes MKPF~0 und MSEG~0, wird noch ein Index MESEG~M konsultiert. Dieser enthält folgende Felder:

mseg

Wichtig für das Verstehen von Indexzugriffen ist, dass diese nur dann optimal genutzt werden können, wenn der Zugriff „linksbündig“ erfolgt. Soll dieser Index optimal greifen müssen also die Werte für die Materialnummer, Werk und Lagerort gesetzt sein; der Mandant wird implizit gesetzt, muss aber im Index vorhanden sein. In unserem Beispiel sind diese Felder aber nicht in den Selektionskriterien enthalten, so dass der Index zumindest keine optimale Wirkung zeigen kann. Warum er dennoch hier genutzt wird, liegt am Optimierer, der die Zugriffe analysiert und automatisch optimiert – s.u.

Wird jetzt ein Index angelegt, der die Bewegungsart enthält, wird der Effekt deutlich sichtbar.

mseg2

trace-liste2

Dauert das Vorbereiten des SQL-Statements OPEN vorher fast 2,4 Sekunden, ist die Zeit hierfür nun auf 0,061 Sekunden geschrumpft. Die Zeit für Holen der Daten verbessert sich von 0,9 auf 0,2 Sekunden. Wie wir im EXPLAIN sehen, wird jetzt wie gewünscht der neue Index MSEG~ZBW verwendet.

explain2

INDIZES

Ein Datenbankindex kann Wunder vollbringen, aber trotzdem ist bei der Verwendung einiges zu beachten. Er stellt im rein technischen Sinne ebenfalls eine Datenbanktabelle dar, die Platz und Pflege benötigt. Bei jedem Einfügen, Löschen oder Ändern eines Datensatzes der Haupttabelle müssen die Einträge im Index ebenfalls angepasst werden – das kostet auch Zeit und Aufwand und muss bei der Indexplanung berücksichtigt werden. Zu viele Indizes können der Performance wieder schaden – hier gibt es aber keine Hausnummer, die die Anzahl allgemeingültig festlegt.

Optimierer

Bevor eine Anfrage zur Datenbank abgesetzt wird, schaut sich der Optimierer die Anfrage an und ermittelt optimale Zugriffspfade.

Wichtigste Kriterien sind:

  • gibt es einen passenden Datenbankindex
  • wie groß sind die beteiligten Tabellen / lohnt es sich ggf. die gesamte Tabelle in den Speicher zu holen und dort auszuwerten?

– gibt es einen passenden Datenbankindex

– wie groß sind die beteiligten Tabellen / lohnt es sich ggf. die gesamte Tabelle in den Speicher zu holen und dort auszuwerten?

Damit der Optimierer nicht immer alle Kriterien neu ermitteln muss, bedient er sich zyklisch erstellter Datenbankstatistiken. Manche Datenbank pflegen die Statistiken automatisch, andere benötigen einen manuellen Anstoß, z.B. durch einen zyklischen SAP-Job; üblich ist, dass dieser wöchentlich sonntags läuft.

Die Statistiken enthalten Informationen über die Tabellengröße und ihr Wachstum, die Anzahl eindeutiger Einträge, Aufbau, Größe und Struktur der Indizes – manchmal über Heuristiken auch Informationen über die Datenverteilung. Anhand dieser Informationen versucht der Optimierer einen optimalen Zugriffspfad auf die Daten zu ermitteln. Ist eine Datenbanktabelle oder ein Index klein, kann es sein dass diese vollständig in den Hauptspeicher (der Datenbank) geladen und dort durchsucht werden.

Fazit kurz und knapp

Es gibt einfache Maßnahmen, die Performance von Programmen zu verbessern und es ist wichtig, diese schon beim Programmentwurf zu berücksichtigen.

In erster Linie geht es darum, nur die notwendigen Daten (Zeilen und Spalten) zu lesen und die Kriterien für die Suche so zu gestalten, dass möglichst immer ein guter Index gefunden wird. Das ist gerade bei frisch aufgebauten SAP-Systemen schwierig, da die Zugriffe am Anfang immer schnell sind – schließlich gibt´s ja am Anfang auch nur wenige Daten im System. Wenn dann die ersten Programme wegen Zeitüberschreitung abbrechen, ist der Ärger groß und es muss nachgearbeitet werden; das spart man sich mit einer Vorabanalyse.

Viel Spaß und Erfolg beim Optimieren!

Falls Sie in der Zwischenzeit Fragen zu diesem Thema haben, freue ich mich über einen Kommentar unter diesem Blog oder eine Mail an: development@itelligence.de

– von Andreas Bork, Teamleitung und Entwicklung, Custom Development & Advanced Services, itelligence AG –

Ähnliche Beiträge

feature-image-people
Lesen Sie mehr
blog-featured-image-auster
Lesen Sie mehr
featured-image-sundown
Lesen Sie mehr
itelligence Conference Center
Lesen Sie mehr
image blog digitale welt
Lesen Sie mehr
SAP S/4HANA Generationswechsel
Lesen Sie mehr

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Folgen Sie uns: