Tuning der problematischen SQL-Anweisungen - Performance Tuning fur Oracle-Datenbanken - page 343

18.4.2 Analyse der Laufzeitstatistiken als Methode des formalen

SQL-Tunings

Die wichtigsten Laufzeitstatistiken für SQL-Tuning sind die Ausführungsplanstatistiken. An-
hand dieser Statistiken kann man leicht die kritischen Stellen im Ausführungsplan erkennen.
Peter: „ Ich bin nicht sicher, dass es so leicht ist .“
Leonid: „ Es ist ziemlich leicht. In erster Linie muss man die Schritte mit der größten Kar-
dinalität, also mit der größten Treffermenge, ermitteln .“
P.: „ Warum wählt man nicht die Schritte mit der größten Laufzeit oder mit den meisten
Buffer Gets? “
L.: „ Weil die Schritte mit der größten Kardinalität die nächsten Ausführungsplanschritte
beeinflussen und dort eine große Laufzeit, viele Buffer Gets oder Disk Reads verursachen. Sie
selber können dabei bescheidene Werte für diese Statistiken haben. Man muss also zunächst
die Ausführungsplanschritte mit der größten Kardinalität untersuchen. Wenn es mehrere
sind, muss man mit dem ersten Schritt anfangen, der vor allen anderen ausgeführt wird .“
P.: „ Angenommen, wir haben eine große Tabelle, wo ein wichtiger Index fehlt. Dann äu-
ßert sich das in einem teuren Full Table Scan, der relativ wenige Datensätze zurückliefert.
Deine Methode funktioniert in diesem Fall nicht .“
L.: „ Man muss sicherlich auch die anderen Laufzeitstatistiken bei der Analyse des Ausfüh-
rungsplans im Auge halten. Die Kardinalität ist aber in vielen Fällen die wichtigste Statistik.
Der Fall, den Du eben beschrieben hast, stellt ein lokales Problem im Ausführungsplan dar,
weil ein Full Table Scan mit einer kleinen Treffermenge die nächsten Ausführungsplanschritte
entsprechend wenig beeinflusst .“
P.: „ Wie genau erkennt man im Ausführungsplan, dass ein Index fehlt? “
L.: „ Was ist Deine Meinung? “
P.: „ Das muss ein Full Table Scan sein, der viele Buffer Gets bzw. Disk Reads ausführt
und wenige Datensätze selektiert. Wenn die jeweilige Tabelle viele Datensätze hat, was man
anhand der Optimizer-Statistiken feststellen kann, ist es ein Indiz für einen fehlenden Index .“
L.: „ Richtig, Peter. Wenn die Anzahl der Datensätze nicht sehr groß ist, kann es auch ein
Indiz für eine hohe High Water Mark unserer Tabelle sein. In diesem Fall wird eine Tabellen-
reorganisation helfen. Als schnelle Hilfe kann man aber auch in diesem Fall den jeweiligen
Index anlegen. Mit dem Anlegen der neuen Indices muss man übrigens etwas aufpassen, weil
es die Performanz anderer SQL-Anweisungen verschlechtern kann .“
P.: „ Was macht man weiter, nachdem man den Ausführungsplanschritt mit der größten
Kardinalität gefunden hat? “
L.: „ Es hängt davon ab, wie dieser und die nächsten Ausführungsplanschritte sind. Am bes-
ten zeige ich das an folgenden zwei Beispielen. In einem Beispiel hilft Änderung der Tabellen-
reihenfolge im Join, in dem anderen wird die Performanz durch Erweiterung eines Indexes um
eine Spalte verbessert. Solche Fälle sind ziemlich einfach zu analysieren und treten häufig in
der Praxis auf. Bei komplexeren Fällen kann man denselben Ansatz bei der Analyse benutzen .“
EineSQL-AnweisunghatbeieinemSystemgravierendePerformanz-Problemeverur-
sacht. Diese SQL-Anweisung habe ich testweise mit den Ausführungsplanstatistiken aus-
geführt.DasErgebnisistuntenpräsentiert.