KK10_11 Transaktionen

Datenbanken
11 Transaktionen
Karl Meier
[email protected]
23.11.2010
Inhalt
Transaktion
ACID
Isolationsebenen
MySQL Tabellentypen
Transaktion erstellen
COMMIT
ROLLBACK
23.11.2010
11 Transaktionen
2
1
Definition Transaktion
Eine Transaktion (TA) ist eine logisch
zusammengehörige Folge von Datenbankbefehlen, die eine DB von einem logisch
konsistenten Zustand in einen anderen logisch
konsistenten Zustand überführen.
Das Datenbanksystem garantiert bei der
Ausführung einer Transaktion die Einhaltung vier
grundlegender Eigenschaften (ACID Regel).
23.11.2010
11 Transaktionen
3
Ziele
Mehrbenutzerbetrieb
 concurrency control
Fehlertoleranz
 recovery
23.11.2010
11 Transaktionen
4
2
ACID
23.11.2010
Atomicity
´Alles oder nichts´
Consistency
Konsistenz
I solation
Unabhängigkeit
Durability
Dauerhaftigkeit
11 Transaktionen
5
Atomicity
Die Transaktion, die aus einer oder
mehreren Operationen bestehen kann
wird entweder vollständig oder gar nicht
ausgeführt.
Bei einem Fehler werden alle bisherigen
Operationen der Transaktion rückgängig
gemacht (ROLLBACK).
´Alles oder nichts´-Regel
23.11.2010
11 Transaktionen
6
3
Consistency
Eine Transaktion überführt die Datenbank
von einem konsistenten Zustand DBt1 in
einen anderen konsistenten Zustand DBt2.
Konsistenzerhaltung
23.11.2010
11 Transaktionen
7
Isolation
Eine Transaktion sieht keine Zwischenresultate einer anderen, parallel laufenden
Transaktion.
Unabhängigkeit
23.11.2010
11 Transaktionen
8
4
Durability
Änderungen einer Transaktion gehen
auch bei nachfolgenden Fehlersituationen
nie verloren ( Backup / Recovery )
Dauerhaftigkeit
23.11.2010
11 Transaktionen
9
Komponenten der
Transaktionsverwaltung
Concurrency control



Isolation von parallel laufenden Transaktionen
keine Inkonsistenz bei Mehrbenutzerbetrieb
automatische Synchronisationsmechanismen
Recovery


Fehlerhandling (Hardware und Software)
Abbruch (system-, bzw. anwendungsinitiiert)
23.11.2010
11 Transaktionen
10
5
Isolationsebenen
Durch den Transaction Isolation Level wird der
Grad der Parallelität von Transaktionen
gesteuert.
Höherer Level bedeutet:



Höhere Sicherheit für Aktualität der Daten (READ)
Weniger Probleme bezüglich Konsistenz
Geringerer Durchsatz bei grosser Anzahl Zugriffe
23.11.2010
11 Transaktionen
11
SQL2-Standard
Isolationsebene 0:
READ UNCOMMITED
Lesezugriff auf alle Daten
Keine Sperren  dirty read
Isolationsebene 1:
READ COMMITED
Modifizierte Datensätze gesperrt
Non-repeatable read / Phantom
Isolationsebene 2:
REPEATABLE READ
Alle Datensätze gesperrt
Phantom-Problem
Isolationsebene 3:
SERIALIZABLE
Volle Serialisierbarkeit
Keine Probleme
23.11.2010
11 Transaktionen
12
6
Problem 1
Dirty Read
Die Transaktion T1 modifiziert einen
Datensatz. Eine weitere Transaktion T2
liest diesen Datensatz bevor T1 COMMIT
oder ROLLBACK durchgeführt hat. Wenn
nun T1 einen ROLLBACK durchführt, hat
T2 Daten gelesen, die nie festgeschrieben
wurden, also nie wirklich existierten.
23.11.2010
11 Transaktionen
13
Beispiel
w1[x]: Write von Transaktion 1 auf Datensatz x
r2[x]: Read von Transaktion 2 von Datensatz x
a1: ROLLBACK von Transaktion 1
c2: COMMIT von Transaktion 2
P1: w1[x]… r2[x]… (a1 und c2 beliebig)
w1[x=120] r2[x=120] a1 c2
100
23.11.2010
120
100
11 Transaktionen
t
14
7
Problem 2
Non-repeatable oder Fuzzy Read
Die Transaktion T1 liest einen Datensatz.
Eine zweite Transaktion T2 modifiziert
oder löscht diesen Datensatz mit COMMIT.
Falls nun T1 denselben Datensatz
nochmals liest, erhält sie modifizierte
Daten oder stellt fest, dass diese gelöscht
worden sind.
23.11.2010
11 Transaktionen
15
Beispiel
P2: r1[x]… w2[x]… c2… r1[x]… c1
r1[x=100] w2[x=120] c2 r1[x=120] c1
100
23.11.2010
t
120
11 Transaktionen
16
8
Problem 3
Phantom
Die Transaktion T1 liest eine Anzahl
Datensätze anhand einer Suchbedingung.
Eine Transaktion T2 erstellt weitere
Datensätze (COMMIT), welche ebenfalls
diese Suchbedingung erfüllen. Wenn nun
T1 mit denselben Suchbedingungen liest,
resultiert eine andere Datenmenge.
23.11.2010
11 Transaktionen
17
Beispiel
P3: r1[P]… w2[y in P]… c2… r1[P]… c1
r1[SELECT * FROM t_ma WHERE ort=„chur“;]
w2[UPDATE t_ma SET ort=„chur“ WHERE name=„huber“;]
c2
r1[SELECT * FROM t_ma WHERE ort=„chur“;]
c1
2 rows
23.11.2010
11 Transaktionen
t
3 rows
18
9
Zusammenfassung
w1[x]: Write von Transaktion 1 auf Datensatz x
r2[x]: Read von Transaktion 2 von Datensatz x
a1: ROLLBACK von Transaktion 1
c2: COMMIT von Transaktion 2
P1: w1[x]… r2[x]… (a1 und c2 beliebig)
P2: r1[x]… w2[x]… c2… r1[x]… c1
P3: r1[P]… w2[y in P]… c2… r1[P]… c1
23.11.2010
11 Transaktionen
19
ANSI SQL Isolation Levels
Dirty Read
Fuzzy
Read
Phantom
ja
ja
ja
READ COMMITTED
nein
ja
ja
REPEATABLE READ
nein
nein
ja
SERIALIZABLE
nein
nein
nein
Isolation Level
READ UNCOMMITTED
23.11.2010
11 Transaktionen
20
10
Locking
Die meisten SQL Produkte benutzen
Isolation mit Locking Mechanismen.
Read (Share) Lock
Write (Exclusive) Lock
23.11.2010
11 Transaktionen
21
Problem 0
Dirty Write
Die Transaktion T1 modifiziert einen Datensatz.
Eine weitere Transaktion T2 modifiziert diesen
Datensatz bevor T1 COMMIT oder ROLLBACK
durchgeführt hat. Wenn nun T1 oder T2 einen
ROLLBACK durchführen, ist unklar, wie nun der
korrekte Wert aussieht.
P0: w1[x]… w2[x]… ((c1 oder a1) und (c2 oder a2) beliebig)
23.11.2010
11 Transaktionen
22
11
Beispiel
w1[x=120] w2[x=130] c1 c2
100
120
23.11.2010
130
t
?
11 Transaktionen
23
ANSI SQL Isolation Levels
Isolation Level
Dirty
Write
Dirty
Read
Fuzzy
Read
Phantom
READ UNCOMMITTED
nein
ja
ja
ja
READ COMMITTED
nein
nein
ja
ja
REPEATABLE READ
nein
nein
nein
ja
SERIALIZABLE
nein
nein
nein
nein
23.11.2010
11 Transaktionen
24
12
Weitere Probleme
Lost Update
P4: r1[x]… w2[x]… w1[x]… c1
Beispiel:
r1[x=100] r2[x=100] w2[x=120] c2 w1[x=130] c1
t
100
23.11.2010
120
130
11 Transaktionen
25
Lektüre zum Thema
„A Critique of ANSI SQL Isolation Levels“
ftp://ftp.research.microsoft.com/pub/tr/tr-95-51.pdf
Mögliche Anomalien/Phänomene in Datenbanken bei der
Ausführung von Transaktionen im Mehrbenutzerbetrieb
„Generalized Isolation Level Definitions“
http://www.pmg.lcs.mit.edu/papers/icde00.pdf
23.11.2010
11 Transaktionen
26
13
my.cnf Optionsdatei
Die meisten MySQL-Programme können Startoptionen
aus Optionsdateien (auch Konfigurationsdateien
genannt) auslesen.
23.11.2010
11 Transaktionen
27
Beispiel my.cnf
[mysqld]
datadir = /mysql/data
default-storage-engine = InnoDB
transaction-isolation = READ-COMMITTED
Hinweis: Auf Unix-Plattformen ignoriert MySQL
Konfigurationsdateien, die für alle schreibbar (worldwritable) sind. Dies ist beabsichtigt und dient der
Erhöhung der Sicherheit.
23.11.2010
11 Transaktionen
28
14
MySQL Tabellentypen
MySQL kann nicht nur die eigenen
Tabellentypen ISAM/MyISAM handhaben,
sondern weitere wie Archive und solche
von Drittanbietern wie InnoDB.
Standardmässig arbeitet MySQL ab
Version 3.23 mit MyISAM.
Der Tabellentyp lässt sich mit der Klausel
ENGINE beim Erzeugen der Tabelle
angeben.
23.11.2010
11 Transaktionen
29
Speicherorte
MySQL erzeugt beim Erstellen einer
Tabelle immer eine Datei tabelle.frm.
Diese enthält die Tabellen- und
Spaltendefinitionen.
Abhängig vom Tabellentyp werden Index und
Daten in anderen Dateien gespeichert.
SHOW VARIABLES LIKE ´datadir´;
23.11.2010
11 Transaktionen
30
15
Tabellendateien
MySQL Datenbanken als Verzeichnisse
MySQL MyISAM Tabellen als Dateien



tabelle.frm
tabelle.MYD
tabelle.MYI
23.11.2010
Tabellenschema
MyISAM Tabellendaten
MyISAM Indizes
11 Transaktionen
31
Gross-/Kleinschreibung
Windows:
mysql> CREATE DATABASE Sammlung;
Query OK, 1 row affected (0.00 sec)
mysql> USE sammlung;
Database changed
UNIX:
mysql> CREATE DATABASE Sammlung;
Query OK, 1 row affected (0.00 sec)
mysql> USE sammlung
ERROR 1049: Unknown database ‘sammlung’
SHOW VARIABLES LIKE ´lower_case_table_names´;
23.11.2010
11 Transaktionen
32
16
lower_case_table_names
Benutzen Sie lower_case_table_names=0 unter Unix
und lower_case_table_names=2 unter Windows/OSX.
23.11.2010
11 Transaktionen
33
MySQL eigene Tabellentypen
Archive
Blackhole
CSV
Falcon
Federated
InnoDB
Memory
Merge
MyISAM
NDB/MySQL Cluster
23.11.2010
11 Transaktionen
34
17
Archive
Ab MySQL 5.0
Für historische/archivierte Daten
Komprimiert gespeicherte Daten
Nur INSERT und SELECT
Keine Indizes möglich
Priorität Platzbedarf / Performance nicht relevant
ENGINE=ARCHIVE
23.11.2010
11 Transaktionen
35
Blackhole
Ab MySQL 5.0
„Schwarzes Loch“ für Daten
Keine Datenspeicherung
BLACKHOLE wurde entwickelt, um die Syntax von
SQL-Statements zu prüfen und ein Binärlog zu
schreiben.
ENGINE=BLACKHOLE
23.11.2010
11 Transaktionen
36
18
CSV
Ab MySQL 5.1
Speichert Daten als CSV-Textfile und erlaubt
damit flat-file Datenmanipulation
Keine Transaktionen und Foreign Keys
Kein Index Support
Eingeschränkte Sicherheit
Einfacher Zugriff auf externe Datenquellen
ENGINE=CSV
23.11.2010
11 Transaktionen
37
Falcon
Ursprünglich geplant 2010als Ersatz für die
InnoDB
ACID Transaktionssupport
Hohe Performance
Entwicklung am 13.4.2010 durch Oracle
eingestellt
23.11.2010
11 Transaktionen
38
19
Federated
Ab MySQL 5.0
Logische Datenbank aus mehreren
physikalischen Datenbanken, welche auf
verschiedenen Servern liegen
Im Moment auf MySQL 5.1 aus
Qualitätsgründen und anderen Prioritäten
deaktiviert
ENGINE=FEDERATED
23.11.2010
11 Transaktionen
39
Federated Syntax
CREATE TABLE sys_client (
# list all your attributes here
)
ENGINE = FEDERATED
DEFAULT CHARSET = utf8
COMMENT = 'write your comment here'
CONNECTION = 'mysql://user:[email protected]:3306/
testDB/sys_client';
Die Federated Engine muss in der my.cnf Datei
enabled sein.
23.11.2010
11 Transaktionen
40
20
InnoDB
Bietet transaktionsunterstützung
Fremdschlüssel möglich
Seit 2005 bei Oracle
ENGINE=INNODB
23.11.2010
11 Transaktionen
41
Memory
Sehr schnell
Nicht persistent
Daten nur im Memory gespeichert
Nur Tabellenstruktur auf der Festplatte
Nicht alle Datentypen unterstützt
ENGINE=MEMORY
23.11.2010
11 Transaktionen
42
21
Merge
Verbindet mehrer MyISAM Tabellen zu einer einzigen
logischen
Keine Speicherlimite
Beschränkter SQL Befehlssatz
 SELECT, (INSERT), UPDATE, DELETE
DROP einer MERGE-Tabelle löscht nur deren MERGESpezifikation, keine Daten
ENGINE=MERGE
UNION=(tabelle1, tabelle2,…)
INSERT_METHOD=FIRST|LAST
23.11.2010
11 Transaktionen
43
MyISAM
Ab Version 3.23 Standard-Tabellentyp
Hardware- und Betriebssystemunabhängig
Transaktionen sind nicht unterstützt
Speicherung als Dateien
 tabelle.frm:
Tabellenstruktur
 tabelle.MYD:
Daten
 tabelle.MYI:
Index
ENGINE=MyISAM
23.11.2010
11 Transaktionen
44
22
NDB / MySQL Cluster
ACID-Transaktionen unterstützt
Hohe Verfügbarkeit (bis 99.999%)
Eingebaute Clustering Mechanismen
Shared Nothing Architektur
Keine Foreign Key Unterstützung
ENGINE=NDB
23.11.2010
11 Transaktionen
45
Defaulttyp
Der Default-Tabellentyp kann mit einer
Startoption des Servers, bzw. einem
Eintrag in der Konfigurationsdatei my.cnf
gesetzt werden.
[mysqld]
default-table-type=myisam
23.11.2010
11 Transaktionen
46
23
Third-Party Storage Engines
IBMDB2I
MariaDB
PBXT
ScaleDB
XtraDB
23.11.2010
11 Transaktionen
47
IBMDB2I
Diese Engine ist ein Adapter, welches Zugriff auf
DB2 Tabellen auf der i5 Plattform von IBM
erlaubt. Der Zugriff erfolgt über ein MySQL
basiertes Interface.
Natives DB2 Format für Datenspeicherung
Zugriff via MySQL oder native i5 Anwendungen
23.11.2010
11 Transaktionen
48
24
MariaDB
Monty Program AB
Alpha Release
Fork der MyISAM Engine
Transaktionssupport geplant
Erweiterungen Data Warehouse geplant
23.11.2010
11 Transaktionen
49
PBXT
PrimeBase XT von SNAP Innovation GmbH
www.primebase.org
23.11.2010
11 Transaktionen
50
25
ScaleDB
ScaleDB Inc.
Transaktionsfähig
Hohes Datenvolumen, hohe Verfügbarkeit
Shared Disk Clustering Architektur
Beta Release
www.scaledb.com
23.11.2010
11 Transaktionen
51
XtraDB
Clone der InnoDB Engine
www.percona.com Peter Zaitsev
Multiple Rollback
Performance Diagnostic
Speed Enhancement
23.11.2010
11 Transaktionen
52
26
InnoDB
InnoDB ergänzt MySQL mit einem Transaction
Handler und Foreign Keys.
Internet: http://www.innodb.com
http://www.innodb.com/support/documentation
InnoDB Engine in MySQL: Reference Manual
23.11.2010
11 Transaktionen
53
Datenspeicherung
23.11.2010
11 Transaktionen
54
27
Allgemeines zu InnoDB 1
InnoDB ist MyISAM dann überlegen, wenn eine
Anwendung viele Einfügevorgänge oder
Aktualisierungen in Tabellen vornimmt. Bei
Lesevorgängen ist MyISAM in der Regel
schneller.
InnoDB unterstützt Transaktionen und
referentielle Integrität.
InnoDB und MyISAM lassen sich gleichzeitig
nutzen, auch in einem Statement (z.B. in Joins).
23.11.2010
11 Transaktionen
55
Allgemeines zu InnoDB 2
InnoDB Tabellen benötigen mehr Speicherplatz
als MyISAM Tabellen. (Etwa doppelt so viel)
InnoDB Tabellen lesen in SELECT Statements
nur die angegebenen Spalten. MyISAM Tabellen
werden aber datensatzweise eingelesen und
anschliessend entsprechend berechnet. Daher
sind InnoDB Tabellen MyISAM Tabellen bei sehr
grossen Datensätzen in der Regel überlegen.
23.11.2010
11 Transaktionen
56
28
InnoDB Tabellen
mysql> CREATE TABLE customer (a INT, b CHAR(20), INDEX (a))
-> ENGINE = InnoDB;
Query OK, 0 rows affected (0.26 sec)
oder:
default-table-type=innodb
23.11.2010
im My.cnf file
11 Transaktionen
57
Konversion MyISAM zu InnoDB
Systemtabellen (mysql) nicht konvertieren!
ALTER TABLE tabelle ENGINE=InnoDB;
Achtung: InnoDB Tabellen belegen bedeutend
mehr Platz als MyISAM Tabellen.
23.11.2010
11 Transaktionen
58
29
Foreign Keys
CREATE TABLE t_parent (id INT NOT NULL,
PRIMARY KEY (id)) TYPE=InnoDB;
CREATE TABLE t_child (id INT, parent_id INT,
INDEX i_par (parent_id),
FOREIGN KEY (parent_id) REFERENCES t_parent(id)
ON DELETE CASCADE
) ENGINE=InnoDB;
InnoDB erstellt die Indizes auf Fremdschlüssel und
referenzierte Schlüssel nicht automatisch, daher
müssen diese explizit erstellt werden.
23.11.2010
11 Transaktionen
59
Foreign Keys anzeigen
SHOW CREATE TABLE tabelle;
23.11.2010
11 Transaktionen
60
30
Beispiel
mysql> SHOW CREATE TABLE t_ma_proj;
+-----------+-------------------------------------------------+
| Table
| Create Table
+-----------+-------------------------------------------------+
| t_ma_proj | CREATE TABLE `t_ma_proj` (
`ma_id` int(11) NOT NULL default '0',
`proj_id` int(11) NOT NULL default '0',
PRIMARY KEY (`ma_id`,`proj_id`),
KEY `i_ma` (`ma_id`),
KEY `i_proj` (`proj_id`),
FOREIGN KEY (`proj_id`) REFERENCES `mav.t_proj` (`proj_id`)
ON DELETE CASCADE,
FOREIGN KEY (`ma_id`) REFERENCES `mav.t_ma` (`id`)
ON DELETE CASCADE
) ENGINE=InnoDB |
-+-----------+------------------------------------------------+
1 row in set (0.00 sec)
23.11.2010
11 Transaktionen
61
Transaktionen mit InnoDB
Row Level Locking
Default ist REPEATABLE READ
Ab MySQL 4.0.5 alle 4 Isolationslevel
transaction-isolation = … im File my.cnf
23.11.2010
11 Transaktionen
62
31
Transaktionen mit MySQL
MySQL started per Default im AUTOCOMMIT
Modus, d.h. jedes SQL Statement wird sofort in
der DB festgeschrieben.
Für Transaktionen muss daher entweder
SET AUTOCOMMIT = 0; gesetzt oder
BEGIN; … COMMIT; bzw.
BEGIN; … ROLLBACK; verwendet werden.
23.11.2010
11 Transaktionen
63
SET TRANSACTION
SYNTAX
SET [GLOBAL | SESSION] TRANSACTION ISOLATION LEVEL
[READ UNCOMMITTED | READ COMMITTED |
REPEATABLE READ | SERIALIZABLE]
Setzt die Transaktionsisolationsebene global, für die gesamte Sitzung oder
für die nächste Transaktion.
Default: Setzen der Isolationsebene für die nächste Transaktion.
GLOBAL betrifft alle neu erzeugten Threads. (PROCESS-Privileg)
SESSION betrifft die folgenden und alle zukünftigen Transaktionen.
Default-Isolationsebene für mysqld mit --transaction-isolation=... setzen.
23.11.2010
11 Transaktionen
64
32
Achtung !!!
Folgende Befehle beenden eine
Transaktion automatisch (COMMIT):







ALTER TABLE
BEGIN
CREATE INDEX
DROP DATABASE
DROP TABLE
RENAME TABLE
TRUNCATE
23.11.2010
11 Transaktionen
65
Transaktion und Lock‘s
Die Serialisierbarkeit von Transaktionen wird
durch sogenannte Locks erreicht, die
konkurrierende Aktionen mit einem Datensatz
verhindern.
Ein Datensatz kann drei Zustände aufweisen:

unlocked

read-locked (shared lock)

write-locked (exclusive lock)
23.11.2010
11 Transaktionen
66
33
Zweiphasen Sperrprotokolle
Two Phase Locking
Grundregeln




R1: Sperranforderung vor jedem Objektzugriff
R2: Sperren paralleler Transaktionen dürfen
nicht in Konflikt zueinander stehen
R3: Nicht mehrere Sperren für ein Objekt
innerhalb einer Transaktion
R4: Bei Transaktionsende sind alle Sperren
freizugeben
23.11.2010
11 Transaktionen
67
Two-phase locking
Um zu garantieren, dass alle Paare von
Operationen in zwei Transaktionen, die einen
Konflikt hervorrufen, in der gleichen Reihenfolge
durchgeführt werden (serial equivalence), darf
eine Transaktion, sobald sie einmal einen Lock
freigegeben hat kein weiteres Datenelement
mehr locken. Daraus folgt, das jede Transaktion
in zwei Phasen zerlegt werden kann: In der
growing phase fordert die Transaktion Locks an
und in der shrinking phase gibt sie diese Locks
wieder frei.
Das wird auch two-phase-locking genannt.
23.11.2010
11 Transaktionen
68
34
Two-Phase-Locking
write lock (lock promotion)
unlock
read lock
write lock
unlock
1
exclusive
lock
23.11.2010
unlocked
read lock
read lock
2
unlock
…
unlock
shared lock
11 Transaktionen
69
Two-Phase-Locking
Das Two-Phase Locking Protokoll fordert:
Vor jeder Leseaktion r[x] ein readlock[x]
Vor jeder Schreibaktion w[x] ein writelock[x]
Für jedes lock muss ein unlock durchgeführt werden



Frühester Zeitpunkt für Freigabe (unlock) ist:


Kein weiterer Zugriff mehr auf Datenobjekt
Keine weiteren lock Operationen folgen
23.11.2010
11 Transaktionen
70
35
Beispiel
Transaktion T:
Transaktion U:
Bank_Belastung(Konto A, 100 sFr.)
Bank_Belastung(Konto C, 200 sFr.)
Bank_Gutschrift(Konto B, 100 sFr.)
Bank_Gutschrift(Konto B, 200 sFr.)
Operation
Operation
Locks
Locks
Begin Transaction
Saldo := A.Read()
read lock A
A.Write(Saldo -100)
write lock A
Begin Transaction
Saldo := B.Read()
read lock B
B.Write(Saldo+100)
write lock B
End Transaction
unlock A, B
23.11.2010
Saldo := C.Read()
read lock C
C.Write(Saldo -200)
write lock C
Saldo := B.Read()
wartet wegen T lock auf B
…
…
read lock B
B.Write(Saldo+200)
write lock B
End Transaction
unlock B, C
11 Transaktionen
71
Domino Effekt
Transaktionen
T1:
T2:
lock(acc1)
read(acc1)
acc1 := acc1 + 100
write(acc1)
unlock acc1
lock(acc1), lock(acc2)
read(acc1), read(acc2)
acc1 := acc1 - 100
acc2 := acc2 +100
write(acc1), write(acc2)
unlock(acc1), unlock(acc2)
commit
abort
23.11.2010
11 Transaktionen
72
36
Strict Two-Phase-Locking
Wenn die Transaktionen ihre Locks bis zum
Commit oder Abort behalten und diese erst dann
wieder freigeben, so nennt man dies strict twophase-locking.
Strict two-phase-locking wird verwendet, da
beim two-phase-locking noch nicht feststeht, ob
ein Datenelement, dem der Lock entzogen
wurde, bevor die Transaktion ein COMMIT
durchführt, wirklich den korrekten Wert enthält
(und daher von anderen Transaktionen schon
gelesen werden darf), da die Transaktion ja
auch abgebrochen werden könnte.
23.11.2010
11 Transaktionen
73
Deadlock
Tritt immer dann auf, wenn zwei oder mehrere
konkurrierende Prozesse nicht beendet werden
können, weil diese darauf warten, dass der
jeweils andere Prozess Resourcen freigibt, die
der andere zum Lesen oder Schreiben gesperrt
hat. Bei Datenbanken, deren Lockmechanismen
(ROW/COLUMN/CELL/TABLE LOCKING) zu
grob differenziert sind, entstehen hierdurch oft
lange Reaktionszeiten.
Häufiger ist allerdings falsche Programmierung
die Ursache.
23.11.2010
11 Transaktionen
74
37
Beispiel
Transaktion T:
Transaktion U:
Bank_Belastung(Konto A, 100 sFr.)
Bank_Belastung(Konto C, 200 sFr.)
Bank_Gutschrift(Konto B, 100 sFr.)
Bank_Gutschrift(Konto B, 200 sFr.)
Operation
Operation
Locks
Locks
Begin Transaction
Saldo := A.Read()
read lock A
Begin Transaction
A.Write(Saldo-100)
write lock A
Saldo := B.Read()
read lock B
B.Write(Saldo+100)
wartet auf U
23.11.2010
Saldo := C.Read()
read lock C
C.Write(Saldo -200)
write lock C
Saldo := B.Read()
shares read lock B
B.Write(Saldo+200)
wartet auf T
11 Transaktionen
75
Möglichkeiten im Umgang mit
Deadlocks
Vermeidung


einfach, aber nicht unbedingt gut
zu restriktiv, Zugriffsbeschränkung
Erkennung

Aufgabe des Lock Managers
Timeout



Lock wird nach Timeout „verletzlich“ und die
ursprüngliche Transaktion bricht ab
Gefahr des Abbruchs auch ohne Deadlock
Problem bei lange andauernden Transaktionen
23.11.2010
11 Transaktionen
76
38
Lock Manager
Die Clients haben natürlich keinen Zugriff
zu Operationen für das Locking oder
Unlocking, da ja sonst die Protokolle von
trickreichen Programmierern verletzt
werden könnten.
Diese Funktionen werden vom lock
manager - einem Serverprogramm durchgeführt.
23.11.2010
11 Transaktionen
77
Locks in MySQL InnoDB
SELECT … FROM …;
setzt keine locks (consistent read), Snapshot
SELECT … FROM … LOCK IN SHARED MODE;
setzt shared lock auf alle resultierenden Sätze
SELECT … FROM … FOR UPDATE;
setzt exclusive lock auf alle resultierenden Sätze
23.11.2010
11 Transaktionen
78
39
Zeitstempel Verfahren
Vor allem bei verteilten Datenbanken
kommt das Zeitstempel-Verfahren zur
Anwendung. Anstelle von Sperren, wird
eine Transaktion mit einer drohenden
Verletzung der Serialisierbarkeitskriterien
abgebrochen und neu gestartet.
Dieses Verfahren soll präventiv
verhindern, dass Deadlocks entstehen
können.
23.11.2010
11 Transaktionen
79
MVCC
Multiversioning Concurrency Control
MVCC benutzt Transaktions-IDs um eine Serialisierung
zu erreichen. MVCC stellt sicher, dass eine Transaktion
nie auf Datenbankobjekte warten muss und verwaltet die
verschiedenen Versionen eines Objektes.
Jede Version eines Objektes P besitzt einen LeseZeitstempel RTS(P) (read timestamp), der den
Startzeitstempel TS(T) derjenigen Transaktion T angibt,
die P zuletzt gelesen hat. Wenn Ti dieses Objekt P
ändert und TS(Ti) < RTS(P)=TS(T) gilt, dann wird die
Transaktion Ti abgebrochen und neu gestartet.
Andernfalls erstellt Ti eine neue Version von P und setzt
den Lese/Schreib Zeitstempel von P auf TS(Ti).
23.11.2010
11 Transaktionen
80
40
Scheduler
Der Scheduler gewährleistet die Koordination
der verschiedenen Transaktionen.
Die Bearbeitung von Zugriffskonflikten geschieht
dabei zum einen pessimistisch (also zum
Zeitpunkt des Zugriffs durch die Massnahme des
Sperrens oder mittels eines Zeitstempels (als
Abbruch und Neustart)) und zum anderen
optimistisch (also am Ende der Transaktion
durch einen vorwärts gerichteten oder rückwärts
gerichteten Validierer (als jeweiligen Abbruch
und Neustart)).
23.11.2010
11 Transaktionen
81
Validierer
Ausgangspunkt ist die Tatsache/Annahme, dass
Konflikte eher selten auftreten. Der Validierer
(certifier) bearbeitet die Transaktionen auf der
Grundlage von Datenbereichen, in denen die
Menge der aktiven Transaktionen, die Menge
der gelesenen Datenelemente und die Menge
der geschriebenen Datenelemente gespeichert
wird. Im Konfliktfall setzt der Validierer die
Transaktion auf Abort, sonst auf Commit.
23.11.2010
11 Transaktionen
82
41
Savepoints
InnoDB unterstützt die SQL Statements
SAVEPOINT und ROLLBACK TO
SAVEPOINT.
SAVEPOINT identifier
ROLLBACK TO SAVEPOINT identifier
23.11.2010
11 Transaktionen
83
Transaktionsfähige Engines
23.11.2010
11 Transaktionen
84
42
Data Warehouse Engines
Calpont

www.calpont.com
InfoBright - BrightHouse

www.infobright.org
Kickfire

www.kickfire.com
TokuDB

www.tokutek.com
23.11.2010
11 Transaktionen
85
23.11.2010
11 Transaktionen
86
43