Vorlesung Informationssysteme 5. Datenbank

Vorlesung Informationssysteme
5. Datenbank-Technologie
Wintersemester 2016/2017;
Mo, 8:00-9:45, CAP3, HS2; Di, 16:15-17:45, OS40, N.-Gansel-HS
30. 1. 2017
Prof. Dr. Bernhard Thalheim
Information Systems Engineering Group
Computer Science Institute
Kiel University, Germany
Wiederholung: DBMS Architecture
Presentation
system
(playout
(story))
5.
Technologie
30. 1. 2017
B. Thalheim
Input-output
processor
Authority
control
Parser
Pre-compiler
?6
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
DBMS
Communication subsystem
Topic
Application system
(workflow
(functionality))
Compiler
-
Update
processor
Query
processor
Optimizer
Access plan
generation
Code generation
Integrity
control and
enforcement
Distribution management
Recovery
Synchronization
Transaction manager
of parallel
management
access
Scheduler
DBS =
Storage management
DBMS +
{ DB }
Data manager
6?
6
?
Buffer manager
6
Supporting
Data
systems
Log
(graphical book - dictionary
etc. )
?
Database
6?
Operating
system
Wiederholung: 5-Schichten-Modell eines
DBMS
(1)
(2)
(3)
(4)
(5)
5.
Technologie
30. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Ebene derBenutzersprache
Benutzerschnittstelle
Ebene der Anfrageverarbeitung
Ebene der Zugriffstrukturen und Code-Erzeugung
Ebene der Synchronisation paralleler Zugriffe
Ebene der Speicherverwaltung
Geräteschnittstelle
Darauf aufbauend hat das System verschiedene Schnittstelle
Mengen-Schnittstelle
1
↔
select, insert, delete, modify
2
↔
Tupel-Schnittstelle
fetch, store, erase, update
Record-Schnittstelle
3
↔
retrieve, add, change, dispose, change
Seiten-Schnittstelle
4
↔
read, write
2
5
views, Relationen
3
Cursor, Tupel
4
(Index-)Records
Seiten, Segmente
Transaktionsverwaltung und
Integritätskontrolle
5.
Technologie
30. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Transaktionen: einige Vorüberlegungen
5.
Technologie
30. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
- nicht nur einzelne Handlungen, sondern auch (formale)
Handlungsfolgen
- semantische Bedingungen (als statische Gesichtspunkte) auch als
dynamische Gesichtspunkte:
- Aufzählungen nur derart ändern, daß anschließend die semantischen
Bedingungen wieder erfüllt sind
- bei Änderungswünschen bezüglich mehrerer Objekte oder
interrelationalen Bedingungen, neben der eigentlich gewünschten
Änderung auch noch Folgeänderungen notwendig; möglicherweise
werden die Bedingungen zwischenzeitlich verletzt
- Änderungsfolgen als unteilbare Operationen, die entweder gar nicht oder
vollständig ausgeführt werden
- Daten für viele und verschiedenartige Benutzer verfügbar halten: diese
arbeiten im Allgemeinen parallel und möglichst unabhängig
voneinander
Das Transaktionsparadigma
Praktizierte Definition der Transaktion:
Eine Transaktion ist eine Folge von DB-Operationen (DML-Befehlen), welche die Datenbank von einem logisch konsistenten Zustand in einen neuen logisch konsistenten
Zustand überführt. Das DBS gewährleistet für Transaktionen die sogenannten A.C.I.D.Eigenschaften
5.
Technologie
30. 1. 2017
B. Thalheim
A.C.I.D.-Prinzip
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Atomicity: “Alles oder Nichts” (Fehlerisolierung)
Consistency: eine erfolgreiche Transaktion erhält die DB-Konsistenz (Menge der definierten
Integritätsbedingungen)
Isolation: alle Aktionen innerhalb einer Transaktion müssen vor parallel ablaufenden Transaktionen verborgen werden (logischer Einbenutzerbetrieb)
Durability: Überleben von Änderungen erfolgreich beendeter Transaktionen trotz beliebiger (erwarteter) Fehler garantieren (Persistenz).
Das Transaktionsparadigma
Das Transaktionsparadigma befreit den DB-Anwendungsprogrammierer von allen Aspekten des Fehlerfalls (failure transparency) und der Nebenläufigkeit (concurrency transparency). Es erlaubt also eine fehlerfreie Sicht auf die Datenbank im logischen Einbenutzerbetrieb.
Programmierschnittstelle für Transaktionen
- begin of transaction (BOT)
- commit transaction (commit workı̈n SQL)
- rollback transaction (rollback workı̈n SQL)
5.
Technologie
30. 1. 2017
B. Thalheim
Transaktionen
Synchronisation Mögliche Ausgänge einer Transaktion
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
ACID
ACID vereinfacht DB-Anwendungsprogrammierung erheblich
- Fehlertransparenz (failure transparency)
- Transparenz der Nebenläufigkeit (concurrency transparency)
- erlaubt also eine fehlerfreie Sicht auf die Datenbank im
logischen Einbenutzerbetrieb
5.
Technologie
30. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Probleme der praktizierten Definition
Annahme von der Existenz einer DB-Maschine
Komplexe Modelle im Falle von komplexen Integritätsbedingungen und Triggern
Geschachtelte Transaktionen
Transaktionsbeispiel: Debit/Credit
5.
Technologie
30. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Transaktionsbeispiel: Debit/Credit
5.
Technologie
30. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Transaktionsverwaltung
Mechanismen zur Einhaltung der ACID-Eigenschaften
• Synchronisation (Concurrency Control)
• Logging, Recovery, Commit-Behandlung
• Integritätskontrolle
5.
Technologie
30. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Enge Abhängigkeiten untereinander sowie zu anderen Systemfunktionen (Pufferverwaltung, etc.)
Das ACID-Paradigma eignet sich vor allem für relativ kurze Transaktionen, die in den meisten Anwendungen vorherrschen
Transaktionsbeispiel: Debit/Credit
5.
Technologie
30. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
TA’s - parallel und voneinander
unabhängig
muß i.a. durch das Informationssystem selbst durchgesetzt
werden
5.
Technologie
30. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
von den Benutzern wird gegebenenfalls verlangt, dass ihre
Transaktionen einen vorgeschriebenen Aufbau (Protokolle) einhalten
der Scheduler hat dann die Aufgabe, die Anweisungen von parallel auszuführenden Transaktionen in einer geeigneten Reihenfolge anzuordnen
Zwei Randfälle
5.
Technologie
30. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Scheduler kann beliebig TA’s ineinander verschränkt mischen:
- einfache Verwirklichung derart, dass die Anweisungen in der
Reihenfolge angeordnet bleiben, wie sie angefordert werden
- Scheduler im Wesentlichen nur Warteschlange für Anweisungen
- einerseits hohe Parallelität
- andererseits große Unsicherheit über die wechselseitige Beeinflussung
der Transaktionen
Scheduler ordnet TA’s als Ganzes seriell an:
- einfache Verwirklichung derart, dass die Transaktionen in der
Reihenfolge angeordnet werden, wie sie angefordert werden
- Scheduler im Wesentlichen nur Warteschlange für Transaktionen
- einerseits im Wesentlichen keine Parallelität
- andererseits wechselseitige Beeinflussung der Transaktionen
genau vorhersehbar
Korrekte Reihenfolgen und
Serialisierbarkeit
um die Vorteile der beiden Randfälle möglichst gut gleichzeitig
zu erreichen, sollen folgende Reihenfolgen als korrekt (geeignet)
definiert werden:
5.
Technologie
30. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
K1. Sichere Vorhersehbarkeit: eine Reihenfolge, die durch beliebige serielle Anordnung der Transaktionen als Ganzes entsteht, sei korrekt
K2. Erlaubte Parallelität: jede Reihenfolge, deren Auswirkung
(unter den jeweils getroffenen Annahmen) ununterscheidbar
von der Auswirkung einer nach K1 korrekten Reihenfolge ist,
sei ebenfalls korrekt
in Praxis und Theorie:
verschiedene Annahmen und Auswirkungen führen zu verschiedenen Begriffen von Korrektheit bzw. Serialisierbarkeit
Planung
5.
Technologie
30. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Menge von Operatoren (Aktionen):
A
Menge von Objekten:
O
Menge der Anweisungen:
S := A × O
Menge der Transaktionen:
T := {t | t : {1, ..., n} → S, t ist injektiv}
Plan (schedule) zu T:
für eine Menge von Transaktionen
T = {t1 , ..., tk } mit ti = (ti.1 , ..., ti.ni )
Plan ist Funktion
P : {1, ..., n1 + ... + nk } −→
{ i.j |1 ≤ i ≤ k, 1 ≤ j ≤ ni }
mit
- P ist bijektiv
- für alle i, für alle j1 , j2 gilt :
j1 < j2
⇔
P−1 (i.j1 ) < P−1 (i.j2 )
Synchronisation
DBS müssen Mehrbenutzerbetrieb unterstützen
ohne Synchronisation kommt es zu sogenannten
Mehrbenutzer-Anomalien
5.
Technologie
30. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
• Verlorengegangene Änderungen (lost updates)
• Abhängigkeiten von nicht freigegeben Änderungen (dirty
read, dirty overwrite)v
• inkonsistente Analyse (non-repeatable read)
• Phantom-Probleme
Anomalien sind nur durch Änderungen verursacht
Synchronisation erfolgt automatisch durch das DBS
offene Fragen
• Korrektheitskriterium ?
• Realisierung ?
• Leistungsfähigkeit ?
Atomaritätsproblem: Beispiel
5.
Technologie
30. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Verlorengegange Änderung (Lost
Update)
5.
Technologie
30. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Schmutziges Lesen (Dirty Read)
5.
Technologie
30. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Inkonsistente Analyse (Non-repeatable
Read)
5.
Technologie
30. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Phantom-Problem
5.
Technologie
30. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Synchronisation von Transaktionen:
Modellannahmen
Transaktion:
Ein Programm T mit DB-Anweisungen, so daß: Wenn T allein auf einer
5.
Technologie
30. 1. 2017
B. Thalheim
konsistenten DB ausgeführt wird, dann terminiert T (irgendwann) und
hinterläßt die DB in einem konsistenten Zustand. Während der
Transaktionsverarbeitung werden keine Konsistenzgarantien eingehalten.
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Wenn Transaktionen seriell ausgeführt werden, dann bleibt die
Konsistenz der DB erhalten.
DB-Anweisungen lassen sich nachbilden durch READund WRITE-Operationen
Transaktion: BOT, Folge von READ- und WRITE-Anweisungen
auf Objekte, EOT
Die Ablauffolge von Transaktionen mit ihren Operationen kann
durch einen Schedule beschrieben werden:
r1 (x), r2 (x), r3 (y), w1 (x), w3 (y), r1 (y), c1 , r3 (x), w2 (x), a2 , w3 (x), c3 , ...
Beispiel eines seriellen Schedules:
Content
Information
r1 (x), w1 (x), r1 (y), c1 , r3 (y)c3 , r2 (x), w2 (x), c2 , ...
BOT ist implizit, EOT wird durch ci (Commit)
oder ai (Abort / Rollback) dargestellt
Concept
Topic
Transaktion als Schnittstelle
5.
Technologie
30. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Transaktion als Schnittstelle
5.
Technologie
30. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Verhalten von Transaktionen
Syntax: Transaktion T über (S, Σ) als
endliche Folge o1 ; o2 ; o3 ; ...; om von
Basismodifikationsoperationen (insert, delete, update) und
Retrievaloperationen map(filter(join(...), ψ), S)
über (S, Σ).
5.
Technologie
30. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Semantik der Anwendung: Effekt der Anwendung einer TA T auf
S C : transition constraint preserving transformation
{
T(S C ) falls T(S C ) |= Σ
C
T(S ) =
SC
falls T(S C ) ̸|= Σ
Effekt definiert die Granularität der Transaktion
TA’s sind i.a. invariant state transitions
invariant bzgl. der Menge der statischen IC
Potentiell parallele Ausführung von TA’s
T1 , T2 konkurrieren
falss read(T1 ) ∩ write(T2 ) ̸= ∅ oder read(T2 ) ∩ write(T1 ) ̸=
∅
or write(T2 ) ∩ write(T1 ) ̸= ∅ .
5.
Technologie
30. 1. 2017
B. Thalheim
read(Ti ) bzw. write(Ti ) : Lokalisierung der Objekte von Ti
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Parallele Ausführung von TA’s T1 ∥ T2 is korrekt
falls entweder T1 , T2 nicht konkurrieren
oder (T1 ∥T2 )(S C ) ∈≡ { T1 (T2 (S C )), T2 (T1 (S C ))} für jede
SC
Zustandsraum für Transaktionen
Status einer TA Status(TA):
undef (Inaktivität einer TA in der Warteschlange),
5.
Technologie
30. 1. 2017
B. Thalheim
active (TA wird z.Z. ausgeführt),
commit (TA wurde erfolgreich ausgeführt),
ready2commit (TA ist vorbereitet zum Commit),
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
failed (TA wurd nicht erfolgreich ausgeführt),
done (TA wurde beendet)
Content Content(TA):
Folgen der Basisopertionen
als Warteschlange Queue(transaction)von Operationen
Persistenter DB-Raum StableDB
zur Darstellung der DB
Globaler Log-Raum: zur
Aufzeichnung
Log(transaction,action,location)
Global-
Speichermodelle zur DB-Modifikation
Speichertypen primary, nonvolatile memory (secondary und tertiary).
5.
Technologie
30. 1. 2017
B. Thalheim
Anwendung der Modifikation je nach Speichertyp
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Modification in-place: direktes Durchschreiben der Resultate
auf den Speicher (location)
Veränderungen werden mitprotokolliert für Recovery
UNDO: falls TA fail oder abort.
Modification in-private: TA’s mit eigenem lokalem Raum
TA commit: Daten oder lokale Daten werden in Sekundarspeicher geflutet
Shadow modification: mit Schattenseiten zum vorherigem
Zustand der TA-Objekte
TA arbeitet auf Originalseiten
Zustandsdiagramm von TA’s
-
Inactive
Aborted
6
5.
Technologie
30. 1. 2017
B. Thalheim
Failed
BOT
j
EOT
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
6
Committed
6
Run
ICtrue
j
Ready2Commit
Erweiterung um 4 Zustände: Ready2Commit, ICtrue, Failed, Inactive
Basiert auf 6 ASM Transitionsregeln: CreateOwnDB, PrepareMergeDB, MergeOwnDB, FreeOwnDB, ReadOwnDB, WriteOwnDB
TA by modification-in-private
BOT:
Status(Self) = undef
5.
Technologie
30. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Status(Self) := active
Queue(Self) := Content(Self)
CreateOwnDB()
RUN:
Status(Self) = active
IF Queue(Self) ̸= ∅
THEN
CASE Top(Queue(Self)) OF
read(loc): ReadOwnDB(loc)
write(loc,val):
WriteOwnDB(loc,val)
compute(expr,loc):
WriteOwnDB(loc,compute(expr,loc))
ENDCASE
TA by modification-in-private
READY2COMMIT:
Status(Self) = ready2commit
5.
Technologie
30. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
IF OwnDB |= Σ
THEN Status(Self) := ICtrue
ELSE Status(Self) := ICfalse
ENDIF
FAILED:
(Status(Self) = failed ∨ Status(Self) =ICfalse)
Status(Self):= aborted
ABORTED:
Status(Self) = aborted
IF CanReschedule(Self) THEN
Status(Self) := undef
FreeOwnDB()
TA by modification-in-private
ICTRUE:
Status(Self) = ICtrue
5.
Technologie
30. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
PrepareMergeDB()
Status(Self) := committed
COMMITTED:
Status(Self) = committed
MergeOwnDB()
FreeOwnDB()
Status(Self) := done
Program(Self) := undef
TA by modification-in-private
Satz 1. Wenn eine Anwendung der Transaktionen t1 , ..., tk in
dieser Reihenfolge anwendbar ist, dann ist dies auch in der
modification-in-private-Strategie für t1 , ..., tk anwendbar, atomar
und konsistent .
5.
Technologie
30. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Satz 2. Die Dauerhaftigkeit ist garantiert für modification-inprivate.
Satz 3. Die Transaktionsausführung bei der modification-inprivate-Strategie
· mit einem pessimistischen Locking zu Beginn,
· mit einem Abort, wenn die Locks nicht erworben werden
können und
· mit einer Auflösung am Ende
Ξ̆
ist eine konservative Erweiterung der Relation −→ .
Serialisierbarkeit
Ziel der Synchronisation: logischer Einbenutzerbetrieb, d.h. Vermeidung
aller Mehrbenutzeranomalien
Gleichbedeutend mit dem formalen Korrektheitskriterium der
Serialisierbarkeit:
5.
Die parallele Ausführung einer
Technologie
Menge von n Transaktionen ist
30. 1. 2017
B. Thalheim
serialisierbar, wenn es eine serielle
Ausführung derselben Transaktionen
gibt, die den gleichen DB-Zustand
Transaktionen
Synchronisation und die gleichen Ausgabewerte wie
die ursprüngliche Ausführung erzielt.
Recovery
Algorithmik
Hintergrund:
Optimierung
- serielle Ablaufpläne sind korrekt
Realisierung
- jeder Ablaufplan, der denselben
Integrität
Effekt wie ein serieller erzielt,
Indexes
ist akzeptierbar
Denormalisation
Metadata
Content
Information
Concept
Topic
Nachweis der Serialisierbarkeit
Führen von zeitlichen Abhängigkeiten zwischen Transaktionen in einem
Abhängigkeitsgraphen (Konfliktgraphen)
Abhängigkeit (Konflikt) besteht, wenn zwei Transaktionen auf
dasselbe Objekt mit nicht reihenfolgeunabhängigen Operationen zugreifen
5.
Technologie
30. 1. 2017
B. Thalheim
Konfliktarten:
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
- Schreib-/Lese-Konflikt
- Lese-/Schreib-Konflikt
- Schreib-/Schreib-Konflikt
Serialisierbarkeit liegt vor, wenn der Abhängigkeitsgraph keine Zyklen enthält
y Abhängigkeitsgraph beschreibt partielle Ordnung zwischen TA’s,
die sich zu einer vollständigen erweitern läßt (Serialisierungsreihenfolge)
Anomalien im Schreib/Lese-Modell
5.
Technologie
30. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Konsistenzerhaltende Ablaufpläne
5.
Technologie
30. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Die Transaktionen T1 bis T3 müssen so synchronisiert werden,
daß der resultierende DB-Zustand gleich dem ist, der bei der seriellen
Ausführung in einer der folgenden Sequenzen zustande gekommen
wäre.
bei n Transaktionen bestehen n! mögliche serielle Schedules
T1T2T3 T1T3T2 T2T1T3 T2T3T1 T3T1T2 T3T2T1
Sinnvolle Einschränkungen:
- Reihenfolgeerhaltende Serialisierbarkeit: jede Transaktion sollte
wenigstens alle Änderungen sehen, die bei ihrem Start (BOT)
bereits beendet waren
- Chronologieerhaltende Serialisierbarkeit: jede Transaktion sollte
stets die aktuellste Objektversion sehen
Zweiphasen-Sperrprotokolle (2 Phase
Locking)
5.
Technologie
30. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Einhaltung folgender Regeln gewährleistet Serialisierbarkeit:
1. vor jedem Objektzugriff muß Sperre mit
ausreichendem Modus angefordert werden
2. gesetzte Sperren anderer Transaktionen sind zu beachten
3. eine Transaktion darf nicht mehrere Sperren
für ein Objekt anfordern
4. Zweiphasigkeit:
- Anfordern von Sperren erfolgt in einer Wachstumsphase
- Freigabe der Sperren in Schrumpfungsphase
- Sperrfreigabe kann erst beginnen,
wenn alle Sperren gehalten werden
5. Spätestens bei EOT sind alle Sperren freizugeben
Striktes Zwei-Phasen-Sperren
5.
Technologie
30. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
2PL garantiert Serialisierbarkeit lediglich in einer fehlerfreien Umgebung
Fehler während Schrumpfungsphase können zu “Dirty Read”
etc. führen
Lösungsalternativen
- Lesen schmuziger Daten und Abhängigkeiten bei Commit
überprüfen (Problem: kaskadierende Rollbacks)
- Besser: strikte Zwei-Phasen-Sperrverfahren mit Sperrfreigabe
nach Commit
RX-Sperrverfahren
Sperranforderung einer Transaktion: R (Read) oder
X (eXclusive bzw. Write)
Gewährter Sperrmodus des Objektes: NL, R, X
Kompatibilitätsmatrix:
5.
Technologie
30. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
unverträgliche Sperranforderung (Sperrkonflikt)
führt zur Blockierung
Problem von Sperrkonversionen
5.
Technologie
30. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Sperrkonversionen führen oft zu Deadlocks
Erweitertes Sperrverfahren
- Ziel: Verhinderung von Konversions-Deadlocks
- U-Sperre (Update) für Lesen mit Änderungsabsicht
- bei Änderung Konversion U X, andernfalls U R (Downgrading)
aktueller Modus
angeforderter Modus
R
U
X
R
+
-
-
U
+
-
-
X
-
-
-
- u.a. in DB2 eingesetzt
- das Verfahren ist unsymmetrisch - was würde
eine Symmetrie bei U bewirken?
Konsistenzstufen von Transaktionen
Usprüngliche Definition von Gray et al. (1976)
Konsistenzstufe 0: Die Transaktionen halten kurze Schreibsperren auf den Objekten, die sie ändern
5.
Technologie
30. 1. 2017
B. Thalheim
Konsistenzstufe 1: Transaktionen halten lange Schreibsperren
auf den Objekten, die sie ändern
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Konsistenzstufe 2: Transaktionen halten lange Schreibsperren
auf den Objekten, die sie ändern, sowie kurze Lesesperren
auf Objekten, die sie lesen
Konsistenzstufe 3: Transaktionen halten lange Schreibsperren
auf den Objekten, die sie ändern, sowie lange Lesesperren
auf Objekten, die sie lesen.
Konsistenzebenen in SQL92
SQL92: vier Konsistenzebenen (Isolation Level) bzgl. Synchronisation
- Konsistenzebenen sind durch die Anomalien bestimmt,
die jeweils in Kauf genommen werden
- Lost-Update muß generell vermieden werden
- Default ist Serialisierbarkeit (serializable)
5.
Technologie
30. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
SQL-Anweisung zum Setzen der Konsistenzebene:
SET TRANSACTION <tx mode>, ISOLATION LEVEL <isolation level>
- tx mode: READ WRITE (Default) bzw. READ ONLY
Content
Information
Concept
Topic
SET TRANSACTION READ ONLY, ISOLATION LEVEL READ COMMITTED
READ UNCOMMITTED für Änderungstransaktionen unzulässig
Zusammenfassung
Transaktionskonzept vereinfacht Datenbank-Programmierung und
-Nutzung: Transparenz gegenüber Fehlern und Mehrbenutzerbetrieb
Transaktionsverwaltung zur Sicherung der ACID-Eigenschaften
5.
Technologie
30. 1. 2017
B. Thalheim
- Synchronisation
- Logging / Recovery
- Integritätskontrolle
Integritätskontrolle möglichst weitgehend im DBS
Transaktionen
Synchronisation
Recovery
Zwei-Phasen-Commit: erfolgreicher Transaktionsabschluss (Commit)
Algorithmik
mit Gültigstellung von Änderungen erst nach Sicherstellung
Optimierung
aller Integritätsbedingungen sowie der Wiederholbarkeit von
Realisierung
Änderungen
Integrität
Indexes
Denormalisation ACID v.a. für kurze Transaktionen geeignet y Bedarf
für erweiterte Transaktionskonzepte
Metadata
Content
Information
Concept
Topic
Anmerkung: Vielzahl von Ergänzungen
Recovery-Unterstützung
automatische Behandlung aller erwarteten Fehler durch das DBMS
Voraussetzung: Sammeln redundanter Informationen
während Normalbetrieb (Logging)
Transaktionsparadigma verlangt:
5.
Technologie
31. 1. 2017
B. Thalheim
• Alles-oder-Nichts-Eigenschaft von Transaktionen
• Dauerhaftigkeit erfolgreicher Änderungen
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Zielzustand nach Recovery: jüngster, transaktionskonsistenter Zustand
vor Erkennen des Fehlers
Fehlerarten:
• Transaktionsfehler: vollständiges Zurücksetzen auf Transaktionsbeginn
(Undo)
• Systemfehler (Rechnerausfall, DBMS-Absturz)
• REDO für erfolgreiche Transaktionen
(Wiederholung verlorengegangener Änderungen)
• UNDO aller durch Ausfall unterbrochenen Transaktionen
(Entfernen derer Änderungen aus der permanenten DB)
• Gerätefehler (Plattenausfall):
• vollständiges Wiederholen (REDO) aller Änderungen
auf einer Archivkopie
• oder: Spiegelplatten bzw. RAID-Disk-Arrays
Systemkomponenten für Recovery
5.
Technologie
31. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Pufferung von Log-Daten im Hauptspeicher (Log-Puffer)
- Ausschreiben spätestens am Transaktionsende (“Commit”)
Temporäre Log-Datei zur Behandlung von Transaktions- und
Systemfehler
Behandlung von Gerätefehlern: Archivkopie + Archiv-Log
Überblick zur Algorithmik von
Operationen
5.
Technologie
31. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Einführung zur Realisierung von Operationen
Selektion
Verbundalgorithmen
- Nested-Loop-Join
- Sort-Merge-Join
- Hash-Join
Sortierung
Weitere Operationen
Eigenschaften von Operationen
Ableitung von Prinzipien der Optimierung
Algorithmen zur Implementierung der
Selektion
Nutzung des Scan-Operators
5.
Technologie
31. 1. 2017
B. Thalheim
- Definition von Start- und Stop-Bedingung
- Definition von einfachen Suchargumenten
- Attributprojektion (ohne Duplikateliminierung)
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Algorithmen
Relationen-Scan
- immer möglich
- Scan-Operator implementiert die Selektionsoperation
Index-Scan
- Auswahl des kostengünstigsten Index
- Spezifikation des Suchbereichs (Start-, Stop-Bedingung)
TID-Algorithmus
- Auswertung aller “brauchbaren” Indexstrukturen
- Auffinden von variabel langen TID-Listen
- Boole’sche Verknüpfung der einzelnen Listen
- Zugriff zu den Tupeln entsprechend der Zielliste
- TID-Sortierung zur Minimierung von Plattenzugriffsarmbewegungen sinnvoll
Boole’sche Verknüpfung von Bitindizes
Auswertungsstrategien für Selektion
5.
Technologie
31. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Lineare Suche (brute force)
Binäre Suche (erfordert Sortierung, nur möglich bei geclusterter Speicherung)
Nutzung eines Primärindexes (falls vorhanden)
Nutzung eines Sekundärindexes
Konjunktive Suchprädikate
Schnittmengenbildung für TID-Listen
Bewertungsparameter: Selektivität eines Suchprädikates
Verbund-Algorithmen
Verbund
- satztypübergreifende Operation: gewöhnlich sehr teuer
- häufige Nutzung: wichtiger Optimierungskandidat
- typische Anwendung: Gleichverbund
- allgemeiner Θ-Verbund selten
5.
Technologie
31. 1. 2017
B. Thalheim
Implementierung der Verbundoperation kann gleichzeitig
Selektionen auf den beteiligten Relationen R und S ausführen
SELECT *
FROM R,S
WHERE R.VA 1Θ S.VA AND PR AND PS
Transaktionen
Synchronisation
Recovery
- VA: Verbundattribute
- PR und PS : Prädikate definiert auf Selektionsattributen (SA)
Algorithmik
von R und S
Optimierung
Mögliche Zugriffspfade
Realisierung
Integrität
- Scans über R und S (immer möglich)
- Scans über I(R(VA)), I(S(VA)) (wenn vorhanden) liefern
Indexes
Sortierreihenfolge nach VA
Denormalisation
- Scans über I(R(SA)), I(S(SA)) (wenn vorhanden)
Metadata
ggf. schnelle Selektion für PR und PS
Content
Information
Concept
Topic
- Scans über andere Indexstrukturen (wenn vorhanden)
ggf. schnelleres Auffinden aller Sätze
Verbund-Algorithmen:Nested-Loop-Join
Annahme:
- Sätze in R und S sind nicht nach den Verbundattributen geordnet oder
- es sind keine Indexstrukturen I(R(VA)) und I(S(VA)) vorhanden
5.
Technologie
31. 1. 2017
B. Thalheim
Berechnung allgemeiner Θ-Joins
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
2
Denormalisation Komplexität: O(N ) (Kardinalität N : Maximum für R und S)
Metadata
Content
Information
Concept
Topic
Nested-Loop-Join: Varianten
Nested-Loop-Join mit Indexzugriff auf innere Relation S
(Gleichverbund)
5.
Technologie
31. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Nested-Block-Join:
(Sort-) Merge-Join
2-Phasen-Algorithmus:
- Phase 1: Sortierung von R und S nach R(VA) und S(VA) (falls nicht
bereits vorhanden), dabei frühzeitige Eliminierung nicht benötigter
Sätze (y PR , PS )
5.
Technologie
31. 1. 2017
B. Thalheim
- Phase 2: schritthaltende Scans über sortierte R- und S-Sätze mit
Durchführung des Verbundes bei r.VA = s.VA
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Komplexität: O (N) bei vorliegender Sortierung, ansonsten O(N log N)
Metadata
Content
Information
Concept
Topic
(Sort-) Merge-Join
Spezialfall: Ausnutzung von Indexstrukturen auf Verbundattributen
(Annahme: I(R(VA)) und I(S(VA)) vorhanden)
- schritthaltende Scans über I(R(VA)) und I(S(VA))
5.
Technologie
31. 1. 2017
B. Thalheim
- falls R(VA) = S(VA), Überprüfung von PR und PS in den
zugehörigen Sätzen
- falls PR und PS , Bildung des Verbundes
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Hash-Join
nur für Gleichverbund
Idealfall: kleinere (innere) Relation S fast vollständig in Hauptspeicher
- Building-Phase: Einlesen von S und Speicherung in einer Hash-Tabelle
5.
Technologie
31. 1. 2017
B. Thalheim
unter Anwendung einer Hash-Funktion h auf dem Join-Attribut
- Probing-Phase: Einlesen von R und Überprüfung für jeden
Join-Attributwert, ob zugehörige S-Tupel vorliegen (wenn ja,
erfolgt Übernahme ins Join-Ergebnis)
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Vorteile
- lineare Kosten O(N)
- Hashing reduziert Suche nach Verbundpartnern auf Sätze einer
Content
Hash-Klasse (Partitionierung des Suchraumes)
- Nutzung großer Hauptspeicher
Information
Concept
Topic
- auch für Joins auf Zwischenergebnissen gut nutzbar
Hash-Join
allgemeiner Fall: kleinere Relation paßt nicht vollständig in
Hauptspeicher y Überlaufbehandlung erforderlich
5.
Technologie
31. 1. 2017
B. Thalheim
Lösung: Partionierung der Eingaberelationen (z.B. durch
GRACE Hash-Join)
- Partitionierung von S und R in q Partitionen über (Hash-)Funktion g
auf dem Join-Attribut, so daß jede S-Partition in den
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Hauptspeicher paßt
- q-fache Anwendung des Basisalgorithmus’ auf je zwei
zusammengehörigen Partitionen
rund 3-facher I/O-Aufwand gegenüber
Überlauf
Basisverfahren
ohne
Hash-Join: Varianten
Hybrider Hash-Join
- direkte Erstellung der Hash-Tabelle für die k ersten S-Partitionen
während Partitionierung (nur noch q-k Ausgabepartitionen)
5.
Technologie
31. 1. 2017
B. Thalheim
- analoge Partitionierung für R; bezüglich k erster Partitionen erfolgt
direkte Verbundberechnung
Speicheradaptiver Hash-Join
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
- Speicherzuordnung für Hash-Joins gemäß aktueller Lastsituation
(Ausmaß konkurrierender Transaktionen/Queries)
- variable Anzahl von S-Partitionen im Hauptspeicher
TID-Hash-Join
- zur Platzersparnis werden in Hash-Tabelle nur Kombinationen:
(Verbundattributwert, TID) gespeichert
- separate Materialisierungsphase für Ergebnistupel erforderlich
Nutzung von Bitvektoren
- während Partitionierung von S wird Bitvektor erstellt, in dem
Content
Information
Concept
Topic
vorhandenen Join-Attributwerten zugeordnete Bits gesetzt werden
- nur solche R-Tupel werden weiter berücksichtigt, für deren
Join-Attributwert zugehöriges Bit gesetzt ist
Verbundalgorithmen - Vergleich
5.
Technologie
31. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Nested-Loop-Join ist immer anwendbar
jedoch ist dabei stets das vollständige Durchsuchen des
gesamten Suchraums in Kauf zu nehmen
Sort-Merge-Join benötigt die geringsten Suchkosten, wenn
Indexstrukturen auf beiden Verbundattributen vorhanden sind
Sonst reduziert das Sortieren beider Relationen nach den
Verbundattributen den Kostenvorteil in erheblichem Maße.
Hash-Join partitioniert den Suchraum
Gleiche Hash-Funktion h auf die Relationen R und S angewendet
Content
Information
Concept
Topic
Partitionsgröße (bei der kleineren) Relation richtet sich nach der
verfügbaren Puffergröße im Hauptspeicher.
Mehr-Wege-Join
N-Wege-Verbund kann durch N-1 2-Wege-Joins realisiert werden
5.
Technologie
31. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
komplexe Optimierung
- N! mögliche Verbundreihenfolgen
- Festlegung von N-1 Verbundmethoden
- Nutzung von Pipelining, um Speicherung temporärer Zwischenergebnisse
zu reduzieren
Einsatz des SORT-Operators
5.
Technologie
31. 1. 2017
B. Thalheim
SORT-Optionen zur Duplikateliminierung:
N = keine Eliminierung
K = Duplikateliminierung bezüglich Sortierkriterium
Transaktionen
S = STOP sobald Duplikat entdeckt wird
Synchronisation
SORT als Basisoperator für Operationen auf höherer Ebene
Recovery
Algorithmik
Bsp.: JOIN zwischen R1 und R2
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Externes Sortieren
große Datenmengen können nicht im Hauptspeicher sortiert werden
Merge-Sort
- Einlesen und Zerlegung der Eingabe in mehrere Läufe (runs)
5.
Technologie
31. 1. 2017
B. Thalheim
- Sortieren und Zwischenspeichern (Zurückschreiben) der sortierten Läufe
- Einlesen und sukzessives Mischen der Läufe bis 1 sortierter Lauf entsteht
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Mischen:
y
Externes Sortieren
Anzahl der initialen Läufe m ist abhängig vom verfügbaren Hauptspeicher
- bei P+1 HS-Seiten können P Läufe gemischt werden
(1 Seite zur Generierung der Ausgabe)
5.
Technologie
31. 1. 2017
B. Thalheim
y Zerlegung der unsortierten
Eingabe in höchstens P Läufe (m ≤ P)
- der Umfang eines initialen Laufes kann höchstens P Seiten umfassen,
um eine interne Sortierung zu ermöglichen L ≤
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
N
P
(N = #Seiten der Eingaberelation)
Idealfall: P ≥
√
N y 1 Durchgang ausreichend (# Durchgänge D=1)
Externes Sortieren
Replacement Selection Sort: Erhöhung der Run-Länge
für initiale Zerlegung der (unsortierten) Eingabe
y Sortierung erfordert weniger Durchgänge
5.
Technologie
31. 1. 2017
B. Thalheim
Prinzip
- bei Ausgabe des nächst-kleinsten Elements erfolgt Übernahme
des nächsten Elementes x aus der Eingabe
- x kann noch im gleichen Run untergebracht werden, sofern x nicht
kleiner als das größte schon ausgegebene Element ist
Transaktionen
- Ersetzung erfolgt solange bis alle Schlüssel im Auswahlbereich
Synchronisation
kleiner sind als der zuletzt ausgegebene ( y neuer Run)
Recovery
- im Mittel verdoppelt sich die Run-Länge
Algorithmik
Optimierung
Beispiel 14, 4, 3, 17, 22, 5, 25, 13, 9, 10, 1, 11, 12, 6, 2, 15 (eigentliche Run-Länge sei 4
Realisierung
Sätze)
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Weitere Operationen
skalare Aggregatberechnungen: MIN, MAX, COUNT, SUM, AVG
- Nutzung von Indexstrukturen bzw. sequentielle Abarbeitung
5.
Technologie
31. 1. 2017
B. Thalheim
Kartesisches Produkt: Realisierung gemäß Nested-Loop Join
Durchschnitt / Vereinigung / Differenz: als Spezialfälle
vom Join realisierbar
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
- Beispiel: innere Relation S in Hauptspeicher-Hash-Tabelle
- modifiziertes Probing mit R zur Bestimmung von Duplikaten
und des Ergebnisses
Duplikat-Eliminierung
- 1 Eingaberelation
- Realisierung über Sortierung oder Hash-basierte Strategien
Gruppierung
- Sortierung bzw. Hashing bezüglich Gruppierungsattribut
- pro Attributwert Bestimmung der in Anfrage geforderten Aggregatwerte
Information
Concept
Topic
(SUM, COUNT, MAX etc.)
Zusammenfassung
Einfache Algorithmik bei Selektion und Projektion
Verbundoperation erfordert besondere Aufmerksamkeit
5.
Technologie
31. 1. 2017
B. Thalheim
- Nested-loop-join universell aber komplex
- Sort-merge-join einfach aber aufwendige Indizes erforderlich
- Hash-join nicht immer möglich, erfordert Gleichlauf
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Weitere Operationen durch spezielle Operatoren
- Sort-Operator als Basis-Operator
Zurückführung aller anderen Operationen auf Basisoperationen
- Warum können wir dies annehmen?
Komplex Anfrageoptimierung
Vorgehensweise
5.
Technologie
31. 1. 2017
B. Thalheim
Übersetzung vs. Interpretation von DB-Operationen
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Anfragedarstellung
Anfragetransformation
Erstellung und Auswahl von Zugriffsplänen
Kostenbewertung
Anfrageoptimierung
Informationssystem: stellt einem Benutzer mächtige Anfragesprachen zur Verfügung
Benutzer: kann damit Anfragen ausdrücken, die im Wesentlichen beschreiben,
was (welche Aussagen, Tupel, Objekte, Objektwerte) er als Ergebnisse erwartet
5.
Technologie
31. 1. 2017
B. Thalheim
Informationssystem: um Anfragen effizient zu bearbeiten, ermittelt aus der Anfrage,
wie die gewünschten Ergebnisse bzw. deren Bestandteile möglichst schnell (und platzsparend) erzeugt bzw. aufgefunden werden können
Transaktionen
Synchronisation
Optimierungsaufgabe: bestimme aus der Beschreibung des Was (einer Anfrage) einen guRecovery
ten Plan für das Wie (einen Algorithmus)!
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Anfrageoptimierung
Optimierung: besonders wichtig und besonders schwierig
- einerseits kann Benutzer anwendungsnahe, mächtige Sprachmittel
auf sehr große Mengen von Daten anwenden
5.
Technologie
31. 1. 2017
B. Thalheim
- andererseits muß Informationssystem die volle Kluft zwischen
Benutzersprache und Speicherzugriffen über alle Zwischenschichten
hinweg überbrücken
zentrales Problem
Transaktionen
- Umsetzung deskriptiver Anfragen in eine zeitoptimale Folge
Synchronisation
interner DBMS-Operationen
Recovery
- Anfrageübersetzer/-optimierer des DBMS ist im wesentlichen für eine
Algorithmik
effiziente Abarbeitung verantwortlich, nicht der Programmierer
Optimierung
Realisierung
Polyoptimierung mit runtime-Änderungen
Integrität
mit z.T. nicht genau erfaßbar, nur mit Statistiken unterlegbar
Indexes
Alternativen: algebraisch-basiert, statistisch-basiert
Denormalisation
Metadata
Content
Information
Concept
Topic
Anfrageoptimierung
hohe Komplexität der Übersetzung, da die Auswahlmächtigkeit
- an der Prädikatenlogik erster Stufe orientiert ist; durch zusätzliche
5.
Technologie
31. 1. 2017
B. Thalheim
Prädikate wie EXISTS, MATCHES, NULL, LIKE u. a. wird diese sogar deutlich übertroffen
- nicht auf einen Satztyp beschränkt ist
- unabhängige oder korrelierte Teilanfragen zur Bestimmung von
Suchargumenten in beliebiger Schachtelungstiefe zuläßt
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
- zusätzlich den Einsatz von Built-in- und Sortier-Funktionen auf
Partitionen der Satzmenge gestattet
zusätzliche Anforderungen
- auch die Manipulationsoperationen sind mengenorientiert
- referentielle Integrität durch referentielle Aktionen zu wahren
- Operationen können sich auf Sichten von Relationen beziehen
- vielfältige Optionen der Datenkontrolle sind zu berücksichtigen
Formulierung von ‘nicht angemessenen’ Anfragen wird durch
deskriptive Sprachen sehr einfach
- oft extreme Kostenunterschiede zwischen funktional äquivalenten
Zugriffsplänen
Ziel der Optimierung
Auswertung einer Anfrage:
- zunächst bestimmte Daten (Werte, Tupel, Objekte) in der
gegenwärtigen Instanz des Informationssystems auffinden
- anschließend aus bzw. in Abhängigkeit von diesen aufgefundenen
Daten, die gewünschten Ergebnisse erzeugen
5.
Technologie
31. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Damit ergeben sich folgende Wunsch-Anforderungen (die i.a. kaum erfüllbar
sind):
O1. [Suchraum beschränken ] ausschließlich auf die zu findenden Daten zugreifen
O2. [Wiederholungen vermeiden ] auf jedes zu findende Datum nur einmal
zugreifen
Methoden der Optimierung
1. Äquivalente Umformungen der Anfrage: auf der Ebene der
Anfragesprache äquivalente Anfragen bestimmen, in denen
- (im Sinne der Semantik) redundante Teile entfernt sind oder
5.
Technologie
31. 1. 2017
B. Thalheim
- Variable (bzw entsprechende Konzepte) an möglichst kleine Mengen
gebunden werden
2. Erstellung von Ausführungsplänen: so bestimmte Anfragen jeweils
übersetzen in ein oder mehrere Ausführungspläne, deren Anweisungen auf
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
tieferen Schichten des Informationssystems liegen
3. Aufwandsschätzung: für so gewonnene Ausführungspläne den
voraussichtlichen Aufwand abschätzen
4. Suche nach einem kostengünstigen Ausführungsplan: alle
erfolgversprechenden äquivalenten Umformungen erzeugen (1. ") und
deren Übersetzungen in Pläne (1. " ) und jeweils deren Aufwand (3. ")
bestimmen mit dem Ziel, möglichst schnell einen Plan als kostengünstig
(oder im besten Fall als kostengünstigsten) im Vergleich mit den anderen
erzeugten Plänen zu erkennen
Content
Information
Concept
Topic
Nutzbares Wissen zur Optimierung
- Kenntnisse über die Semantik von Anfragen, insbesondere Regeln für
äquivalenzerhaltende Umformungen
5.
Technologie
31. 1. 2017
B. Thalheim
- Schemavereinbarung, insbesondere semantische Bedingungen
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
- Laufzeitinformation über gespeicherte Objekte
(z.B. Anzahl der gespeicherten Tupel einer Relation)
- Kenntnisse über verfügbare Datenstrukturen und Algorithmen
Content
Information
Concept
Topic
- Laufzeitinformation über bereits angelegte Zugriffsstrukturen
Heuristiken zur Optimierung
- Ausdrücke zusammenfassen
- Redundanz entfernen
- Selektionen und Projektionen vorziehen
- Verbund-Reihenfolge auswählen
Anfragedarstellung
direkte Repräsentation der Anfrage als Zeichenstring (Relationenalgebra, Relationenkalkül)
5.
Technologie
31. 1. 2017
B. Thalheim
syntaktischer Aufbau der Anfrage z.B. durch Syntaxgraphen
Darstellung der Auswertungsstrategie durch Operatorgraph
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
- Knoten stellen Operatoren (z.B. der Relationenalgebra) dar
- Kanten beschreiben operator-kontrollierten Datenfluß
- Verfeinerung um innere Operatoren möglich
Anfragetransformation
Ziele der Anfragetransformation (algebraische Optimierung)
- standardisierte Ausgangsdarstellung
5.
Technologie
31. 1. 2017
B. Thalheim
- Elimination der Redundanz
- Verbesserung der Auswertbarkeit
Standardisierung
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
- Wahl einer Normalform, z.B. konjunktive Normalform
(A11 OR ... OR A1n) AND ... AND (Am1 OR ... OR Amn)
- Verschiebung von Quantoren
Elimination der Redundanz / Vereinfachung
- Behandlung/Eliminierung gemeinsamer Teilausdrücke
(A1 = a11 OR A1 = a12) AND (A1 = a12 OR A1 = a11)
- Ausdrücke, die an “leere Relationen” gebunden sind, können vereinfacht
werden
- Konstanten-Propagierung: A op B AND B = const.
Content
Information
Concept
Topic
- nicht-erfüllbare Ausdrücke, z.B.: A ≥ B AND B ≥ C AND C > A
Anfragetransformation
Verbesserung der Auswertbarkeit
- Nutzung von Äquivalenzbeziehungen für relationale Operatoren
5.
Technologie
31. 1. 2017
B. Thalheim
siehe Teil 3 der Vorlesung - Zusammenfassung von Operationsfolgen
- Minimierung der Größe von Zwischenergebnissen
- selektive Operationen (σ, π) vor konstruktiven Operationen 1, ×, ∪
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Nutzung von Integritätsbedingungen (knowledge-based / semantic query processing)
- Bsp.: A ist Primärschlüssel: πA y
keine Duplikateliminierung erforderlich
- Integritätsbedingungen sind wahr für alle Tupel der betroffenen Relation.
Hinzufügen einer Integritätsbedingung zur WHERE-Bedingung
verändert den Wahrheitswert nicht
Erstellung und Auswahl von
Ausführungsplänen
Eingabe:
5.
Technologie
31. 1. 2017
B. Thalheim
- transformierte Anfrage
- existierende Speicherungsstrukturen und Zugriffspfade
- Kostenmodell
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Ausgabe: optimaler bzw. “guter” Ausführungsplan
(Query Evaluation Plan)
Alternative Herangehensweisen
Algebraische Optimierung
Statistische Optimierung
Algorithmen zur Optimierung
Klassische Optimierungsalgorithmen
Approximative Optimierung
• Brute-Force-Algorithmen: Breite-Zuerst, Tiefe-Zuerst, Auswahl mit Kostenmodell, beschränktes TiefeZuerst, iterative Tiefe-Zuerst, bidirektionale Tiefe-Zuerst (exponentiell)
• Heuristische Algorithmen: Greedy-Algorithmen, A*-Algorithmen, speicherbeschränkte Heuristiken (rekursives Bestes-Zuerst) mit Vielzahl von heuristischen Funktionen
• Lokale Algorithmen: Hill-Climbing, Annealing, Beam-Optimierung, genetische Algorithmen
Erstellung und Auswahl von
Ausführungsplänen
Vorgehensweise:
5.
Technologie
31. 1. 2017
B. Thalheim
1. Generiere alle “vernünftigen” logischen Zugriffspläne
zur Auswertung der Anfrage
2. Zerlege komplexere Operationen in Folge von Ein- und
Zwei-Variablen-Ausdrücke
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
3. Wähle für jeden logischen Operator Implementierungsstrategie
unter Berücksichtigung der Zugriffspfade und
Speicherungsstrukturen (Clusterung, Sortierreihenfolge etc.)
4. Wähle den billigsten Zugriffsplan " dem vorgegebenen
Kostenmodell aus
Suchstrategien
- voll-enumerativ
- beschränkt-enumerativ
- zufallsgesteuert
Content
Reduzierung: bestimmte Suchpfade zur Erstellung von Ausführungsplänen
Information
Concept
Topic
werden nicht mehr verfolgt
Berechnung der Zugriffskosten
Optimizer erstellt Kostenvoranschlag für jeden Zugriffsplan
(möglicher Lösungsweg)
5.
Technologie
31. 1. 2017
B. Thalheim
Berücksichtigung von folgenden Kosten
- Berechnungskosten (CPU-Kosten, Pfadlängen)
- I/O-Kosten (# der physischen Referenzen)
- Speicherungskosten (temporäre Speicherbelegung im DB-Puffer und
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
auf Externspeichern)
- im verteilten Fall: Kommunikationskosten (# der Nachrichten,
Menge der zu übertragenden Daten)
Gewichtete Kostenformel:
C = # physischer Seitenzugriffe + W * (#Aufrufe des Zugriffssystems)
- gewichtetes Maß für I/O- 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
Typisches Kostenmodell - statistische
Werte
statistische Größen:
MS Anzahl der Datenseiten des Segmentes S
5.
Technologie
31. 1. 2017
B. Thalheim
LS Anzahl der leeren Seiten in Segment S
NR Anzahl der Tupeln der Relation R (Card(R))
TR,S Anzahl der Seiten in S mit Tupeln von R
C Clusterfaktor (Anzahl Tupel pro Seite)
R
Transaktionen
jI Anzahl der Attributwerte / Schlüsselwerte im Index I
Synchronisation
für Attribut A ( = Card (pA (R)) )
Recovery
BI Anzahl der Blattseiten (B*-Baum) für Index I
Algorithmik
...
Optimierung
Realisierung
Statistiken müssen im Katalog gewartet werden
Integrität
- Aktualisierung bei jeder Änderung zu aufwendig (zusätzliche SchreibIndexes
und Log-Operationen, Katalog wird zum Sperr-Engpaß)
Denormalisation
- Alternative:
Metadata
Content
Information
Concept
Topic
- Initialisierung der statistischen Werte zum Lade- oder
Generierungszeitpunkt von Relationen und Indexstrukturen
- periodische Neubestimmung der Statistiken durch eigenes Kommando/Dienstprogramm
Grundsätzliche Probleme
Anfrageoptimierung beruht i.a. auf zwei fatalenÄnnahmen
1. Alle Datenelemente und alle Attributwerte sind gleichverteilt
2. Suchprädikate in Anfragen sind unabhängig
5.
Technologie
31. 1. 2017
B. Thalheim
beide Annahmen sind jedoch im allgemeinen Fall falsch !
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Lösung: Verbesserung der Statistiken / Heuristiken
Verfeinerte Kostenmodelle
verbesserte Ansätze zur Schätzung der
Verteilung von Attributwerten
- parametrisierte Verteilungen (z.B. Normalverteilung)
5.
Technologie
31. 1. 2017
B. Thalheim
- Histogramme
- Stichproben
Histogramme
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
- Unterteilung des Wertebereichs in Intervalle; Häufigkeitszählung pro Intervall
- äquidistante Intervalle vs. Intervalle mit etwa gleicher Häufigkeit von Werten
(Equi-Depth-Histogramme)
Zusammenfassung
Interpretation vs. Übersetzung
- Interpretation: hoher Aufwand zur Laufzeit (v.a. bei wiederholter
Ausführung einer Anweisung)
5.
Technologie
31. 1. 2017
B. Thalheim
- Übersetzung: pro DB-Anweisung wird zugeschnittenes Programm zur
Übersetzungszeit erstellt y hohe Laufzeiteffizienz
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Kernproblem der Anfrageoptimierung: Übersetzung
(multi-)mengenorientierter DB-Sprachen
- Analyse
- Anfragetransformation / Algebraische Optimierung
- Optimierung unter Berücksichtigung von Zugriffspfaden und
Operatorimplementierungen (Verwendung von Heuristiken)
- Kostenbewertung und Auswahl des günstigsten Plans
- Code-Generierung
Kostenvoranschläge für Zugriffspläne:
- CPU-Zeit und E/A-Aufwand
- Anzahl der Nachrichten und zu übertragende Datenvolumina
(im verteilten Fall)
“fatale” Annahmen:
Information
Concept
Topic
- Gleichverteilung aller Attributwerte
- Unabhängigkeit aller Attribute
Integritätskontrolle
Wahrung der logischen DB-Konsistenz
Überwachung von semantischen Integritätsbedingungen durch Anwendungen oder durch DBS
DBS-basierte Integritätskontrolle
5.
Technologie
31. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
• größere Sicherheit
• vereinfachte Anwendungserstellung
• Unterstützung von interaktiven sowie programmierten DB-Änderungen
• leichtere Änderbarkeit von Integritätsbedingungen
• ggf. Leistungsvorteile
Optionen zu Integritätspflege
Benutzer muss dies i.a. durch sorgfältigen Entwurf der Transaktionen
erreichen
Informationssystem unterstützt dabei durch programmiersprachliche
Konstrukte:
5.
Technologie
31. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
• Meldungen über den Erhalt bzw. die Verletzung von Bedingungen
bei Änderungen, wobei bei Verletzung der Bedingungen
eine Liste der betroffenen Objekte geliefert wird,
etwa Affected(objekt liste)
• Anweisung zum vorzeitigen Abbruch einer Transaktion, die die
gesamte Transaktion gar nicht wirksam werden lässt,
etwa Abort Trans
• Anweisung zum vollständigen Wirksamwerden einer Transaktion,
etwa Commit Trans
Wiederholung: Arten von
Integritätsbedingungen
5.
Technologie
31. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Modellinhärente vs. sonstige (modellunabhängige) Integritätsbedingungen
- Modellinhärente Bedingungen des RM: Primärschlüsseleigenschaft;
referentielle Integrität für Fremdschlüssel;
Definitionsbereiche (Domains) für Attribute
Reichweite der Bedingung
- Attributwert-Bedingungen (z. B. Geburtsjahr > 1900)
- Satzbedingungen (z. B. Geburtsdatum < Einstellungsdatum)
- Satztyp-Bedingungen (z. B. Eindeutigkeit von Attributwerten)
- satztypübergreifende Bedingungen (z. B. referentielle Integrität
zwischen verschiedenen Tabellen)
Statische vs. dynamische Bedingungen
- Statische Bedingungen (Zustandsbedingungen) beschränken
zulässige DB-Zustände (z.B. Gehalt < 500000)
- dynamische Integritätsbedingungen (Übergangsbedingungen):
zulässige Zustandsübergänge (z. B. Gehalt darf nicht kleiner werden)
- Variante dynamischer IB: temporale Integritätsbedingungen
für längerfristige Abläufe (z. B. Gehalt darf innerhalb von 3 Jahren nicht
um mehr als 25 % steigen)
Zeitpunkt der Überprüfbarkeit: unverzögerte vs.
verzögerte Integritätsbedingungen
Zur Erinnerung: Integritätsbedingungen
in SQL92
5.
Technologie
31. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Primary Key- und Foreign Key-Klauseln
- referentielle Integrität: deklarative Spezifikation unterschiedlicher
Reaktionsmöglichkeiten für Wegfall (Löschung, Änderung) eines
referenzierten Satzes bzw. Primärschlüssels
(CASCADE, SET NULL, SET DEFAULT, NO ACTION)
Festlegung von Wertebereichen für Attribute durch
Angabe eines Datentyps bzw. Domains
- optional: Angabe von Default-Werten, Eindeutigkeit
(UNIQUE), Nullwerte-Ausschluß (NOT NULL)
- allgemeine Wertebereichsbeschränkungen über CHECK-Klausel
Spezifikation allgemeiner, z. B. tabellenübergreifender Bedingungen durch CREATE ASSERTION
direkte (IMMEDIATE) oder verzögerte (DEFERRED)
Überwachung spezifizierbar
Integritätsregeln
5.
Technologie
31. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Standardreaktion auf verletzte Integritätsbedingung: ROLLBACK
Integritätsregeln erlauben Spezifikation von Folgeaktionen,
z.B. um Einhaltung von IB zu erreichen
- SQL92: deklarative Festlegung referentieller Folgeaktionen
(CASCADE, SET NULL, ...)
- SQL3: Trigger
- allgemeine aktive Datenbanksysteme: ECA-Regeln
Trigger bzw. ECA-Regeln teilweise prozedural,
jedoch sehr flexibel und mächtig
- Realisierungsmöglichkeit für nahezu alle Integritätsbedingungen,
u.a. dynamische IB
- Zeitpunkte, Verwendung alter/neuer Werte, Aktionsteil
im Detail festzulegen
- viele Einsatzformen über Integritätskontrolle hinaus
Integritätsregeln
5.
Technologie
31. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
Probleme von Triggern
- Trigger i.a. beschränkt auf Änderungsoperationen einer Tabelle
(UPDATE, INSERT, DELETE)
- derzeit i.a. keine verzögerte Auswertung von Triggern
- Gefahr zyklischer, nicht-terminierender Aktivierungen
- Korrektheit des DB-/Trigger-Entwurfes (Regelabhängigkeiten,
parallele Regelausführung, ...)
Implementierungsaspekte der
Integritätskontrolle
5.
Technologie
31. 1. 2017
B. Thalheim
Transaktionen
Synchronisation
Recovery
Algorithmik
Optimierung
Realisierung
Integrität
Indexes
Denormalisation
Metadata
Content
Information
Concept
Topic
IC-Überprüfung verlangt vom DBS Entscheidungen
- für welche DB-Operationen welche Überprüfungen zusätzlich
vorzunehmen sind
- wann Überprüfungen durchzuführen sind (direkt, verzögert)
- wie Überprüfungen vorzunehmen sind (Ausführungsplan)
Behandlung zur Übersetzungszeit (falls Namen der Tabellen,
Attribute... bekannt) oder zur Laufzeit
in einfachen Fällen können IB über Anfragemodifikation
(query modification) behandelt werden
- Transformation von Änderungsoperation durch Hinzunahme
einzuhaltender IB-Prädikate
- verhindert Ausführung integritätsverletzender Änderungen
Integritätskontrolle über allgemeines Regelsystem
- interne Verwendung von Triggern bzw. ECA-Regeln
auch bei deklarativer Spezifikation von IB
- dynamische Überwachung regelauslösender Ereignisse
sowie der ausgelösten Ausführungen