DB-Anfrageverarbeitung Überblick (1) Transaktionsprogramme Mengenorientierte DB-Schnittstelle SQL, QBE... Satzorientierte DB-Schnittstelle FID EXT/STORE... Interne Satz-Schnittstelle Speichere Satz (in B*-Baum),... DB-Puffer-Schnittstelle Stelle Seite bereit / gib Seite frei Dateischnittstelle Lies/Schreibe Block Geräteschnittstelle Kanalprogramme Logische Datenstrukturen Logische Zugriffspfade Speicherungsstrukturen Seitenzuordnungsstrukturen Speicherzuordnungsstrukturen Externspeichermedien ns Zugriffslücke ms 1 DB-Anfrageverarbeitung Überblick (2) splan Code-Generierung Interpretation in Programmierumgebung 2
Behandlung von DB-Anweisungen Verarbeitungsschritte zur Auswertung von DB-Anweisungen: 1. Lexikalische und syntaktische Analyse - Überprüfung auf korrekte Syntax (Parsing) - Erstellung eines s (AG) als Bezugsstruktur für die nachfolgenden sschritte 2. Semantische Analyse - Feststellung der Existenz und Gültigkeit der referenzierten Tabellen, Sichten und Attribute - Einsetzen der Sichtdefinitionen in den AG - Ersetzen der externen durch interne amen (amensauflösung) - Konversion vom externen Format in interne Darstellung 3 Behandlung von DB-Anweisungen (2) splan splan Code- Interpretation Generierung in Programmierumgebung Code- Interpretation Generierung in Programmierumgebung Verarbeitungsschritte zur Auswertung von DB-Anweisungen (Forts.) 3. Zugriffs- und Integritätskontrolle - sollen aus Leistungsgründen, soweit möglich, schon zur szeit erfolgen - Zugriffskontrolle erfordert bei Wertabhängigkeit Generierung von Laufzeitaktionen - Durchführung einfacher Integritätskontrollen (Kontrolle von Formaten und Konversion von Datentypen); Generierung von Laufzeitaktionen für komplexere Kontrollen 4. und - dienen der effektiveren und frühzeitigen Fehlererkennung - Überführung des AG in eine ormalform (Beispielsweise konjunktive/disjunktive ormalformen der WHERE-Klauseln) - Elimination von Redundanzen im AG 4
Behandlung von DB-Anweisungen (3) splan Code- Interpretation Generierung Verarbeitungsschritte zur Auswertung von DB- Anweisungen (Forts.) 5. Restrukturierung und Transformation - Restrukturierung zielt auf globale Verbesserung des AG ab; bei der Transformation werden ausführbare Operationen eingesetzt - Anwendung von heuristischen Regeln (algebraische ) zur Restrukturierung des AG - Transformation führt Ersetzung und ggf. Zusammenfassen der logischen Operatoren durch Planoperatoren durch (nichtalgebraische ): Meist sind mehrere Planoperatoren als Implementierung eines logischen Operators verfügbar - Bestimmung alternativer Zugriffspläne (nicht-algebraische ): Meist sind viele sreihenfolgen oder Zugriffspfade auswählbar - Bewertung der Kosten und Auswahl des günstigsten splanes Schritte 4 + 5 werden als Anfrageoptimierung zusammengefasst! in Programmierumgebung 5 Behandlung von DB-Anweisungen (4) Verarbeitungsschritte zur Auswertung von DB- Anweisungen (Forts.) 6. Code-Generierung - Generierung eines zugeschnittenen Programms für die vorgegebene (SQL-) Anweisung - Erzeugung eines ausführbaren Zugriffsmoduls - Verwaltung der Zugriffsmodule in einer DBVS-Bibliothek splan Code- Interpretation Generierung in Programmierumgebung 6
DB-Anfrageverarbeitung Kostenaspekte Laufzeit Keine Vorbereitung splan Code-Generierung Interpretation in Programmierumgebung szeit Laufzeit Maximale Vorbereitung 7 Auswertung von DB-Anweisungen Auswertungstechnik: Spektrum von Verfahren mit folgenden Eckpunkten Maximale Vorbereitung - Für eine DB-Anweisung wird ein zugeschnittenes Programm (Zugriffsmodul) zur szeit erzeugt - Zur einer DB-Anweisung (Laufzeit) wird das Zugriffsmodul geladen und abgewickelt; dabei wird durch Aufrufe des DBVS (genauer: des Zugriffssystems) das Ergebnis abgeleitet Keine Vorbereitung - typisch für Call-Schnittstellen und dynamisches (eingebettetes) SQL - Allgemeines Programm (Interpreter) akzeptiert DB-Anweisungen als Eingabe und erzeugt durch Aufrufe des Zugriffssystems das Ergebnis 8
und splan Beispiel SQL-Anweisung SELECT FROM WHERE P.ame, P.Beruf, J.Pname Pers P, Abt A, Proj J A.Ein > 1000000 AD J.Ort = KL AD A.Anr = P.Anr AD A.Anr = J.Anr; Zugehöriger (nach algebraischer ) π ame, Beruf, Pame Anr, ame, Beruf π Pers π σ Abt Anr Ein > 1 M π σ Proj Anr, Pame Ort = KL 9 und splan Beispiel (Forts.) Ausschnitt aus einem möglichen splan... JOI Method: Sort-Merge Pred: A.Anr = P.Anr Inner: Outer: SORT Cols: Input: Anr GET Table: Pers Cols: ame, Beruf,.. Input: ACCESS Table: Abt Cols: Anr Pred: Ein > 1 M ACCESS Table: I (Pers(Anr)) Cols: TID, Anr Pred: 10
Anfrageoptimierung Von der Anfrage (Was?) zur Auswertung (Wie?) Ziel: kostengünstiger Auswertungsweg sarten Regelbasiert (algebraische ) Kostenbasiert (Kostenmodell erforderlich, höhere Genauigkeit) Einsatz einer großen Anzahl von Techniken und Strategien logische Transformation von Anfragen Auswahl von Zugriffspfaden optimierte Speicherung von Daten auf Externspeichern Probleme genaue ist im allgemeinen nicht berechenbar Fehlen von genauer statistischer Information breiter Einsatz von Heuristiken (Daumenregeln) sziel Antwortzeitminimierung: Minimierung der Ressourcennutzung für gegebenen Output Durchsatzmaximierung: Maximierung des Outputs bei gegebenen Ressourcen 11 Bewertung von splänen Kostenbasierte basiert auf zwei im Allgemeinen falschen Annahmen 1. Alle Datenelemente und Attributwerte sind gleichverteilt 2. Die Werte und alle Attribute sind stochastisch unabhängig Lösung? Verbesserung der Statistiken/Heuristiken (Histogramme)? Berechnung von noch mehr splänen? Obwohl Kostenabschätzungen meistens ungenau und/oder falsch sind 12
Kostenmodell Berechnungsgrundlagen (1) Optimierer erstellt Kostenvoranschlag für jeden splan (möglicher Lösungsweg) Gewichtete Kostenformel: C = #physischer Seitenzugriffe + W (#Aufrufe des Zugriffssystems) gewichtetes Maß für E/A- und CPU-Auslastung W ist das Verhältnis des Aufwandes für einen ZS-Aufruf zu einem Seitenzugriff Ziel der Gewichtung: Minimierung der Kosten in Abhängigkeit des Systemzustandes System "I/O-bound": kleines W #Instr. pro ZS Aufruf W I O = ------------------------------------------------------------------------------------------------------------------ #Instr.pro E A + Zugriffszeit MIPS-Rate System "CPU-bound": relativ großes W W I O #Instr.pro ZS Aufruf W CPU = ------------------------------------------------------------- W 1000 #Instr. pro E A CPU = ----------- = 0, 4 2500 1000 I. = ------------------------------------------------------------------------- 2500 I. + 12 msec 10 7 = 0, 008 I./sec 13 Kostenmodell Berechnungsgrundlagen (2) statistische Größen für Segmente: M S Anzahl der Datenseiten des Segmentes S L S Anzahl der leeren Seiten in S statistische Größen für Relationen: R Anzahl der Tupel der Relation R (Card(R)) T R,S Anzahl der Seiten in S mit Tupeln von R C R Clusterfaktor (Anzahl Tupel pro Seite) statistische Größen pro Index I auf Attributen A einer Relation R: j I Anzahl der Attributwerte/ Schlüsselwerte im Index (=Card (π A (R)) B I Anzahl der Blattseiten (B*-Baum)... Statistiken müssen im DB-Katalog gewartet werden Aktualisierung bei jeder Änderung sehr aufwendig zusätzliche Schreib- und Log- Operationen DB-Katalog wird zum Sperr-Engpass Alternative: Initialisierung der statistischen Werte zum Lade- oder Generierungszeitpunkt von Relationen und Indexstrukturen periodische eubestimmung der Statistiken durch eigenes Kommando/ Dienstprogramm (DB2: RUSTATS) 14
Kostenmodell Berechnungsgrundlagen (3) Selektivitätsfaktor SF Mit Hilfe der statistischen Werte kann der Optimizer jedem Verbundterm im Qualifikationsprädikat einen Selektivitätsfaktor (0 SF 1) zuordnen (erwarteter Anteil an Tupeln, die das Prädikat erfüllen): Card (σ p (R)) = SF(p) Card (R) Selektivitätsfaktor SF bei: 1/j i wenn Index auf A i A i=a i SF = 1/10 sonst 1 / Max(j i, j k) wenn Index auf A i, A k A i = A k SF = 1 / j i wenn Index auf A i 1 / j k wenn Index auf A k 1/10 sonst A i a i (oder A i > a i) SF = (a max - a i) / (a max - a min) wenn Index auf A i und Wert interpolierbar 1 / 3 sonst A i BETWEE a i AD a k SF = (a k-a i) / (a max - a min) wenn Index auf A i und Wert interpolierbar 1 / 4 sonst A i I (a 1, a 2,..., a r) SF = r / j i wenn Index auf A i und SF < 0.5 1 / 2 sonst 15 Kostenmodell Berechnungsgrundlagen (4) Berechnung von Ausdrücken SF (p(a) p(b)) = SF (p(a)) SF (p(b)) SF (p(a) p(b)) = SF (p(a)) + SF (p(b)) - SF (p(a)) SF (p(b)) SF ( p(a)) = 1 - SF (p(a)) Join-Selektivitätsfaktor (JSF) Card (R S) = JSF Card(R) Card(S) bei (:1)-Joins (verlustfrei): Card (R S) = Max(Card(R), Card(S)) 16
Beispiel: Einfache Anfrage Vorhandene Zugriffspfade Relationen-Scan im Segment von PERS I PERS (BERUF) I PERS (GEHALT) SELECT AME, GEHALT FROM PERS WHERE BERUF = PROGRAMMIERER AD GEHALT 100.000 Statistische Kennwerte Der Optimizer findet folgende Parameter im DB-Katalog: = Anzahl der Tupel in Relation PERS C = durchschnittliche Anzahl von PERS-Tupeln pro Seite j i = Index-Kardinalität (Anzahl der Attributwerte für A i )... + Information über Clusterbildung Annahmen Jeder 10. Programmierer hat ein Gehalt > 100 K Jeder 2. Angestellte mit Gehalt > 100 K ist Programmierer 17 Methode 1: Scan über I PERS (BERUF) OPE SCA auf I PERS (BERUF) bei BERUF = PROGRAMMIERER FETCH EXT WHERE GEHALT 100.000; CLOSE SCA wenn BERUF PROGRAMMIERER Kosten: Clusterbildung auf I PERS (BERUF) K 3 + ------------------------ + w --------------------------- C j BERUF 10 j BERUF keine Clusterbildung K 3 + ---------------- + w --------------------------- j B E R U F 10 j B E R U F Ann: Jeder 10. Programmierer hat ein Gehalt > 100 K 18
Methode 2: Scan über I PERS (GEHALT) OPE SCA auf I PERS (GEHALT) bei GEHALT 100.000 FETCH EXT WHERE BERUF = PROGRAMMIERER ; CLOSE SCA wenn EOT Kosten: Clusterbildung auf I PERS (GEHALT) K 3 + 3 ---------- + C w --------- 3 2 keine Clusterbildung K 3 + --- + w --------- 3 3 2 Ann: Jeder 2. Angestellte mit Gehalt 100 K ist Programmierer 19 vs. Interpretation (1) Laufzeit Keine Vorbereitung splan Code-Generierung Interpretation in Programmierumgebung szeit Laufzeit Maximale Vorbereitung 20
vs. Interpretation (2) Binden Beispiel - AP: SELECT Pnr, ame, Gehalt FROM Pers WHERE Beruf = Programmierer - DB-Katalog - SYSREL: Tabellenbeschreibungen: Pers,... - SYSATTR: Attributbeschreibungen: Pnr, ame, Gehalt,... - SYSIDEX: I Pers (Beruf),... - SYSAUTH: utzungsrechte - SYSIT/RULES: Integritätsbedingungen, Zusicherungen,... 21 vs. Interpretation (3) Bindezeitpunkt szeit (ÜZ) skosten: unerheblich für Antwortzeit (AZ) Zugriffe (zur LZ): effizient datenabhängig! AP Invalidierung durch Schemaänderungen Ausgleich gesucht! Interpretation: erheblich für AZ Zugriffe (zur LZ): teuer Laufzeit (LZ) datenunabhängig! 22
vs. Interpretation (4) Bindezeitpunkt (Forts.) Macht die für die Abwicklung einer DB-Anweisung erforderlichen Operationen von DB-Schema abhängig Maximale Vorbereitung einer DB-Anweisung - aufwendige und Erstellung eines Zugriffsmoduls - maximale Auswirkungen von Schemaänderungen, welche die DB-Anweisung betreffen - Schemaänderungen nach der werden nicht berücksichtigt (neue Zugriffspfade, geänderte Statistiken etc.) - Invalidierung des Zugriffsmoduls und erneute Erstellung Interpretation einer DB-Anweisung - Interpreter wertet Anweisung (als Zeichenfolge) zur Laufzeit aus - aktueller DB-Zustand wird automatisch berücksichtigt - sehr hohe skosten bei Programmschleifen sowie durch häufige Katalogzugriffe - interessant vor allem für Ad-hoc-Anfragen bzw. dynamisches SQL 23 vs. Interpretation (5) Kosten Interpretation Gesamtkosten Zugriffsmodulerstellung #Satzzugriffe 24
Zusammenfassung Anfrageverarbeitung Kostenmodell Minimierung der Kosten in Abhängigkeit des Systemzustandes Problem: Aktualisierung der statistischen Kenngrößen Anfrageoptimierung: Kernproblem der mengenorientierter DB-Sprachen Fatale Annahmen - Gleichverteilung der Attributwerte - Unabhängigkeit der Attribute Kostenvoranschläge für spläne - CPU-Zeit und E/A-Aufwand - Anzahl der achrichten und zu übertragende Datenvolumina (im verteilten Fall) Gute Heuristiken zur Auswahl von splänen sehr wichtig 25