9. Transaktionsverwaltung Der Scheduler

9. Transaktionsverwaltung
Der Scheduler
Architektur der Transaktionsverwaltung
T1
T2
Tn
Sperrende und nicht-sperrende Verfahren
TransaktionsManager (TM)
Transaktionen in SQL-Systemen
Transaktionsmonitore
Scheduler (SC)
korrekter Schedule
(bestehend aus r, w, c, a)
Speicher
Manager (SM)
Recovery
Manager (RM)
Puffer
Manager (PM)
DB
VL Datenbank-Implementierungstechniken – 9–1
Transaktionsoperationen
VL Datenbank-Implementierungstechniken – 9–2
Zustände einer Transaktion
active
Transaktionsklammern
BOT (Begin of Transaction)
execute
EOT (End of Transaction)
initial
Schritte:
delay
BOT
running
delayed
restart
r (read),
retry
w (write),
reject
a (abort), und
c (commit).
stop
aborted
EOT
committed
stopped
t = {r|w}∗ (a|c)
VL Datenbank-Implementierungstechniken – 9–3
VL Datenbank-Implementierungstechniken – 9–4
Behandlung eines Schritts
Aggressive Scheduler
ausführen (execute)
ein Scheduler ist aggressiv, wenn er Konflikte zuläßt
Transaktion → Zustand running.
und dann versucht, aufgetretene Konflikte zu erkennen
und aufzulösen
verzögern (delay)
Transaktion → Zustand delayed
maximiert die Parallelität von Transaktionen
zurückweisen (reject)
Risiko: Transaktionen werden erst am Ende ihrer
Transaktion → Zustand aborted
Ausführung zurückgesetzt
VL Datenbank-Implementierungstechniken – 9–5
Konservative Scheduler
VL Datenbank-Implementierungstechniken – 9–6
Sperrmodelle
ein Scheduler arbeitet konservativ, wenn er Konflikte
möglichst vermeidet, dafür aber Verzögerungen von
Transaktionen in Kauf nimmt
erlauben nur eine geringe Parallelität von
Schreib- und Lesesperren in folgender Notation:
rl(x): Lesesperre (engl. read lock ) auf einem Objekt x
wl(x): Schreibsperre (engl. write lock ) auf einem
Objekt x
Transaktionen
Entsperren ru(x) und wu(x), oft zusammengefaßt u(x) für
engl. unlock
minimieren den Rücksetzungsaufwand für
abgebrochene Transaktionen
im Extremfall findet keine Parallelisierung von
Transaktionen mehr statt, d.h., es werden immer alle
Transaktionen bis auf eine verzögert
VL Datenbank-Implementierungstechniken – 9–7
VL Datenbank-Implementierungstechniken – 9–8
Verklemmungen
Sperrdisziplin
Schreibzugriff w(x) nur nach Setzen einer
t1
wl(x)
Schreibsperre wl(x) möglich
Lesezugriffe r(x) nur nach d rl(x) oder wl(x) erlaubt
nur Objekte sperren, die nicht bereits von einer
anderen Transaktion gesperrt
wl(y)
delay → wl(y)
wl(x)
Verklemmung!
nach rl(x) nur noch wl(x) erlaubt, danach auf x keine
Sperre mehr; Sperren derselben Art werden maximal
einmal gesetzt
nach u(x) durch ti darf ti kein erneutes rl(x) oder
wl(x) ausführen
t2
← delay
Alternativen:
Verklemmungen werden erkannt und beseitigt
Verklemmungen werden von vornherein vermieden
vor einem commit müssen alle Sperren aufgehoben
werden
VL Datenbank-Implementierungstechniken – 9–9
Erkennung und Auflösung
VL Datenbank-Implementierungstechniken – 9–10
Livelock-Problem
1. T1 sperrt A
Wartegraph
6
5
4
2. T2 will A sperren, muß aber warten
neue
Sperre
1
2
3. T3 will danach A sperren, muß auch warten
4. T1 gibt A frei
5. T3 kommt vor T2 an eine Zeitscheibe, sperrt A
3
Auflösen durch Abbruch einer Transaktion, Kriterien:
6. T2 will weiterhin A sperren, muß aber warten
Anzahl der aufgebrochenen Zyklen,
7. T4 will danach A sperren, muß auch warten
Länge einer Transaktion,
8. T3 gibt A frei
Rücksetzaufwand einer Transaktion,
9. T4 kommt vor T2 an die nächste Zeitscheibe ...
Wichtigkeit einer Transaktion, ...
VL Datenbank-Implementierungstechniken – 9–11
VL Datenbank-Implementierungstechniken – 9–12
Zwei-Phasen-Sperr-Protokoll
Sperrprotokolle: Notwendigkeit
T2
#Sperren
T1
wl(x)
w(x)
u(x)
wl(x)
w(x)
u(x)
wl(y)
w(y)
u(y)
2PL
AnforderungsPhase
FreigabePhase
Zeit
wl(y)
w(y)
u(y)
VL Datenbank-Implementierungstechniken – 9–13
T1
Striktes Zwei-Phasen-Sperr-Protokoll
#Sperren
Konflikt bei Nichteinhaltung des 2PL
VL Datenbank-Implementierungstechniken – 9–14
T2
u(x)
wl(x)
wl(y)
..
.
S2PL
AnforderungsPhase
u(x)
u(y)
Zeit
wl(y)
..
.
Freigabe-Phase
vermeidet kaskadierende Abbrüche!
VL Datenbank-Implementierungstechniken – 9–15
VL Datenbank-Implementierungstechniken – 9–16
#Sperren
#Sperren
Konservatives 2PL-Protokoll
C2PL
Sperrgranulate
Granularitätshierarchien in Datenbanken
Hierarchische Sperren
CS2PL
FreigabePhase
Baumprotokolle für Baumindexe
Zeit
Zeit
AnforderungsPhase
AnforderungsPhase
FreigabePhase
vermeidet Deadlocks!
VL Datenbank-Implementierungstechniken – 9–17
Granularitätshierarchien in RDBS
VL Datenbank-Implementierungstechniken – 9–18
Hierarchische Sperren
Granularitätshierarchien
Sperren pflanzen sich nach unten (in Richtung der
Blätter) fort
Datenbank
Datenbank
Relation
Datei
Tupel
Cluster
Attribut
Seite
Logisch
Physisch
Sperren dürfen nicht von oben (von der Wurzel her)
überschrieben werden
Zusätzlich: intentionale Sperren (engl. intentional
locks)
Warnungen vor Sperren, die sich in der Hierarchie
weiter unten befinden
irl (intentionale Lesesperre) und iwl (intentionale
Schreibsperre)
VL Datenbank-Implementierungstechniken – 9–19
VL Datenbank-Implementierungstechniken – 9–20
Kompatibilitätsmatrix
Kompatibilitätsmatrix
für elementare Sperren
rlj (x)
wlj (x)
für hierarchische Sperren
rli (x) wli (x)
√
—
—
—
rlj (x)
wlj (x)
irlj (x)
iwlj (x)
riwlj (x)
rli (x) wli (x) irli (x) iwli (x) riwli (x)
√
√
—
—
—
—
—
—
—
—
√
√
√
√
—
√
√
—
—
—
√
—
—
—
—
VL Datenbank-Implementierungstechniken – 9–21
Ablauf des hierarchischen Sperren
1. Sperren werden auf einem Pfad in der Reihenfolge von
der Wurzel zum Zielobjekt gesetzt
2. Datenobjekt, auf dem gearbeitet werden soll, wird
gesperrt: Schreib- oder Lesesperre (dabei
Sperrenverträglichkeitsmatrix beachten!)
3. Alle anderen Knoten auf dem Pfad bekommen
intentionale Sperren
4. Sperren können verschärft werden, das heißt ein rl
kann zum wl werden, ein irl zum rl und ein irl zum iwl
VL Datenbank-Implementierungstechniken – 9–22
Hierarchisches Sperren: Beispiel I
T1
T2
BetriebsDB
Mitarbeiter
rl (implizit)
iwl (explizit)
(BetriebsDB)
Relation
rl (explizit)
Tamara, ..., Mario
BetriebsDB
Datenbank
irl (explizit)
Tupel
(Tamara Jagellowsk)
Relation
...
(Mitarbeiter)
...
(Projekt)
Mitarbeiter
iwl (explizit)
Tupel
(Mario De Monti)
5. Freigabe erfolgt in umgekehrter Reihenfolge
Gehalt, ..., Telefon
rl (implizit)
VL Datenbank-Implementierungstechniken – 9–23
Attribut
(Gehalt)
...
Attribut
(Telefon)
VL Datenbank-Implementierungstechniken – 9–24
Hierarchisches Sperren: riwl
Hierarchisches Sperren: Beispiel II
T1
T2
BetriebsDB
Mitarbeiter
Tamara
iwl (explizit)
(BetriebsDB)
Relation
irl (explizit)
irl (explizit)
BetriebsDB
Datenbank
irl (explizit)
Tupel
(Tamara Jagellowsk)
Relation
...
(Mitarbeiter)
...
(Projekt)
Tupel
(Mario De Monti)
Mitarbeiter
iwl (explizit)
Tamara
iwl (explizit)
T1 sperrt
T2 sperrt
BetriebsDB
Gehalt
Attribut
(Gehalt)
...
Attribut
(Telefon)
irl (explizit)
(BetriebsDB)
Mitarbeiter
Relation
riwl (explizit)
Mitarbeiter
Relation
...
(Mitarbeiter)
irl (explizit)
(Projekt)
Tamara, ..., Mario
rl (implizit)
Tupel
Tamara
(Tamara Jagellowsk)
wl (explizit)
rl (explizit)
BetriebsDB
Datenbank
riwl (explizit)
...
Mario
Tupel
rl (explizit)
(Mario De Monti)
Telefon
wl (explizit)
VL Datenbank-Implementierungstechniken – 9–25
Sperren in Indexstrukturen
VL Datenbank-Implementierungstechniken – 9–26
Beispiel Baumprotokoll
lock A; lock B; unlock A; lock D
Baumprotokoll
1. Objekt o kann nur dann von T gesperrt werden, wenn
sein direkter Vorgänger bereits von T gesperrt ist
A
2. erste Regel gilt nicht für die erste Sperre einer
Transaktion
B
3. Sperren können jederzeit wieder freigegeben werden
4. Kein Objekt kann innerhalb einer Transaktion T
zweimal gesperrt werden
D
E
F
VL Datenbank-Implementierungstechniken – 9–27
C
G
VL Datenbank-Implementierungstechniken – 9–28
Baumprotokolleigenschaften
Ablauf im Baumprotokoll
T1
lock A
lock B
lock D
unlock B
T2
T3
Baumprotokoll erzwingt nicht 2PL!
Falls alle Transaktionen dem Baum-Protokoll genügen, ist jeder korrekte Schedule serialisierbar.
lock B
lock C
lock E
unlock D
lock F
unlock A
lock G
unlock C
unlock E
lock E
unlock F
unlock B
unlock G
unlock E
VL Datenbank-Implementierungstechniken – 9–29
Nicht-sperrende Verfahren
VL Datenbank-Implementierungstechniken – 9–30
Zeitmarkenverfahren
Zeitstempelbasierte Verfahren erzwingen eine korrekte
Reihenfolge der Bearbeitungsschritte mittels
geeigneter Markierungen der Transaktionen
Serialisierbarkeitstester verwalten einen
Zeitmarken sind eindeutig und werden fortlaufend
vergeben.
Für jedes Datenobjekt x werden zwei Werte geführt:
max-r-scheduled[x]:
Konfliktgraphen, und realisieren daher eine direkte
Überprüfung der Konfliktserialisierbarkeit
Zertifikatoren führen zunächst die kompletten
Transaktion aus und versuchen erst am Ende
festzustellen, ob die Transaktion gemäß dem
Serialisierbarkeitsbegriffs abgelaufen sind
VL Datenbank-Implementierungstechniken – 9–31
Variable, die den Zeitstempel der letzten
Leseoperation auf x enthält
max-w-scheduled[x]:
Variable, die den Zeitstempel der letzten
Schreiboperation auf x enthält
VL Datenbank-Implementierungstechniken – 9–32
Timestamp-Ordering-Regel
Basis-TO-Algorithmus
Eine Operation pi [x] wird vor qk [x] genau dann ausgeführt, wenn ts(Ti ) < ts(Tk ) gilt.
p und q: inkompatible Operationen der Transaktionen
Ti bzw. Tk (i 6= k) auf einem Objekt x
ts(Ti ) bzw. ts(Tk ) sind Zeitstempel der Transaktionen
Ti bzw. Tk
Formal:
Sind pi (x) und qj (x) in Konflikt, so gilt:
pi (x) wird vor qj (x) ausgeführt ⇐⇒ ts(Ti ) < ts(Tj ).
if pi [x] ist eingetroffen then
if pi [x] ist ri [x] then
if ts(Ti ) < max-w-scheduled[x] then
weise Operation zurück;
else
max-r-scheduled[x] :=
max(max-r-scheduled[x], ts(Ti ));
gebe Operation weiter;
else /* pi [x] ist wi [x] */
if ts(Ti ) < max-w-scheduled[x] or
ts(Ti ) < max-r-scheduled[x] then
weise Operation zurück;
else
max-w-scheduled[x] := ts(Ti );
gebe Operation weiter;
VL Datenbank-Implementierungstechniken – 9–33
Nachteile und Vorteile der TO-Verfahren
Nachteil: Anfälligkeit gegen stark variierende
Laufzeiten von Transaktionen
lang andauernde Transaktionen bearbeiten ihre
letzten Schritte längere Zeit nach der Vergabe der
Zeitmarke
kommen damit mit diesen Schritten mit größerer
Wahrscheinlichkeit „zu spät“
Vorteil: einfache Realisierung in verteilten Systemen
VL Datenbank-Implementierungstechniken – 9–35
VL Datenbank-Implementierungstechniken – 9–34
Zeitmarkenverfahren: Ablauf
T1
ts = 200
T2
ts = 150
T3
ts = 175
read B
read A
read C
write B
write A
A
B
C
mrs
mws
mrs
mws
mrs
mws
0
0
0
0
0
0
0
0
200
0
0
0
150
0
200
0
0
0
150
0
200
0
175
0
150
0
200
200
175
0
150
200
200
200
175
0
write C ⇓
150
200
200
200
175
⇓
abort
150
200
200
200
175
0
VL Datenbank-Implementierungstechniken – 9–36
Optimiertes Zeitmarkenverfahren
Opt. Zeitmarkenverfahren: Ablauf
Optimierte BTO-Regel:
T1
T2
T3
A
ts = 200
ts = 150
ts = 175
bei negativen Ausgang des Vergleichs einer
schreibenden Transaktion mit der
max-w-scheduled-Marke wird das Schreiben ignoriert
sofern kein Konflikt mit der max-w-scheduled-Marke
auftritt
alter Wert von max-w-scheduled wird übernommen
und die Transaktion läuft weiter
read A
C
mrs
mws
mrs
mws
0
0
0
0
150
0
0
0
read C
150
0
175
0
200
175
0
write A
150
√
150
200 (⇓)
175
0
write A
√
; „Optimierung für blindes Schreiben“
VL Datenbank-Implementierungstechniken – 9–37
Livelocks im Zeitmarkenverfahren
T1
ts = 100
T2
ts = 110
T10
ts = 120
T20
ts = 130
write B
write A
read A ⇓
write B
read B ⇓
write A
read A ⇓
VL Datenbank-Implementierungstechniken – 9–38
Serialisierbarkeitsgraphentester
A
Problem: Bereinigen des Konfliktgraphens
B
mrs
mws
mrs
mws
0
0
0
0
0
0
0
100
0
110
0
100
0
110 ⇓
0
100
0
110
0
120
0
110
0
120 ⇓
0
130
0
120
0
130 ⇓
0
120
r0 (x) w1 (x)w1 (y1 )c1 ... wn (x)wn (yn )cn w0 (z)
|
{z
} |
{z
}
T1
Tn
t
0
t
t
1
2
.
.
.
t
VL Datenbank-Implementierungstechniken – 9–39
n
VL Datenbank-Implementierungstechniken – 9–40
Optimistische Verfahren: Phasen
Validierungskriterium
1. Ausführungsphase (execute): Transaktion wird
ausgeführt, d.h. alle Lese- und Schreiboperationen;
Schreiboperationen jedoch nicht in der Datenbank,
sondern auf einer lokalen Kopie des Datenbankobjekts
im Puffer
2. Validierung (validate)
für jede Transaktion, die commit ausführen will, wird
geprüft, ob sie im Sinne der Konfliktserialisierbarkeit
korrekt abgelaufen ist
3. Persistenzphase (persist):
falls keine Konflikte aufgetreten sind, Zurückschreiben
aller geänderten Datenbankobjekte in den stabilen
Speicher (d.h. in die Datenbank)
Transaktionszähler T C
∀Ti , Tj : n(Ti ) < n(Tj ) mit
n(Ti ) =Wert von TC nach der Validierung von Ti :
1. Ti beendet seine valpersist-Phase, bevor Tj
diese beginnt.
2. x ∈ ws(Ti ) ∩ rs(Tj ) ⇒ Ti beendet
valpersist-Phase, bevor Tj x liest.
3. x ∈ rs(Ti ) ∩ ws(Tj ) ⇒ Ti liest x vor Beginn der
valpersist-Phase von Tj
ws(Ti ) ist write-set von Ti (alle von Ti geschriebenen
DB-Objekte)
rs(Ti ) ist read-set von Ti (gelesene DB-Objekte)
VL Datenbank-Implementierungstechniken – 9–41
Optimistische Scheduler
execute
T
1
T
2
T
3
T
1
T
2
T
3
execute
execute
validate
validate
execute
execute
validate
Optimistische Scheduler (II)
Rückwärtsvalidierung:
persist
persist
Test von rs(Ti ) gegen ws(Tj ) für bereits
Rückwärtsvalidierung
persist
validate
VL Datenbank-Implementierungstechniken – 9–42
persist
Vorwärtsvalidierung
abgeschlossene Tj
ausgenommen davon sind Tj , die bereits vor
Beginn von Ti ein commit ausgeführt haben
bei Konflikt: Zurücksetzen von Ti
im Beispiel: Test von rs(T1 ) gegen ws(T2 ) und
ws(T3 )
Vorwärtsvalidierung
Test von ws(Ti ) gegen rs(Tj ) für Transaktionen Tj ,
execute
die aktiv sind (also in der Ausführungsphase)
bei Konflikt: Zurücksetzen von Tj
im Beispiel: ws(T1 ) gegen rs(T2 ) und rs(T3 )
VL Datenbank-Implementierungstechniken – 9–43
VL Datenbank-Implementierungstechniken – 9–44
Multiversionen-Synchronisation
MVCC: Prinzip
engl. multiversion concurrency control (MVCC)
Umsetzung in Oracle, InterBase, PostgreSQL, . . .
jede Änderungsoperation w erzeugt neue Version des
Datenobjektes
Leseoperationen können Version wählen
Motivation
Versionen sind transparent für Applikationen
Geg. Schedule s:
s = r1 (x)w1 (x)r2 (x)w2 (y)r1 (y)w1 (z)c1 c2
• s 6∈ CSR
• aber tolerierbar, wenn r1 (y) alte Version von y
lesen könnte, so dass r1 (y) konsistent zu r1 (x) ist
• dann: s äquivalent zu s0 = t1 t2
Vorteile:
Entkopplung von Lese- und Änderungsoperationen
; Lesetransaktion hat Sicht auf Datenbank wie bei
BOT
keine Synchronisation von Lesetransaktionen sowie
gegen Lesetransaktionen notwendig ;
Reduzierung der Konfliktwahrscheinlichkeit
Synchronisation von Änderungsoperationen durch
andere Verfahren (Sperrverfahren, Zeitstempel)
VL Datenbank-Implementierungstechniken – 9–45
MVCC: Beispiel
T1
VL Datenbank-Implementierungstechniken – 9–46
MVCC: Versionenverwaltung
T2
Aufgabe: Bestimmung der zu lesenden Version
TR
globaler Transaktionszähler T N C (transaction
w(x0 → x1 )
w(y0 → y1 )
number count)
Commit-Zeitstempel cts und BOT-Zeitstempel bts
r(y0 )
für Transaktion
Schreibzeitstempel wts(x) für Objekt x
commit
w(x1 → x2 )
commit
r(x0 )
VL Datenbank-Implementierungstechniken – 9–47
VL Datenbank-Implementierungstechniken – 9–48
MVCC: Versionenverwaltung (II)
MVCC: Versionenverwaltung (III)
Aufgabe: Freigabe nicht mehr benötigter Versionen
Commit einer Änderungstransaktion TU :
aktueller T N C-Wert als Commit-Zeitstempel cts
sowie Inkrementieren von T N C
modifiziertes Objekt: Schreibzeitstempel
wts(x) = cts(TU )
Lesetransaktion TR :
aktueller T N C-Wert als BOT-Zeitstempel:
(garbage collection)
BOT-Zeitstempel der ältesten Lesetransaktion:
bts_min
Version xi von Objekt x kann gelöscht werden, falls
neuere Version xj existiert, so dass gilt:
wts(xi ) < wts(xj ) < bts_min
bts(TR ) = T N C
hat Zugriff auf jüngste Version von x mit:
wts(x) < bts(TR )
VL Datenbank-Implementierungstechniken – 9–49
Transaktionen in SQL-DBS
VL Datenbank-Implementierungstechniken – 9–50
Bedeutung der Isolationsstufen
Aufweichung von ACID in SQL-92: Isolationsebenen
set transaction
[ { read only | read write }, ]
[isolation level
{ read uncommitted |
read committed |
repeatable read |
serializable }, ]
[ diagnostics size ...]
read uncommitted
schwächste Stufe: Zugriff auf nicht geschriebene
Standardeinstellung:
set transaction read write,
isolation level serializable
repeatable read
kein nonrepeatable read, aber Phantomproblem
Daten, nur für read only Transaktionen
statistische und ähnliche Transaktionen (ungefährer
Überblick, nicht korrekte Werte)
keine Sperren → effizient ausführbar, keine
anderen Transaktionen werden behindert
read committed
nur Lesen endgültig geschriebener Werte, aber
nonrepeatable read möglich
kann auftreten
serializable
garantierte Serialisierbarkeit
VL Datenbank-Implementierungstechniken – 9–51
VL Datenbank-Implementierungstechniken – 9–52
Isolationsebenen II
Isolationsebenen: read committed
Dirty
Unrepeatable
Phantom
T1
Read
Read
Read
Read Uncommitted
+
+
+
select A from R
→ alter Wert
Read Committed
–
+
+
Repeatable Read
–
–
+
Serializable
–
–
–
Isolationsebene
select A from R
→ alter Wert
T2
update R set A = neu
commit
select A from R
→ neuer Wert
VL Datenbank-Implementierungstechniken – 9–53
Isolationsebenen: serializable
T1
VL Datenbank-Implementierungstechniken – 9–54
Oracle I
Unterstützung der Isolationsebenen Read Committed
T2
und Serializable
set transaction
isolation level
serializable
darüber hinaus: Read-Only -Modus (nicht Bestandteil
von SQL-92)
set transaction ...
update R set A = neu
where C = 42
commit
set transaction isolation level read committed;
set transaction isolation level serializable;
set transaction isolation level read only;
update R set A = neu
where C = 42
→ Fehler
VL Datenbank-Implementierungstechniken – 9–55
VL Datenbank-Implementierungstechniken – 9–56
Oracle II
Transaktionsmonitore
Isolationsebenen für eine Menge von Transaktionen
alter session
set isolation_level Isolationsebene;
Explizite Kommandos zum Setzen von Sperren
lock table Tabelle in row share mode;
lock table Tabelle in share mode;
lock table Tabelle in row exclusive mode;
lock table Tabelle in share row exclusive mode;
lock table Tabelle in exclusive mode;
Presentation Server
Presentation Server
Workflow Controller
Transaction Server
Transaction Server
VL Datenbank-Implementierungstechniken – 9–57
Transaktionsmonitore: Architektur
VL Datenbank-Implementierungstechniken – 9–58
Vorteile eines Transaktionsmonitors
Präsentations-Server, engl. presentation server
realisiert als Client die Kommunikation mit dem
Anwender (Kommandosprache oder Menü-gesteuerte
Oberflächen zum Absetzen von Transaktionen etc.)
Workflow-Kontroller (engl. workflow controller )
erzwingt die Zuteilung (engl. routing) der
Transaktionsanforderungen an verschiedenen DBMS
und realisiert z.B. das Zwei-Phasen-Commit-Protokoll
Transaktions-Server (engl. transaction server )
realisieren die Kopplung der lokalen DBMS mit dem
Transaktionsmonitor
bietet eine einheitliche Schnittstelle für die
Transaktionsprogrammierung auf verschiedenen
DBMS
bei verteilter Verarbeitung Übernahme der Routing der
Transaktionen und der Erzwingung von
Commit-Protokollen
Übernahme von Systemfunktionen wie
Lastbalancierung, Fehlerkontrolle und
Systemkonfiguration
kann Funktionen wie das Schreiben eines Log-Buchs
oder die Kommunikationsüberwachung übernehmen
Transaktions-Server eines TP-Monitors kann auch
Daten einkapseln, die nicht von einem DBMS mit voller
Transaktionsfunktionalität verwaltet werden
VL Datenbank-Implementierungstechniken – 9–59
VL Datenbank-Implementierungstechniken – 9–60