Ich liebe es, wenn ein Plan funktioniert Der Ausführungsplan Thomas Klughardt Senior Presales Consultant 16.11.2011
Quest Software 60 Büros 3 HQs Nord-/ Mittel-/ Südamerika Europa Asien / Pazifik 3600+ Mitarbeiter Sales/Marketing R&D Support 100,000+ Kunden 178 Länder alle Branchen Global bis SMB 1
Ich liebe es wenn ein Plan funktioniert. 2
Warum passt das? Pläne basieren auf Modellen Modelle spiegeln die Realität (annähernd) wieder. Oft klappt es, ab und zu nicht Am Ende wird doch (meist) alles gut. Query Optimizer (CBO) arbeitet mit Statistiken Irgendwann kommen die Daten schon (meistens). 3
Abarbeitung eines Statements Vorgaben kommen vom Anwender (SQL) Statistiken sind bekannt und sind möglichst nah an den tatsächlichen Daten Kardinalitäten Verteilung Plan wird gebaut und ausgeführt Erst dann wird bekannt, ob der Plan gut war. 4
Wie wird ein Ausführungsplan erzeugt? Und Wo sieht man an ihn? Rule Based Optimizer Cost Based Optimizer Statistiken Kosten Explain plan for <Statement> vs. V$SQL_PLAN
Query Optimizer Baut Ausführungsplan für Statement Lädt das Statement in Shared Pool (nur bei hard parses) Syntaxprüfung Semantikprüfung Query Transformation (äquivalente kleinere SQLs) Wenn query_rewrite = true Optimierung Versucht besten Plan zu finden, um an Daten zu kommen Executable Tatsächlich ausführbare Abarbeitung Ausführungsplan wird ab dann gecached Zu aufwändig, um ihn jedes Mal zu bauen 6
Rule Based Optimizer (RBO) 15 Regeln für den Datenzugriff Zugriff über Row ID Zugriff über Index Full Table Scan Inzwischen obsolet, wird seit 10g nicht weiterentwickelt Kann neue Datenbankfeatures nicht nutzen 7
Cost Based Optimizer (CBO) Nutzt Statistiken, um besten Abarbeitungsweg zu finden Entscheidungen sind situationsabhängig Unheimlich komplex Mit Abstand das komplexeste Programm in einer Oracle Datenbank Ausführungsplan schwer vorherzusagen Je nach Komplexität des Statements 8
Statistiken Akkurate Statistiken sind essentiell für den CBO Statistiken sollten aktuell sein dbms_stats.gather_<table schema system>_stats Nicht ANALYZE TABLE (veraltet) Aber: Statistiken nehmen ist ein Change 9
Kosten Entscheidungsgrundlage für Cost Based Optimizer IO Kosten dominieren hier Inzwischen auch CPU Kosten berücksichtigt 10
explain plan for <Statement> vs. V$SQL_PLAN explain plan for <Statement> erzeugt den Plan Braucht Statement nicht auszuführen Im aktuellen Sessionkontext Vorsicht, nicht unbedingt wie in der Anwendung Über V$SQL_PLAN bekommt man den Plan aus dem Cache Der Ausführungsplan für ein Statement wird beim Ausführen gecached Das Statement wurde dort im richtigen Kontext geparst Keine falschen Optimierungseinstellungen für Session Das Statement muss nicht noch einmal geparst werden 11
explain plan for <Statement> Anlegen der Plantabelle @$ORACLE_HOME/RDBMS/ADMIN/UTLXPLAN.SQL Anzeigen des Statements SELECT lpad(' ',level-1) operation ' ' options ' ' object_name "Plan" FROM plan_table CONNECT BY prior id = parent_id AND prior statement_id = statement_id START WITH id = 0 AND statement_id = '&1' ORDER BY id; 12
Explain Plan SELECT STATEMENT FILTER NESTED LOOPS OUTER HASH JOIN INDEX FULL SCAN I_USER2 INDEX RANGE SCAN I_OBJ5 TABLE ACCESS CLUSTER TAB$ INDEX UNIQUE SCAN I_OBJ# NESTED LOOPS INDEX FULL SCAN I_USER2 INDEX RANGE SCAN I_OBJ4 13
Der Ausführungsplan 14
Was erzählt uns der Ausführungsplan? Reihenfolge Zugriffe Join Algorithmen
Reihenfolge Sinnvollerweise siebt man frühzeitig Daten aus Wenn möglich mit kleinen Tabellen anfangen Möglichst früh selektieren 16
Zugriffe Datensätze liegen in Blöcken Werden über RowID angesprochen Im einfachsten Fall dursucht man alle Datenblöcke nach den Daten Full Table Scan Zusätzlich gibt es für schnelleren Zugriff Indizes Index Access Indexeintrag zeigt über RowID auf Datensatz Manchmal stehen alle Daten, die man braucht im Index 17
Zugriffe Tabelle und Index 18
Full Table Scan Der einfachste Weg, an Daten zu kommen Liest die Tabelle von vorne nach hinten Waitevent: db_file_scattered_read Jeder Block wird einmal gelesen I/O hängt von der Größe der Tabelle ab Mehrere Blöcke können auf einmal gelesen werden multiblock read 19
Full Table Scan 20
Index Scans Stehen alle Daten in den Indexblöcken, oder müssen wir auch Datenblöcke lesen? Index Unique Scan Index Range Scan Index Full Scan Index Fast Full Scan Index Skip Scan (seit 9i) 21
Index Unique Scan Scannt eindeutigen Index Man muss die führende Spalte des Index nutzen Gibt üblicherweise jeden Wert nur einmal zurück Eindeutigkeit nicht garantiert, kann also unter Umständen mehr als eine Zeile zurückliefern 22
Index Unique Scan 23
Index Range Scan Scannt einen Indexbereich Bei Range Operationen: >, <, <>, >=, <=, between Auch bei non-unique Index möglich 24
Index Range Scan 25
Index Full Scan Scannt kompletten Index Manchmal auch, wenn auf Datenblöcke zugegriffen werden muss Alternative zu Full Table Scan und Sort Nur verfügbar im CBO RBO nimmt dann Full Table Scan Aber Vorsicht, Single Block I/O Nicht parallelisierbar 26
Index Full Scan 27
Index Fast Full Scan Wird nur genutzt, wenn alle Daten im Index sind. Scannt kompletten Index, Ergebnis unsortiert Wie Full Table Scan auf Index Blöcken Parallelisierung und Multiblock I/O möglich (da komplett und unsortiert) 28
Index Full Scan 29
Index Skip Scan (seit 9i); Die Ausnahme Nutzt combined Indizes, wenn die führende Spalte nicht genutzt wird Wie geht das? Wahrscheinlich durch mehrere Abfragen für die führende Spalte, eine pro distinktem Wert. Anzahl der distinkten Werte spielt eine Rolle, also eingeschränkt nutzbar. Schlechter als echter" Index Scan, aber manchmal besser als Full Table Scan. 30
Joins Nested Loop Join Sort Merge Join Hash Join 31
Nested Loop Join Einfaches sortieren Innere Schleife / äußere Schleife Sinnvoll, wenn die Mengen nicht zu groß sind Liefert schnell erste Ergebnisse First_rows Erzeugt relativ viel IO Last 32
Nested Loop Join 33
Sort Merge Join Eingabemengen werden jeweils sortiert Zwischenergebnisse zuerst in PGA, dann in Temp Segmenten Sortierte Mengen werden ineinander gemischt Liefert das komplette Ergebnis 34
Hash Join Hashfunktion ordnet Eingabemenge in Slots Oracle nimmt die kleinere Eingabemenge zuerst Es findet ein Probing mit der zweiten Menge statt Nested Loop Join Die Operationen finden im Speicher statt Eine Art Mischung aus Nested Loop und Sort Merge Join 35
Beispiele von Ausführungsplänen 36
Beispiele von Ausführungsplänen 37
Wie können wir den Ausführungsplan verbessern? Identifizieren schlechter Statements Optimizer Mode Vermeiden offensichtlicher Schwachstellen Tools und Hilfen
Identifizieren schlechter Statements Wann ist ein Statement schlecht? Kriterien Wann ist das Statement in Ordnung? - Kriterien Anwendungsabhängig OLTP Antwortzeit OLAP/Batch I/O, CPU. Memory 39
Identifizieren schlechter Statements Proaktiv: Ausführungspläne Akut: Statements und Pläne aus der SGA SGA Shared Pool / V$SQL Plan Wait Events Oracle Enterprise Manager, Quest Spotlight Historisch, letzte Nacht / Woche OEM Diagnostic Pack (ADDM, AWR, ASH) Statspack Snapshots Quest Performance Analysis 40
Optimizer Mode Wahl des Optimizers RULE CHOOSE Verschiedene Modi (OPTIMIZER_MODE): FIRST_ROWS(_n) ALL_ROWS 41
Vermeiden offensichtlicher Schwachstellen Kartesische Produkte SQL Howto Full Table Scans Fehlende Indizes? Anwendungsentwickler Caching möglich? Materialized Views, Client oder Server Side Result Cache 42
Tools und Hilfen Optimierung Oracle Tuning Pack Tuning Advisor Quest SQL Optimizer 43
Wo finden Sie mich? Quest Software Stand Dritte Etage Gegenüber des Oracle Standes Zwischen Raum Tokyo und den Toiletten Vor dem Restaurant thomas.klughardt@quest.com 44
Fragen? thomas.klughardt@quest.com 45