Ich liebe es, wenn ein Plan funktioniert

Größe: px

Ab Seite anzeigen:

Download "Ich liebe es, wenn ein Plan funktioniert"

Dirk Maurer
vor 5 Jahren
Abrufe

1 Ich liebe es, wenn ein Plan funktioniert Der Ausführungsplan Thomas Klughardt Senior Presales Consultant

2 Quest Software 60 Büros 3 HQs Nord-/ Mittel-/ Südamerika Europa Asien / Pazifik Mitarbeiter Sales/Marketing R&D Support 100,000+ Kunden 178 Länder alle Branchen Global bis SMB 1

3 Ich liebe es wenn ein Plan funktioniert. 2

4 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

5 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

6 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

7 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

8 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

9 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

10 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

11 Kosten Entscheidungsgrundlage für Cost Based Optimizer IO Kosten dominieren hier Inzwischen auch CPU Kosten berücksichtigt 10

12 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

13 explain plan for <Statement> Anlegen der 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

14 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

15 Der Ausführungsplan 14

16 Was erzählt uns der Ausführungsplan? Reihenfolge Zugriffe Join Algorithmen

17 Reihenfolge Sinnvollerweise siebt man frühzeitig Daten aus Wenn möglich mit kleinen Tabellen anfangen Möglichst früh selektieren 16

18 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

19 Zugriffe Tabelle und Index 18

20 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

21 Full Table Scan 20

22 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

23 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

24 Index Unique Scan 23

25 Index Range Scan Scannt einen Indexbereich Bei Range Operationen: >, <, <>, >=, <=, between Auch bei non-unique Index möglich 24

26 Index Range Scan 25

27 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

28 Index Full Scan 27

29 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

30 Index Full Scan 29

31 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

32 Joins Nested Loop Join Sort Merge Join Hash Join 31

33 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

34 Nested Loop Join 33

35 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

36 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

37 Beispiele von Ausführungsplänen 36

38 Beispiele von Ausführungsplänen 37

39 Wie können wir den Ausführungsplan verbessern? Identifizieren schlechter Statements Optimizer Mode Vermeiden offensichtlicher Schwachstellen Tools und Hilfen

40 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

41 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

42 Optimizer Mode Wahl des Optimizers RULE CHOOSE Verschiedene Modi (OPTIMIZER_MODE): FIRST_ROWS(_n) ALL_ROWS 41

43 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

44 Tools und Hilfen Optimierung Oracle Tuning Pack Tuning Advisor Quest SQL Optimizer 43

45 Wo finden Sie mich? Quest Software Stand Dritte Etage Gegenüber des Oracle Standes Zwischen Raum Tokyo und den Toiletten Vor dem Restaurant 44

46 Fragen? 45

Ähnliche Dokumente

Ganzheitliche Optimierung

Ganzheitliche Optimierung Tuning im Anwendungskontext Thomas Klughardt Senior Systems Consultant Nützliche Tools und Lösungen Aber keine Plattform Lösungsbereiche DATENBANK MANAGEMENT WINDOWS SERVER MANAGEMENT