Transaktionssysteme

Transaktionssysteme
 Arno Schmidhauser
Letzte Änderung: 13. März 2012
Email: arno.schmidhauser@bfh.ch
Webseite: http://www.sws.bfh.ch/db

I - Übersicht
• Transaktionsmodell
– ACID Regel
• Wichtige Komponenten
– Recovery System
– Concurrency Control
– Zugriffsoptimierung

Was ist eine Transaktion
• Aus logischer Sicht ist eine Transaktion ein Arbeitspaket,
das einen geschäftlichen Nutzen erzeugt.
– So klein wie möglich.
– so gross wie nötig, um alle Integritätsbedingungen
einhalten zu können.
• Aus technischer Sicht ist eine Transaktion eine Folge von
Lese- und Änderungsoperationen in der Datenbank, mit
einem definierten Beginn und einem definierten Abschluss.
• Die Transaktionsverwaltung ist eine der Kernaufgaben
eines Datenbanksystems.

ACID-Regel
• Das Datenbanksystem garantiert für eine Transaktion
folgende Eigenschaften:
A Atomarität
C Konsistenz
I Isolation
D Dauerhaftigkeit
Diese Eigenschaften werden als ACID Regel bezeichnet.

Arbeiten mit Transaktionen
• Jeder lesende oder schreibende Zugriff auf die Datenbank kann
nur innerhalb einer Transaktion stattfinden.
• Eine Transaktion beginnt explizit mit einem "begin transaction"
Befehl oder implizit mit dem ersten SQL-Befehl.
• Eine Transaktion wird nur mit dem "commit"-Befehl korrekt
abgeschlossen. Andernfalls gilt sie noch nicht als korrekt
beendet.
• Eine Transaktion kann explizit mit "rollback" oder implizit durch
ein äusseres Ereignis abgebrochen werden.

ACID, Systemkomponenten
• Es folgt die Betrachtung einiger Systemkomponenten, die
sowohl für die Erfüllung der ACID-Regel wichtig sind, wie
auch gleichzeitig die Performance der Datenbank
entscheidend beeinflussen.
• Recovery System
• Concurrency Control
• Zugriffsoptimierung
Zeitverhalten eines Datenbanksystems

III
Das Recovery-System
• Zweck
• Logfile
• Fehlerbehebung

Zweck des Recovery-Systems
 Das Recovery-System eines DBMS enthält alle Hilfsmittel zum
Wiederherstellen eines korrekten Datenbank-Zustandes nach
 Transaktionsfehlern (Rollback)
 Systemfehlern (Crash des Serverprozesses)
 Das Recovery-System garantiert die Atomarität und Dauerhaftigkeit
einer Transaktion (ACID Regel).
• Das Recovery-Systems basiert auf dem Führen eines Logfiles, in
welchem Änderungen protokolliert werden.
• Abschätzen und Überwachen der Grösse und Festlegen des
Speicherortes für das Logfile sind zwei wichtige Aufgaben der
Datenbank-Administration

Fehlerarten
• Transaktionsfehler
– Rollback-Befehl durch Applikation
– Verletzung von Integritätsbedingungen
– Verletzung von Zugriffsrechten
– Deadlock
– Verbindungsunterbruch oder Client-Crash
• Systemfehler
– Stromausfall, Hardware- oder Memory-Fehler

Ablauf von Modifikationsbefehlen
DB-Storage
Checkpoint (Gelegentlich)
SQL-Befehl eines Clients
1.
2. Neue Datenwerte
Logfile
Alte und neue
Datenwerte
Workspace

Logging, Beispiel
Zeit
T1
T2
T3
T4
Checkpoint Systemfehler
BOT
T1
M21 M22
M31 M32
M41 M42
M11
BOT
T2
BOT
T3
BOT
T4
CMT
T1
CMT
T2
RBK
T3
B_CKPT
(T2,T3,T4)
E_CKPT
(T2,T3,T4)
M21
M11
M22
M31
M32
M41
M42
Logfile

Behebung von Transaktionsfehlern
• Bei einem Transaktionsfehler (Rollback) werden aus den
rückwärts verketteten Transaktionseinträgen im Logfile die
alten Daten (Before Images) in den Workspace
übertragen.
• Das Datenbanksystem führt hierzu für jede laufende
Transaktion einen Verweis auf den letzten Log- Eintrag
mit. Der Transaktionsabbruch wird im Logfile ebenfalls
protokolliert.
• Beispiel: Für Transaktion T3 müssen die Before-Images
von M31 und M32 zurückgeladen werden.

Behebung von Systemfehlern
• Gewinner- und Verlierer-Transaktionen ermitteln
• Verlierer-Transaktionen mit Hilfe der Before-Images
zurücksetzen
• Gewinner-Transaktionen mit Hilfe der After-Images noch
einmal durchführen
• Checkpoint durchführen
• Beispiel
– Gewinner: T2 -> M22 nachspielen.
– Verlierer: T3 und T4 -> M31, M41 zurücksetzen.

Zusammenfassung Recovery-System
• Logfile = Performance-kritisches Element einer Datenbank
• Grössenabschätzung vornehmen
• Alternative Speichermöglichkeiten prüfen (SSD Disks
mittl. Zugriffszeit ~10x schneller, 0.4ms statt 4ms)
• Für Bulk-Load Operationen kann und darf man Logging oft
ausschalten
• Logfile wird bei fast allen Datenbanken heute neben dem
Recovery für die Datenreplikation verwendet.

IV
Concurrency Control
• Zweck
• Serialisierbarkeit
• Neue Methoden

Ziel des Concurrency Control
• Einerseits: Isolation (I-Bedingung der ACID Regel)
– Änderungen am Datenbestand dürfen erst bei
Transaktionsabschluss für andere sichtbar sein.
– Die parallele Ausführung von Transaktionen muss bezüglich
Datenzustand und bezüglich Resultatausgabe identisch mit
der seriellen Ausführung von Transaktionen sein
(Serialisierbarkeit).
• Andererseits: Parallelität
– Eine Datenbank muss mehrere Benutzer(-prozesse)
gleichzeitig bedienen können und es sollen möglichst wenig
Wartesituationen entstehen.

Serialisierbarkeit, Beispiel
Transaktion 1
1.1 select * from Kunde
where name = "Muster"
1.2 delete from Kunde
where kunr = :kunr
1.3 delete from Bestellung
where kunr = :kunr
commit
Transaktion 2
2.1 select * from Kunde
where name = "Muster"
2.2 select * from Bestellung
where kunr = :kunr
commit
Die folgenden zwei Transaktionen müssen so gesteuert werden,
dass der Schritt 1.3 nicht zwischen 2.1 und 2.2 zu liegen kommen.

Serialisierbarkeit ff
Unter der Annahme, dass die Datenbank keine Synchro-
nisationsmittel einsetzt und jedes SQL-Statement ein
atomarer Schritt ist, sind verschiedene zeitliche Abläufe
der beiden Transaktionen denkbar:
1. 1.1  2.1  1.2  2.2  1.3 (k)
2. 1.1  2.1  1.2  1.3  2.2 (f)
3. 1.1  2.1  2.2  1.2  1.3 (k)
4. 1.1  1.2  2.1  1.3  2.2 (k)
5. 1.1  1.2  2.1  2.2  1.3 (f)
6. 1.1  1.2  1.3  2.1  2.2 (s)
7. 2.1  1.1  1.2  2.2  1.3 (k)
8. 2.1  1.1  2.2  1.2  1.3 (k)
9. 2.1  1.1  1.2  1.3  2.2 (f)
10. 2.1  2.2  1.1  1.2  1.3 (s)

Locking
• Locking ist die häufigste Technik zur Gewährleistung der
Serialisierbarkeit.
– Für das Lesen eines Datensatzes wird ein S-Lock gesetzt
– Für das Ändern, Löschen, Einfügen wird ein X-Lock gesetzt.
– Für das Einfügen wird zusätzlich ein S-Lock auf der Tabelle
gesetzt.
• Die gesetzten Locks sind gemäss einer Verträglichkeitstabelle
untereinander kompatibel oder nicht:
S X
S + -
X - -
Bestehende Sperre
Angeforderte Sperre
Angeforderte Sperre wird
gewährt (+) oder nicht gewährt (-)

Deadlocks
• Beim Sperren von Daten können Deadlocks auftreten. Der
Deadlock ist nicht ein logischer Fehler, sondern bedeutet:
– Es gibt keinen Weg mehr, die anstehenden Transaktionen so
zu steuern, dass ein serialisierbarer Ablauf entstehen wird.
– Eine der beteiligten Transaktionen wird daher zurückgesetzt,
so dass für die übrigen wieder die Chance besteht, gemäss
Serialisierbarkeitsprinzip abzulaufen.2004.ppt#121.
Serialisierbarkeit

Isolationsgrade
• Eine unter allen Umständen garantierte Serialisierbarkeit kann die
Parallelität empfindlich einschränken. Ist zum Vornherein bekannt,
dass gewisse Inkonsistenzen aufgrund der Business-Logik gar nicht
auftreten können, oder allenfalls in Kauf genommen werden sollen,
können die Locking-Massnahmen des DBMS gelockert werden.
• SQL definiert deshalb vier Isolationsgrade beim Lesen von Daten:
Isolationsgrad Inkonsistenzen
3 SERIALIZABLE -
2 REPEATABLE READ Phantom-Problem
1 READ COMMITTED Lost-Update, Reporting Problem
0 READ UNCOMMITTED Lesen unbestätigter Daten
Paralleli
ät
Isolatio
n

Phantom-Problem
T1 T2
select *
from Person
where name = 'Muster'
insert Person ( name )
values ( 'Muster')
commit
select *
from Person
where name = 'Muster'
commit
Hier tauch neuer Datensatz auf
Bei REPEATABLE READ

Lost-Update
T1 T2
select saldo
from Konto
where idKonto = 3
select saldo
from Konto
where idKonto = 3
neuerSaldo = saldo + 100
update Konto
set saldo = neuerSaldo
where idKonto = 3
commit
neuerSaldo = saldo + 100
update Konto
set saldo = neuerSaldo
where idKonto = 3
commit
Änderungen von T2 gehen beim
Update von T1 verloren !
Bei READ COMMITTED

Reporting-Problem
T1 T2
select *
from Bestellung
order by zahlDatum
update Bestellung
set zahlDatum = now()
where idBestellung = 4711
commit
-- …
-- Abfrage läuft hier weiter
-- …
commit
Derselbe Datensatz kann hier wieder
auftauchen
Bei READ COMMITTED

Demo
Auswirkung des Isolationsgrades auf Transaktions-Durchsatz
• Die Einstellung des Isolationsgrades hat bei intensiven
genutzten Systemen grosse Auswirkungen auf den
Transaktionsdurchsatz, die Deadlockhäufigkeit und das
Auftreten von Inkonsistenzen.
 Transaktionssimulator

Neue Methoden
• Range Locks:
Entschärft ganz entscheidend die Phantomproblematik und
erlaubt in den meisten Fällen von OLTP das Arbeiten im
Modus SERIALIZABLE.
• Datensatz-Versionierung:
Erlaubt ein vollständiges stabiles Lesen von Daten und
Vermeidung des Phantom-Problems, ohne Anwendung von
Locks.

Range Locks (1)
• Range Locks werden für die Realisierung des Isolation
Levels SERIALIZABLE verwendet.
• Mit Range Locks werden Datensätze nach einer logischen
Bedingung und nicht nur rein physisch gesperrt.
• Mit Range Locks kann das Phantom Problem elegant
gelöst werden.
• Voraussetzung: Die Abfragebedingung enthält einen oder
mehrere Teile, welche über einen Index evaluiert werden
können. Beispiel:
select * from Reservation
where resDatum > '1.1.2008'
and resDatum < '31.12.2008'

Range Locks (2)
Datensatz mit resDatum 1.6.2009
Range Locks werden auf Index-Einträge gesetzt, nicht auf
Datensätze, wie gewöhnliche Locks.
Datensätze mit
gesetztem Range Lock
select * from Reservation
where resDatum < '31.12.2008'
and resDatum > '1.1.2008'
Wirkungsbereich des
Range Locks

Concurrency Control mit Versionen
• Von einem Datensatz werden zeitweilig mehrere Versionen geführt,
mit folgenden Zielen:
– Eine Transaktion sieht einen committeten Datenbankzustand
bezogen auf den Zeitpunkt des Starts. Dieser Zustand bleibt
über die ganze Transaktionsdauer eingefroren.
– Schreibbefehle werden durch Lesebefehle nicht behindert und
umgekehrt.
– Schreibbefehle beziehen sich immer auf die neueste Version
eines Datensatz in der Datenbank.

Versionen, Leser gegen Schreiber
Datensatz X, TNC = 2
Lesende Transaktion/Befehl, TNC = 3
1
Schreibende Transaktion/Befehl, TNC = 4
2
Kann gelöscht werden
7
6
commit
5
4
Kopie des Datensatz
3

Versionen, Schreiber gegen Schreiber
Schreibende Transaktion, TNC = 3
1
Schreibende Transaktion, TNC = 4
2
5 commit: ok, weil
TNC 2 = max TNC
im Pool
Kopie Datensatz
4
7
commit: abort,
weil TNC 2  max
TNC im Pool

Kopie Datensatz
3
Änderungsbefehl
6

Demo
Isolationsverbesserung mit Versionenverfahren
in SQL Server 2005/2008
• Zusätzlicher Isolation Level SNAPSHOT : Ergibt
serialisierbare Transaktionen ohne Verwendung von
Lesesperren. Änderungskonflikte mit anderen
Transaktionen werden beim Commit festgestellt.
• Isolation Level READ COMMITTED mit Versionenverfahren
realisiert. Es wird immer ein committeter Zustand
gesehen, es sind aber Lost Updates möglich.

V
Zugriffsoptimierung
• Zielsetzung
• Indexierung von Daten
• SQL Ausführungsplan
• Optimierungshinweise

Zielsetzung
• Ein zentrales Ziel der Abfrageoptimierung ist die Minimierung
des Zugriffs auf I/O-Pages.
• Eine I/O-Page ist ein Datenblock fester Grösse, der am Stück
von einem Speichermedium gelesen oder darauf geschrieben
wird.
• Ein Query Optimizer erzeugt einen Query Execution Plan (QEP),
der den Ablauf einer Abfrage festlegt.
• Die Hilfsinformation für die Planung einer Abfrage sind
verschiedenste Statistiken.
• Das primäre Hilfsmittel für die Durchführung einer Abfrage ist
ein Index.

Indexierung von Daten
• Ein Index ist eine Hilfsstruktur zum schnelleren Auffinden
von Datensätzen.
• Indices werden immer für ein, allenfalls mehrere Attribute
einer Tabelle erzeugt.
• Für Primär- und Fremdschlüssel erzeugt das DMBS meist
selbstständig einen Index.
• Für Attribute, die in Suchbedingungen oder Sortierklauseln
vorkommen, werden zusätzliche Indices erstellt mit:
create index ixname on table (attr1 [,attrn]...)
• Indices haben meist die Struktur eines verzweigten,
ausgeglichenen Baumes (B*).

B*-Index
Z0 W1 Z1 W2 Z2 freier Platz
P S1 D1 S2 D2 freier Platz N P S1 D1 S2 D2 freier Platz N
Knoten (I/O-Page)
R1 R2 R3 R4 R5 R6 R7 R1 R2 R3 R4 R5 R6 R7
Index
Daten

B*-Index, Beispiel
E N
A D G K P T
G
a
b
i
G
ü
nt
h
r
E
d
g
ar
E
m
i
l
Index
Emil
Schlossweg1
Huber
Xeno
Waldstr. 8
Müller
Daten
K
u
r
t
L
o
r
e
n
z
N
i
c
o
l
a
O
t
h
m
a
r
P
et
e
r
R
o
l
f
T
h
o
m
a
s
X
e
n
o
C
a
r
m
e
n
D
a
n
i
el

Anwendungsmöglichkeiten B*
• Auffinden einzelner Datensätzen eines bestimmten
Schlüsselwertes. Beispiel:
where name = 'Meyer'
• Auffinden von Datensätzen in einem bestimmten
Schlüsselbereich.Beispiel:
where gebdatum between '1.1.2000' and 1.1.2001
• Sortierte Ausgabe von Daten. Beispiel:
order by name
• Auffinden von Datensätzen wenn nur der Anfang des
Schlüssels bekannt ist. Beispiel:
where name like 'M%'

Join-Bildung
• Joins sind ein zentrales Konstrukt in SQL. Häufige Algorithmen
für die Join-Bildung sind:
– Nested Loop Join
• Doppelte Schlaufe zur Abarbeitung der Tabellen. Für ganz kleine Tabellen
geeignet und als theoretischer Fallback, der immer möglich ist.
• Aufwand: M/k1 + M * N/k2
– Lookup Join
• Äussere Tabelle sequentiell durchlaufen. Jeden Vergleichswert
(Schlüsselwert) via Indexzugriff in der inneren Tabelle suchen.
• Aufwand: M/k1 + M * (k2log(N/k2)+2)
Anzahl IO-Pages äussere Tabelle
Anzahl Datensätze aussen = Anzahl Aufrufe in den inneren Index
Gesamtzugriffe für IO-Pages innere Tabelle
Zugriff Root-Page + Zugriff Datenpage

Join-Bildung, Merge Join
• Es müssen zwei bereits sortierte Tabellen vorliegen. Alle Datensätze der
linken und rechten Tabelle werden abwechslungsweise über ein
Vergleichsfenster geschoben und die Schlüsselwerte verglichen.
• Aufwand: M/k1+N/k2
2
3
7
7
1 2
2 3
3 4
5 7
7 7
10 12
T1 T2
Vergleichsfenster
Sortierte

Join-Bildung, Hash Join
• Buckets mit Datensätzen beider Tabellen, die den gleichen Hashwert für
das Join-Attribut haben. Verknüpfung der Datensätze pro Bucket für die
Ausgabe.
• Aufwand: M/k1+N/k2
Bucket 1 Bucket 2
Originale Datensätze Originale Datensätze
Join Resultat

Sortieren
• Sortieren ist in Datenbanken eine unverzichtbare Operation:
– für die sortierte Ausgaben mit order by
– für die Durchführung von group by
– als Vorbereitung für Merge Join
– für den Datenabgleich in redundanten Systemen
• Sortieren ist für die Präsentation und Analyse von grossen
Datenmengen in Data Warehouses eine viel gebrauchte, aber
auch zeitkritische Operation, da enorme Datenmengen pro
Abfrage verarbeitet werden.
• Für die reine Transaktionsverarbeitung (OLTP) weniger
kritisch, da meist nur wenig Daten betroffen.

Merge Sort, Prinzip
• Prinzip: Tabellen zerlegen und Bottom Up sortiert neu aufbauen
• Aufwand: N/k * blog( N/k) * 2
Anzahl IO-Pages
für die ganze Liste
Anzahl Verabeitungsstufen
für die ganze Liste
Lese- und
Schreiboperation

Merge Sort, Mischen von Listen
• Zwei Startlisten L1 und L2
• Drei und mehr Startlisten L1, L2, L3,…
Listenkopf
Mischbuffer
1 3 5
2 4 6
1 4
2 3 5 6
L1
L2
LR
SortHeap
(Proz
Cache)
Listenkopf
Mischbuffer
1 3 5
2 4 6 1 3
1 2 4 5
1 3 7
6 7
5
6
7
L1
L2
L3
LR

Merge Sort, Zahlenbeispiele
• Rechenbeispiele
 Demo
Anzahl
Datensätze
Tabellen-
grösse
(GB)
Anzahl
IO's
(Pages)
Totale Zeit
Disk-basiert
(sec)
Totale Zeit
Flash-basiert
(sec)
Totale Zeit
RAM-basiert
(sec)
OLTP 1.00E+02 0.00 0.00E+00 0.000 0.000 0.000
1.00E+03 0.00 2.00E+01 0.002 0.000 0.000
1.00E+04 0.00 4.00E+02 0.032 0.006 0.000
1.00E+05 0.01 6.00E+03 0.480 0.096 0.005
OLAP 1.00E+06 0.08 8.00E+04 6.400 1.280 0.064
1.00E+07 0.80 1.00E+06 80.000 16.000 0.800
1.00E+08 8.00 1.20E+07 960.000 192.000 9.600
1.00E+09 80.00 1.40E+08 11'200.000 2'240.000 112.000
1.00E+10 800.00 1.60E+09 128'000.000 25'600.000 1'280.000
1.00E+11 8000.00 1.80E+10 1'440'000.000 288'000.000 14'400.000

Ausführungsplan
• Eine Ausführungsplan (QEP) bestimmt, mit welchen Indexzugriffen, mit
welchen Join-Methoden usw. eine Abfrage durchgeführt wird.
• Der Ausführungsplan ist eine Baum-Struktur, deren Blätter Tabellen oder
Indices sind. Die Wurzel des Baumes ist das Resultat der Abfrage.
Geschätzter Zeitbedarf.
Abgleichen mit Testmessung!

Optimierungshinweise
Identifikation von kritischen Teilen des Ausführungsplanes!
 Auf Primär- und Fremdschlüsselattributen einen Index erstellen.
 Für Attribute, die häufig in der order by Klausel auftreten, einen Index
erstellen.
 Indices beschleunigen Abfragen, aber verlangsamen Änderungen.
 Der Boolsche Operator NOT und der Vergleichsoperator <> sind nicht
optimierbar.
 Ausdrücke mit dem Vergleichsoperator LIKE sind nur optimierbar, wenn
allfällige Wildcards nicht am Anfang des Suchmusters stehen.
 Ausdrücke mit einem Funktionsaufruf über einem Attribut sind nicht
optimierbar.  Berechnete Hilfsattribute, welche indexiert werden, z.B.
create table Messung (
messwert numeric(6,2),
grenzwert numeric(6,2),
messwertRelativ as messwert / grenzwert persisted
)
create index ix_messwertRel on Messung( messwertRelativ )

Spezielle Indexe
• Pro Tabelle ist ein Clustered Index möglich. Der Clustered
Index enthält in den Blattknoten direkt die Datensätze.
• Ein Index heisst covering, wenn er alle Attribute enthält,
die in der Abfrage gebraucht werden (insbesondere im
Select-Teil). Für breite Tabellen kann ein Covering Index
aus häufig benützten Attributen sinnvoll sein.
• Bitmap Indexe sind extrem schnell für Attribute mit wenig
Werten (z.B. Geschlecht, Zivilstand, Farbe). Nur einige
DMBS unterstützen Bitmap Indexe, z.B. Oracle.

Demo Query-Optimizer
SQL Server 2008
• Table Scan
• Verwendung eines Index
– Abfrage selektiv
– Abfrage zuwenig selektiv
• Lookup Join
– mit Index auf einer Tabelle
– mit Index auf beiden Tabellen
• Merge Join
• Sortierung

Transaktionssysteme

Weitere ähnliche Inhalte

Andere mochten auch (11)

Ähnlich wie Transaktionssysteme (7)

Transaktionssysteme