Nützlich und oft ungenutzt - der Oracle SQL Tuning Advisor
Da hat man nun das SQL-Statement identifiziert, das viel zu lange braucht und die ganze Anwendung ausbremst. Aber, wie kriegt man das jetzt flotter?
Die echten Oracle-Experten sehen sich den Ausführungsplan und die Statistiken an, die Indexe und die Distinct-Values der Key-Felder, und dann ist denen alles klar. Wenn man ein Oracle-Experte ist...
Ist man das nicht, kommt bisweilen etwas Hilflosigkeit auf. Es gibt aber ein Tool, das in allen SAP-Systemen mit einer Oracle-Datenbank vorhanden ist, das aber viel zu selten genutzt wird - der "SQL Tuning Advisor".
Die seltene Nutzung liegt allerdings auch daran, dass es gut versteckt ist.
Zu finden ist es in der ST04 > Performance > SQL Statement Analysis:
Der Menüpunkt zum "SQL Tuning Advisor" in der ST04
Sehen Sie mal nach... wie, der Menüpunkt fehlt bei Ihnen?
Ja, das ist meistens so. Im Standard wird dieses Tool ausgeblendet, aus lizenzrechtlichen Gründen - sollten Sie die Oracle-Datenbank nicht über SAP sondern direkt von Oracle bezogen haben, ist das "Tuning Pack" erforderlich, um den Tuning Advisor nutzen zu dürfen.
Infos dazu finden Sie im SAP-Hinweis 1028068 - Notwendige Oracle Optionen für das DBA Cockpit.
Wenn Sie das "Tuning Pack" lizenziert bzw. die Oracle-DB über SAP bezogen haben, dürfen Sie den Tuning Advisor nutzen.
Im SAP-Hinweis steht auch, was Sie tun müssen, um den Tuning Advisor verfügbar zu machen: einen Eintrag mit "TUNINGPACK" / "X" für das System in der Tabelle ORA_FEAT_USED anlegen.
Tabelle ORA_FEAT_USED
In "offenen" Systemen (also in einem Entwicklungssystem) können Sie die SE16 dafür verwenden, um den Satz in die Tabelle einzutragen. In geschlossenen Systemen gibt es die Möglichkeit, den Funktionsbaustein SE16N_INTERFACE zu verwenden (sofern verfügbar) oder den Eintrag mit "Shortcut for SAP Systems" vorzunehmen. Das einfachste wird sein, jeweils einen Eintrag für alle Systeme im Entwicklungssystem anzulegen und die Tabelleneinträge per Transportauftrag in die Systeme zu verteilen.
Sieht man dann in der ST04 erneut nach (einmal die Transaktion neu aufrufen), ist der Menüeintrag wie im Bild oben vorhanden.
Ok, dann wollen wir den Tuning Advisor mal nutzen. Wir haben da z.B. dieses teure SQL-Statement. 2 Ausführungen seit Systemstart, jeweils 40 Sekunden Laufzeit. Die Anzahl der Ausführungen ist hier recht gering, schlechter wäre eine hohe Ausführungszahl und eine lange Laufzeit pro Ausführung.
Shared Cursor Cache: ein teures SQL-Statement
Ein Klick auf den "Explain"-Button zeigt den Ausführungsplan. Dort sehen wir auch eine "SQL-ID":
Shared Cursor Cache: Ausführungsplan
Mit der SQL-ID starten wir nun den Oracle SQL Tuning Advisor.
Start des Oracle SQL Tuning Advisor
Auch eine Online-Ausführung ist möglich, aber gerade bei größeren Tabellen ist eine Ausführung im Batch vorzuziehen. Den Job finden wir in der SM37:
SM37: Ausführung des Oracle SQL Tuning Advisor im Batch
Nach der Fertigstellung ist die Auswertung vom Oracle SQL Tuning Advisor in der Spoolliste des Jobs zu finden.
Ausgabe des Oracle SQL Tuning Advisor
Die Liste sieht nicht ganz vollständig aus, der rechte Rand ist abgeschnitten. Eine Unschönheit beim ABAP-Programm RSORASTS, der längere Zeilen ausgibt, aber keine entsprechende "line-size" nach dem "REPORT"-Statement gesetzt hat. Aber die wesentlichen Informationen sind da: in diesem Fall schlägt der Tuning Advisor einen "Patch" auf das Statement vor, so dass ein anderer Index verwendet wird. Prognostizierte Zeit-Ersparnis: stolze 99,99%. Die Werte sind meistens etwas übertrieben, aber eine Verbesserung ist auf jeden Fall zu erwarten.
In der Liste findet sich der aktuelle Ausführungsplan sowie der Ausführungsplan, wie er nach dem Patch wäre, inkl. einiger interessanter Kennzahlen. Hier schrumpft die Anzahl der beteiligten Tabellenzeilen signifikant, von 12 Mio. auf lediglich 12.
Oft findet sich aber auch die Empfehlung, einen neuen Index anzulegen, wie in diesem Beispiel:
Auch hier findet sich wieder eine Prognose über eine enorme Laufzeitverkürzung und ein Ausführungsplan vorher / nachher.
Bei der Anlage eines Index ist natürlich zu berücksichtigen, dass entsprechende Lesezugriffe profitieren, aber der Datenbank eine zusätzliche Last bei Änderungen auferlegt wird. Ein Index bei einer Tabelle mit hohem Änderungsvolumen wirkt sich dann positiv auf einen Lesezugriff mit entsprechenden Selektionskriterien aus, kann sich aber auch insgesamt eher negativ auswirken. Vor der Anlage eines Index sollte man daher noch einen Blick in die Tabellenstatistiken (Transaktion ST10) werfen und dort einen Blick auf die Werte bzgl. Tabellenänderungen werfen. Der SAP-Hinweis 912620 - FAQ: Oracle Indizes behandelt das Thema "Index" ausführlich.
Letztendlich ist der Oracle SQL Tuning Advisor aber eine feine Sache: man bekommt schnell und unkompliziert Empfehlungen zur Verbesserung eines einzelnen SQL-Statements. Im Fall der Empfehlung eines Index hat der Tuning Advisor bereits die Selektivität einzelner Felder berücksichtigt und die Reihenfolge der Felder entsprechend optimiert - darüber muss man sich dann keine Gedanken mehr machen.
Man kann vom Tuning Advisor aber auch als Resultat bekommen, dass keine weiteren Optimierungen an dem Statement möglich sind - in dem Fall kann man sich weitere Überlegungen bzgl. Index oder SQL-Patch sparen und Laufzeitoptimierungen sind dann "nur noch" in der Anwendungslogik oder der Formulierung des SQL-Statements möglich.
Es gibt noch keine Rezension.