SQL - Ausführungspläne Matthias Jauernig (03INB), Michael Lahl (03IND) 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) 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) 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???