Datenbanktechnik
Vorlesung Datenbanktechnik, 4. Semester Studiengang Wirtschaftsinformatik
Vorlesung Datenbanktechnik, 4. Semester Studiengang Wirtschaftsinformatik
-
- 1 / 65
-
Cartes-fiches
Berechungsformel: lineare Suche
AnzBZ = b/2 (wenn s = 1, andernfalls AnzBZ = b)
AnzBZ: Anzahl Blockzugriffe
b: Anzahl Blöcke
s: Selektionskardinalität
Berechnungsformel: binäres Suchen
AnzBZ = LOG 2 (b) + (s/bfr) - 1 (wenn nur ein eniziges Schlüsselattribut gesucht: AnzBZ = LOG 2 (b) )
AnzBZ: Anzahl Blockzugriffe
b: Anzahl Blöcke
s: Selektionskardinalität
bfr: Blockfaktor
Berechnungsformel: Index-Suche
AnzBZ = x + s
AnzBZ: Anzahl Blockzugriffe
x: Anzahl Ebenen
s: Selektionskardinalität, ist 1 wenn Schlüsselattribut
Berechnungsformel: Index-Suche bei Vergleichsbedingungen
AnzBZ = x + (bi1 / 2) + (r / 2)
AnzBZ: Anzahl Blockzugriffe
bi1: Anzahl Indexblöcke auf unterster Ebene
r: Anzahl Datensätze
Nested Loop Join
- falls keine Ordnung vorhanden
- jeden Satz der einen Relation mit jedem der anderen Relation vergleichen
AnzBZ = Anzahl Blöcke Relation A * Anzahl Blöcke Relation B + Anzahl Blöcke Relation A
Single Loop Join
- eines der beiden Attribute hat eine Zugriffsstruktur (Index)
- lese eine Relation sequentiell (Single Loop) ein und ermittle über Zugriffstruktur der anderen die Lösungssätze
AnzBZ = AnzBZ Relation A + (AnzSuchanfragen erfolgreich Relation B * (x + s)) + (AnzSuchanfragen erfolglos B * x)
hierbei gilt: eine Suchanfrage je Datensatz der Relation A!
Sort Merge Join
- falls beide Join-Attribute als physisches Sortierkriterium existieren
- parallel beide Relationen Blöcke einlesen und Sätze vergleichen
AnzBZ = AnzBZ Relation A + AnzBZ Relation B
Oder über Index-Blöcke:
AnzBZ = bi1 Relation A + bi1 Relation B + 2 * erfolgreiche Blockzugriff Relation B
Optimierung der Auswertungsreihenfolge - der Optimizer
- bestimmt einen effizienten Ausführungsplan
- meist nicht optimal, da Bestimmung zu teuer
Optimierung der Auswertungsreihenfolge - der Datenbank-Prozessor
- Ausfühung compilierter Code
- bestimmt effiziente Knotenauswertung
Optimierung der Auswertungsreihenfolge
- aus jedem Select-Statetement entsteht 1 Anfragebraum, d.h. geschachtelte Statements getrennt optimiert (innere zuerst)
- Relationen als Blätter
- Operationen als innere Knoten
Regeln für die Optimierung des Anfragebaumes
- frühzeitig Selektionen ausführen (WHERE-Bedingungen)
- Selektionen im Baum möglichst weit nach unten
- dadurch weniger Sätze
- restriktive Selektionen/Joins zuerst ausführen lassen
- Blätter bzw. Teilbäume umstellen
- Selektionen/Joins weiter nach links unten bringen
- kartesische Produkte durch Joins beseitigen
- führzeitig Projektionen ausführen
- Projektionen möglichst weit nach unten
Anfrageoptimierung in DB2
- System-R (70er Jahre): einzelne Operationen Kosten schätzen
- Starbust (84-92): Weiterenwicklung System-R; Graph manipulieren
- System-RX (00-05): Weiterentwicklung System-R & Starbust; realtionale Speicherung und XML
- System-S (04-09): völlig neues Paradigma "Stream Computing"; Echtzeitanalyse
Kostenbasierter Optimierer
- Aufwand für Beantwortung einer SQL-Anfrage
- künstiliche Einheit "timerons"
- Kosten auf Statistiken berechnet
Warum Transaktionsverarbeitung?
- Mehrbenutzerkontrolle (concurrency control)
- Wiederherstellung der Datenbank im Fehlerfall (Recovery)
Was ist eine Transaktion?
- logische Einheit der DB-Verarbeitung
- gekennzeichnet durch begin transaction und end transaction
- umfasst eine oder mehrere DB-Zugriffsoperationen
- wird ganz oder gar nicht ausgeführt
Das Lost Update Problem
Veränderter Wert eines Prozesse geht verloren, da dieser noch nicht wieder zurückgeschrieben war und Prozess 2 mit dem alten Wert gerechnet hat.
Das Dirty Read Problem
Ein Prozess arbeitet mit einem geänderten Wert, der aber dann durch den Prozesse, der die Änderung verursacht hat, wieder rückgängi gemacht wird.
Das Incorrect Summary Problem
Ein Prozess bildet Summe, bevor einer der Summanden durch anderen Prozess geändert wurde.
Das Unrepeatable Read Problem
Prozess 1 liest Flag, bekommt Signal "OK." Prozess 2 setzt Flag auf "NOK", Prozess 1 liest Flag erneut und erhält jetzt "NOK" -> Abbruch
Transaktionszustände
- beginn transaction
- read/write
- commit
- erfolgreich
- permanente Speicherung
- abort/rollback
- fehlerhafte Verarbeitung
- alles Rückgängig anhand Systemlog
Das ACID-Prinzip
Atomicity: ganz oder gar nicht
Consistency: konsistente Zustände
Isolation: als ob keine anderen Transaktionen
Durability: dauerhafte Speicherung
Schedule
= Ausführungsplan
Reihenfolge der DB-Operationen von parallel (=interleaved) ablaufenden Transaktionen
Die Recovery-Grundsätze
- Rollback nur, wenn Transaktion ohne Commit im System Log
- vor Commit werden Werte vom HS in System Log geschrieben
Wann ist ein Schedule recoveryfähig?
Wenn keine Leseabhängigkeiten bestehen, d.h. Prozess 1 schreibt und Prozess 2 liest denselben Wert => commit/abort in gleicher Reihenfolge
Das Zwei-Phasen-Sperr-Protokoll
- zur Mehrbenutzerkontrolle benötigt
- ermöglicht Serialisieren durch Sperren von DB-Objekten
- Locks
- shared lock (read_lock)
- exlusive lock (write_lock)
- no lock (unlock)
- Phasen
- Wachstumsphase (alle lock-Operationen)
- Schrumpfungsphase (alle unlock-Operationen)
Deadlock
- zwei oder mehr Transaktionen warten aufeinander
- Lösung
- Wait-die-Verfahren: ältere Transaktion wartet, jüngere stribt
- Wound-wait-Verfahren: ältere Transation beendet, jüngere wartet
