Datenbanken II
SQL - Ausführungspläne
Matthias Jauernig (03INB), Michael Lahl (03IND)
Inhalt
• Begriff der Ausführungspläne
• Der DBMS-Optimizer
• Ausführungspläne in Oracle:
– SQL+: EXPLAIN PLAN, AUTOTRACE
– SQL Analyze
• Beispiel
Was sind Ausführungspläne? (1)
Ausführungsplan (engl.: Execution Plan):
• Ist die Umwandlung einer SQL Query in
eine für das DBMS ausführbare Form,
• Beschreibt die Schritte zur Ausführung
einer SQL Query,
• gibt DBMS eine Abarbeitungsfolge für
das vom Benutzer eingegebene SQL
Statement vor
Was sind Ausführungspläne? (2)
• Es kann viele Ausführungspläne geben, die dasselbe SQL
Statement erfüllen, z.B. durch Variieren der Reihenfolge,
in der algebraische Operationen ausgeführt werden,
• Laufzeit und Antwortzeit eines SQL Statements
wesentlich vom Ausführungsplan bestimmt,
 Ziel: möglichst kostengünstiger Ausführungsplan,
• Optimierung von SQL–Statements durch DBMS Optimizer
oder manuell durch Anwender möglich,
• Interpretation von Ausführungsplänen versetzt
Anwender in die Lage, Performanceverbesserungen für
Anfragen zu erreichen.
Interne Umwandlung
• „Query Rewrite“
• SQL–Statement intern in prozedurale Form
•
•
umwandeln, d.h. für SQL–Befehle werden die
Operatoren der relationalen Algebra eingesetzt
Ausführungsplan = Operatorbaum – Knoten
stellen Operatoren zur Verknüpfung von
Zwischenergebnissen dar
Zur Abarbeitung des Baums müssen konkrete
Implementierungstechniken angewendet werden
(z.B. Nested Loop Join, Index Scan, …)
Der DBMS-Optimizer (1)
• Generiert eine Menge von möglichen
Ausführungsplänen, wählt den
kostengünstigsten aus,
• Berechnet für jeden Plan einen
„Kostenvoranschlag“
• Unterscheidung zwischen:
– RBO (rule-based optimizer)
– CBO (cost-based optimizer)
RBO – rule-based optimizer
• Ältere Form des Optimierers
• Ausführungsplan wird anhand eines festen
Regelwerks, Prioritäten zwischen
Operationen und Informationen des Data
Dictionary (Indexe, …) erstellt
• Nachteile: Keine Auswertung von
Statistiken, begrenzter Regelsatz
CBO – cost-based optimizer
• Verwendet Statistiken zur Schätzung der
Kosten (I/O, CPU) eines
Ausführungsplans,
• Statistiken beinhalten z.B. Informationen
zu Datenverteilung / Speicherung von
Tabellen und Indexes
• Vorteil: Genauere Kosten als bei RBO
• Nachteil: Statistiken regelmäßig zu
erstellen bzw. aktualisieren
Der DBMS-Optimizer (2)
1. Optimizer spannt zunächst Suchraum von
möglichen Plänen auf  Beschränkung
sinnvoll, z.B. breiter Einsatz von:
Heuristiken: (=Daumenregeln)
- Selektionen so früh wie möglich,
- Basisoperationen als 1 Berechnungsschritt,
- Nur Berechnungen ausführen, die Beitrag zu
Gesamtergebnis liefern.
Der DBMS-Optimizer (3)
2. Optimizer wählt dann Plan mit minimal
geschätzten Gesamtkosten aus 
Suchraum wird durchlaufen
 erschöpfend: NP-Problem, Algorithmen: Greedy,
dyn. Programmierung, Branch&Bound
 partiell: keine opt. Lösung garantiert, Verfahren:
simulated annealing, hill climbing, genetische
Algorithmen
Ausführungspläne in Oracle
• mehrere Möglichkeiten zur Erzeugung von
Ausführungsplänen stehen zur Verfügung:
– SQL*Plus (textbasiert)
• EXPLAIN PLAN – Befehl
• AUTOTRACE – Funktionalität
– Programm SQL–Analyze (nur in der
Enterprise Version enthalten) -> Vereinigung
von beiden textbasierten Varianten
EXPLAIN PLAN – Befehl (1)
• Ausführung in der SQL*Plus Konsole
• Ausführungsplan der SQL – Anweisung wird in
•
•
•
plan_table gespeichert (muss erst angelegt werden)
Anweisung wird nicht ausgeführt!
Informationen können nach Ausführung ausgewertet
werden
Nachteil: manuelle Extrahierung der Informationen
EXPLAIN PLAN
SET statement_id = ‘<Bezeichner>‘
FOR
<SQL – Statement>
EXPLAIN PLAN – Befehl (2)
AUTOTRACE – Funktion (1)
• Ausführungsplan sowie Statistiken werden in lesbarer
•
•
Form an die Resultatmenge der SQL–Anweisung
angehangen
Nutzung durch Einschalten der Funktionalität mittels des
folgenden Befehls: SET AUTOTRACE ON;
Nachteil: SQL–Query wird immer erst ausgeführt, daher
hoher Zeitaufwand bei mehrfacher Nutzung der Query
AUTOTRACE – Funktion (2)
SQL – Analyze (1)
• grafische Darstellung von Ausführungsplänen
• spezielle Wizards und Assistenten stehen zur
•
Analyse von einzelnen SQL–Anweisungen zur
Verfügung
Auswertungen werden in grafischer und relativ
übersichtlicher Form dargestellt (z.B. mittels
Diagrammen, Tabellen)
SQL – Analyze (2)
Eigenschaften (1)
• TopSQL Funktionalität (suche nach SQL-Anweisung,
•
•
•
•
•
welche die meisten Ressourcen benötigen)
Zugriff auf eine SQL-Historie, in der Informationen über
vergangene Anweisungen gespeichert wurden
Ausführen von SQL-Anweisungen mit unterschiedlichen
Optimierungen, Angabe von Ausführungsplänen sowie
Statistiken dazu
grafische Anzeige von Ausführungen und Erklärungen zu
den einzelnen Schritten
Überprüfung von SQL-Anweisungen auf syntaktische
Korrektheit, zeigen von möglichen Fehlerquellen
Präsentiert relevante Objekteigenschaften, um Probleme
zu erkennen / zu beheben und so die Performance der
Anweisung zu beeinflussen
Eigenschaften (2)
• Zugang zu Initialisierungsparametern, haben direkten
•
•
•
•
Einfluss auf die Performance
Hinzufügen von Optimizer-Hints (s. Vortrag Gruppe 8)
mit Hilfe des Hint Wizards
Speicherung von Ausführungsplänen und Statistiken von
SQL-Anweisungen im Repository
Vorschläge zu Indexnutzung um die Performance zu
erhöhen
Virtuelle Indexerstellung (Testen von Indexen ohne diese
zu erstellen)
Interpretation
• gelesen wird ein Ausführungsplan von rechts
•
nach links (im Operatorbaum gesprochen von
den Blättern zur Wurzel)
d.h. es werden einfache Operationen zuerst
ausgeführt und die resultierenden Mengen mit
mächtigeren Operationen verknüpft  daraus
entsteht dann die Resultatmenge der SQL Query
 Bericht von SQL - Analyze
Optimieren (1)
• Optimierung manuell setzen mittels alter session
set optimizer_goal:
– optimizer_goal=rule: Einsatz von RBO (nicht
mehr in 10g – hier nur noch CBO, Erstellung von
Statistiken on-the-fly)
– optimizer_goal=choose: autom. Wahl von RBO
bzw. CBO (wenn Statistiken verfügbar)
– optimizer_goal=all_rows: Optimierung bzgl.
Bereitstellung des Gesamtergebnisses
– optimizer_goal=first_rows: Optimierung bzgl.
Bereitstellung des ersten Tupels (z.B. für Statistiken –
OLAP/Data Warehouses/…)
Beispiel (1)
Beispiel (2)
Beispiel (3)
• Durch Setzen des Indexes auf die Spalte
•
F_ABT_ID lässt sich die Kosten bei Ausführung
der SQL–Query um 44% verringern
bei großen kostenaufwendigeren Querys ist dies
eine enorme Performancesteigerung
ENDE
Noch Fragen???