Informatikfragen

Data-Tier
Aufgaben und Dienste
 Arno Schmidhauser
Letzte Revision: Juli 2006
Email: [email protected]
Webseite: http://www.sws.bfh.ch/db
I
Übersicht
Aufgaben und Dienste
•
Datenbereitstellung
– OLTP und OLAP Abfragen
– Replikation, Warehouse-Befüllung
Data Tier
Lokalitätstransparenz
– Verteilte Daten
Data
WatehouseSrvices
•
Business Tier
Concurrency Control
– Locking
– Versioning
– Timestamping
Data
WarehouseClients
•
Web Tier
Transaktionssicherheit
– ACID-Transaktionen
OLTP und OLAPBedürfnisse
•
Client Tier
Dieses Skript erläutert Aufgaben und Dienste des Data-Tier, die
unmittelbar für die Anwendungsentwicklung in Multi-Tier-Applikationen
wichtig sind:
II
Transaktionsmodell
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.
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
SQL-Befehl eines Clients
2. Neue Datenwerte
1.
Alte und neue
Datenwerte
Workspace
Checkpoint (Gelegentlich)
Logfile
DB-Storage
Logging, Beispiel
T1
M22
M21
T2
M42
M41
T4
M32
M31
T3
M42
RBK T3
M32
CMT T2
M22
E_CKPT (T2,T3,T4)
B_CKPT (T2,T3,T4)
M41
BOT T4
M31
BOT T3
M21
BOT T2
CMT T1
M11
BOT T1
Logfile
M11
Zeit
Systemfehler
Checkpoint
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 Cache ü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.
Concurreny 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.
•
Andererseits: Parallelität
– Eine Datenbank muss mehrere Benutzer(-prozesse)
gleichzeitig bedienen können und es sollen möglichst wenig
Wartesituationen entstehen.
•
Auch für Middleware (Appserver) gilt: Der gemeinsame
Referenzpunkt für Datenobjekte ist der Data-Tier.
Serialisierbarkeit, Beispiel
Die folgenden zwei Transaktionen müssen so gesteuert werden,
dass der Schritt 1.3 nicht zwischen 2.1 und 2.2 zu liegen kommen.
Transaktion 1
Transaktion 2
1.1
select * from Kunde
where name = "Muster"
2.1 select * from Kunde
where where name = "Muster"
1.2
delete from Kunde
where kunr = :kunr
2.2 select * from Bestellung
where kunr = :kunr
commit
1.3
delete from Bestellung
where kunr = :kunr
commit
Serialisierbarkeit ff
Unter der Annahme, dass die Datenbank keine Synchronisationsmittel einsetzt und jedes SQL-Statement ein
atomarer Schritt ist, sind verschiedene zeitliche Abläufe
der beiden Transaktionen denkbar:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
1.1
1.1
1.1
1.1
1.1
1.1
2.1
2.1
2.1
2.1










2.1
2.1
2.1
1.2
1.2
1.2
1.1
1.1
1.1
2.2










1.2
1.2
2.2
2.1
2.1
1.3
1.2
2.2
1.2
1.1










2.2
1.3
1.2
1.3
2.2
2.1
2.2
1.2
1.3
1.2










1.3
2.2
1.3
2.2
1.3
2.2
1.3
1.3
2.2
1.3
(k)
(f)
(k)
(f)
(f)
(s)
(k)
(k)
(f)
(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
-
-
Angeforderte Sperre
Angeforderte Sperre wird
gewährt (+) oder nicht gewährt (-)
Bestehende Sperre
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:
Inkonsistenzen
Isolatio
n
Modus
SERIALIZABLE
REPEATABLE READ
READ UNCOMMITTED
Paralleli
ät
READ COMMITTED
keine Inkonsistenzen
Phantom-Problem
Lost-Update
Lesen unbestätigter Daten
Phantom-Problem
T1
select *
from Person
where name = 'Muster'
T2
insert Person ( name )
values ( 'Muster')
commit
select *
from Person
where name = 'Muster'
commit
Hier tauch neuer Datensatz auf
Lost-Update
T1
select saldo
from Konto
where idKonto = 3
T2
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 !
Demo
Auswirkung des Isolationsgrades auf Transaktions-Durchsatz
• Die Einstellung des Isolationsgrades hat bei intensiven
genutzten Systemen (J2EE-Appservern) grosse
Auswirkungen auf den Transaktionsdurchsatz, die
Deadlockhäufigkeit und das Auftreten von Inkonsistenzen.
 TransaktionsSimulator.doc
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.2004'
and resDatum < '31.12.2004'
Range Locks (2)
Der Range Lock werden auf Index-Einträge gesetzt, nicht auf
Datensätze, wie gewöhnliche Locks.
select * from Reservation
where resDatum < '31.12.2004'
and resDatum > '1.1.2004'
Datensatz mit resDatum 1.6.2005
Datensatz mit resDatum 1.6.2004
Datensatz mit resDatum 1.6.2003
Datensätze mit
gesetztem Range Lock
Wirkungsbereich des
Range Locks
Datensatz mit resDatum 1.6.2002
Concurrency Control mit Versionen (1)
• 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, und verwenden
gegebenenfalls einen Lock, um diese zu reservieren.
Versionen, Leser gegen Schreiber
6
Lesende Transaktion/Befehl, TNC = 6
4
Lesende Transaktion/Befehl, TNC = 5
2
Schreibende Transaktion/Befehl, TNC = 4
1
Lesende Transaktion/Befehl, TNC = 3
3
Kopie des Datensatz
Datensatz X, TNC = 2
5 commit
Datensatz X, TNC = 4
Datensatz X, TNC = 2
7
Kann gelöscht werden
Datensatz X, TNC = 1
Versionen, Schreiber gegen Schreiber
2
Schreibende Transaktion, TNC = 4
1
Schreibende Transaktion, TNC = 3
4
Änderungsbefehl
Datensatz X, TNC = 2
3
Datensatz X, TNC = 2
5
commit: ok, weil
TNC 2 = max TNC
im Pool
6

7
commit: abort,
weil TNC 2  max
TNC im Pool
Datensatz X, TNC = 3
Kopie Datensatz
Kopie Datensatz
Datensatz X, TNC = 2
Datensatz X, TNC = 1
Demo
Isolationsverbesserung mit Versionenverfahren
in SQL Server 2005
• 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.
Concurrency Control mit Zeitstempeln
• Zeitstempel + Daten in die Applikation lesen.
• Beim Zurückschreiben werden Zeitstempel verglichen:
Bei Veränderung Abbruch der Transaktion.
T1
T2
T3
/* BEGIN TRANS */
READ A (13:00)
LOCALLY MODIFY A
/* BEGIN TRANS */
/* BEGIN TRANS */
READ A (13:00)
COMMIT/WRITE A
READ A (13:00)
COMMIT
LCCALLY MODIFY A
COMMIT/WRITE A
/* Rollback ! */
Zeitstempel
in DB
A
A
A
A
A
A
A
(13:00)
(13:00)
(13:00)
(13:01)
(13:01)
(13:01)
(13:01)
Zeitstempel in SQL
create table T (
ts integer default 1,
id integer primary key,
data ... )
A
select ts as ts_old, id, data
from T
where id = id_gesucht
B
-- data ändern
C
update T
set ts = ts_old + 1, data = ...
where id = id_gesucht
and ts = ts_old
D
if rowcount = 0 then rollback
III
OLTP, OLAP, Data Warehouse
OLTP- und OLAP-Applikationen
•
•
OLTP = Online Transaction Processing
OLAP = Online Analytical Processing
•
Der Fokus von Java EE Applikationen liegt stark im OLTP-Bereich:
– Kurze, einfache, effiziente Transaktionen für das laufende
Geschäft.
Das extremste Gegenstück zum OLTP-Betrieb ist das Data Warehouse:
– Periodische Extraktion und Aufbereitung von Aktualdaten in
spezielle Datenbanken, den Data Warehouses.
– Aufbewahrung von historischen Daten.
– Auswertung in die Vergangenheit und die Zukunft.
OLAP-Anfragen nehmen eine Zwischenposition an:
– Zusammenfassende Informationen, in Echtzeit aus den
Aktualdaten erzeugt.
– OLAP-Anfragen gehören mehr und mehr zu OLTP-Applikationen.
•
•
Beispiele OLTP-Transaktionen
Kundenlogin prüfen
select count(*) from Kunde
where username = eingegebener Name
and password = eingegebenes Passwort
Anzeigen von Artikeln
select *
from Artikel
where idGruppe = gewählte Gruppe
order by name
Bestellung einfügen
insert Bestellung (idKunde, idArtikel, menge, bestellDatum )
values ( vom Benützer eingegebene Daten )
Beispiel 1, OLAP-Transaktion
Welche Artikel wurden wie oft von Kunden gekauft, die auch den
Artikel 1 gekauft haben?
select b2.idArtikel, count(*)
from Bestellung b1, Bestellung b2
where b1.idArtikel = 1
and b2.idArtikel != b1.idArtikel
and b1.idKunde = b2.idKunde
group by b2.idArtikel
Beispiel 2, OLAP-Transaktion
Zeige für jeden Artikel, wieviele Verkäufe im Jahr 2007 realisiert wurden:
Absolute Menge, relativ zu allen verkauften Artikeln, relativ zu allen
Verkäufen in der Artikelgruppe.
select artikel, gruppe, verkäufe,
verkäufe / sum(verkäufe) over() anteilGesamt,
verkäufe / sum(verkäufe) over( partition by gruppe ) anteilGruppe
from
( select a.name artikel, g.name gruppe, cast ( sum(b.menge) as
float ) verkäufe
from Bestellung b, Artikel a, Gruppe g
where b.idArtikel = a.idArtikel
and a.idGruppe = g.idGruppe
and datepart( year, bestellDatum ) = 2007
group by a.name, g.name
) as Verkauf
order by artikel
Vergleich OLTP, OLAP, DW
Kriterium
OLTP
OLAP
DW
Anwenderzahl
hoch
mittel/niedrig
niedrig
Operationstyp
lesen, ändern,
einfügen, löschen
lesen
lesen
Komplexität der Abfragen
klein
mittel
hoch
Typischer Isolationsgrad
Serializable
Read Committed
Snapshot
Java EE Anbindung
Entity Klassen
Technische Entities
und Views, SQLDurchgriff
(spezialisierte Tools)
verlangte Antwortzeiten
< 1 sec
1-3 sec
> 1-3 sec
Grunddaten
Aktueller,
realitätskonformer
Datenbestand.
Aktueller,
realitätskonformer
Datenbestand.
Aktuelle und
historische Daten.
Inkrementelle
Fütterung aus
Aktualdaten.
Durch Einzeltransaktion
berührtes Datenvolumen
klein
klein bis mittel
mittel bis gross
Datenqualität
operativ
operativ
bereinigt
IV
Verteilte Datenbanken
Definition
• Eine verteilte Datenbank umfasst ein einziges
Datenmodell, dessen Daten auf mehrere Datenbankserver
(Knoten) aufgeteilt werden. Jede Information ist nur auf
einem Knoten vorhanden.
• Die einzelnen Knoten und das verbindende Netzwerk sind
technisch unabhängig lebensfähige Komponenten.
• Das Managementsystem für eine verteilte Datenbank
muss mit zeitweise ausfallenden oder nicht erreichbaren
Knoten umgehen können.
Knoten = Datenbankserver = Resource Manager RM
Warum verteilte Datenbanken?
• Zusammenwachsen von vormals unabhängigen Systemen
zu einem aus Benutzer- oder Applikationssicht einzigen
System.
• An gewissen Knoten werden meist nur bestimmte Daten
benötigt. Ein Zugriff auf die anderen Knoten ist nur
gelegentlich notwendig.
• Aus Sicherheits- oder gesetzlichen Überlegungen werden
bestimmte Daten nur auf bestimmten Knoten abgelegt.
Verteilte Datenbank, Beispiel
Gesamtsystem
Kunde
1
1
0..*
Bestellung
Knoten 1
0..*
Kreditkarte
Artikel
Knoten 3
Knoten 2
Zugriff auf verteilte DB, Beispiele
• Kunde aufnehmen
– erfordert neuen Eintrag in Knoten 1
• Kunde löschen
– erfordert Löschungen in Knoten 1, 2 und 3
• Artikelstamm ändern
– erfordert Änderungen in Knoten 2
• Artikel bestellen
– erfordert Lesen in 1 und 3, Änderungen in 2
Zugriffsarchitektur
Transparente Architektur
• Einer der beteiligten Knoten
spielt den Master und steuert
die beteiligten Datenbanken.
• Oft für produkthomogene
verteilten Datenbanken.
Explizite Architektur
• Eine "Drittpartei", der Transaktionsmanager, steuert die beteiligten
Datenbanken.
• Oft für produktheterogene, verteilte
Datenbanken, z.B. mit Java EE
Applikation
Knoten 1
Knoten 2
Knoten 3
Applikation
AppServer/Transaktionsmanager
Knoten 1
Knoten 2
Knoten 3
Integration mit Business Tier
• Vorteile
– Gleiche Datensicht für verschiedene Applikationswelten
– Bessere Abfrageoptimierung
– Globale Integritätsbedingungen
Applikation
AppServer/Transaktionsmanager
Knoten 1
Knoten 2
Knoten 3
Demo
Verteilte Transaktionen in SQL Server 2005
• Linked Server definieren für die physische Adressierung
• Synonym deklarieren, um Ortstransparenz zu erreichen
• Lokale Tabelle Kunde, Remote-Tabelle Bestellung
Verteilte Abfragetransaktion
Verteilte Änderungstransaktion
begin [distributed] transaction
select *
from Kunde k, Bestellung b
where k.idKunde = b.idKunde
commit
begin [distributed] transaction
insert into Kunde
values ( 2, 'Bitterli' )
insert Bestellung
values ( 2, 'IPod' )
commit
Verteilte Optimierung
•
Ein entscheidender Vorteil der transparenten Architektur ist, dass
Abfragen knotenübergreifend optimiert werden können.
•
Ein Query Optimierer arbeitet nach dem Cost-Based-Verfahren: Er
versucht, den Ausführungsplan mit dem kleinsten Zeitaufwand zu
finden. Die Anzahl Zugriffe auf IO-Pages eines Speichermediums
(physical reads) spielen dabei eine ausschlaggebende Rolle.
Bei SQL-Abfragen mit Zugriffen auf Remote-Tabellen ist der Transfer
von Datensätzen über ein Netzwerk die teuerste Operation.
•
– Für Abfragen, welche ausschliesslich Tabellen eine RemoteDatenbank betreffen, wird die gesamte Abfrage an diese RemoteDatenbank delegiert.
– Für Abfragen, welche Tabellen aus verschiedenen Datenbanksystemen enthalten, wird versucht, möglichst geringe
Transferraten zu erreichen.
Beispiel für Optimierung
SELECT *
FROM Kunde k,
remote_server.remote_db.dbo.Bestellung b,
remote_server.remote_db.dbo.Artikel a
WHERE k.idKunde = b.idKunde
AND
b.idArtikel = a.idArtikel AND k.kundenNr = 3
•
Annahmen
– Kunde habe 10'000 Einträge
– Bestellung habe 100'000 Einträge
– Artikel habe 1'000 Einträge
– Die Anzahl Bestellungen pro Kunde und Pro Artikel sei etwa gleich
verteilt.
Plan 1
select
Join
Join
Restriction
Kunde
Transfer 100'000 Datensätze
Bestellung
Artikel
• Grau: Tabellen/Operationen auf dem Remote-Server
• Weiss: Tabellen/Operationen auf dem lokalen Server
• Fett: Netzwerk-Transfers
Plan 2 (günstiger)
select
Transfer 10 Datensätze
Join
Join
Artikel
Transfer 1 Datensatz
Restriction
Kunde
Bestellung
• Grau: Tabellen/Operationen auf dem Remote-Server
• Weiss: Tabellen/Operationen auf dem lokalen Server
• Fett: Netzwerk-Transfers
Verteilte Integritätsbedingungen
•
Im Grundsatz können Integritätsbedingungen über verteilte Daten
definiert werden, da die Prüfung einer Integritätsbedingung oder
Ausführung einer Integritätsaktion lediglich der Ausführung von
versteckten SQL-Befehlen entspricht. Die Transparenz der Verteilung
wird dadurch gewährleistet.
•
Je nach Produkt ergeben sich aber Einschränkungen. SQL-Server
erlaubt z.B. keine Fremdschlüssel-Beziehungen zu Remote-Tabellen,
jedoch kann mit Triggern gearbeitet werden.
-- host 1
create table Kunde ( ... )
create synonym Bestellung for ...
create trigger t_casc_del on Kunde
for delete as begin
delete Bestellung
where idKunde in (
select idKunde from deleted )
-- host 2
create table Bestellung
( ... )
V
Verteiltes
Transaktionsmanagement
Grundsätze
•
Zugriffe in verteilten Datenbanken unterliegen dem Transaktionsmodell:
– Es gilt die ACID-Regel und das Serialisierbarkeits-Prinzip.
– Eine verteilte Transaktion konkurriert mit anderen
lokalen oder verteilten Transaktionen.
•
Der Ablauf aus Applikationssicht ist grundsätzlich wie bei lokalen
Transaktionen:
– Beginn implizit oder explizt auf allen Knoten
– Benutzung der Daten via SQL
– commit / rollback
•
Heikel: Die Atomaritätsanforderung. Was passiert, wenn einer der Knoten
Änderungen bereits durchgeführt und freigegeben hat, und der andere
abstürzt?
Programmbeispiel
// get resources
xaDs[i] = new MyXADataSource( ... );
// create transaction manager (tm) for this data sources
XATransactionManager tm = new XATransactionManager( xaDs );
// get JDBC connections for all resources, start transaction
Connection con[] = tm.getConnections();
tm.start();
// use resources with sql/jdbc
for ( int i = 0; i < xaDs.length; i++ ) {
Statement stmt = con[i].createStatement();
stmt.executeUpdate( "..." );
}
// end transaction, execute two phase commit
tm.end();
tm.commit();
Two Phase Commit Protocol
Das Two-Phase-Commit Protokoll ermöglicht das Durchführen
von global korrekten Transaktionen:
1. Sicherstellung der modifizierten Daten in jedem beteiligten
Knoten.
2. Bestätigen und Freigeben der modifizierten Daten in
jedem beteiligten Knoten.
2PC, Transaktionsmanager (TM)
• Der Transaktionsmanager führt das 2PC durch. Der TM kann ein
separates Produkt oder in ein bestimmtes DB-System, z.B.
Oracle, integriert sein.
• Der Transaktionsmanager benötigt selbst eine Datenbank-für
das Durchführen des 2PC, vorallem für die laufenden
Transaktions-Nummern und die Transaktions-Zustände. Der TM
führt den Zustand jeder Transaktion in seinem Logfile mit:
prepare
global commit
global abort
complete
2PC, Resource Manager (RM)
• Der Resource Manager (lokales Datenbanksystem) muss
den Zustand seines Teiles der verteilten Transaktion
ebenfalls in seinem Logfile festhalten:
begin ( wie für gewöhnliche Transaktion )
ready ( oder prepared, für verteilte Transaktion)
commit ( wie für gewöhnliche Transaktion )
Ablauf 2PC, Normalfall
get connections
global commit
RM 1
Resource
Manager 1
RM 2
Resource
Manager 2
ready
ready
committed
committed
ack
commit
prepare
commit
ready
completed
ack
ok
TM
Transaktions Manager, resp. Masterknoten
prepare
Working
Changes
with
okand…
Pending
RM1
RM2 …
commit
ready
Client oder
TM selber
prepare
Ablauf 2PC, RM-Fehler in Phase 1
get connections
Client oder
TM selber
prepare
commit
TM
Transaktions Manager, resp. Masterknoten
failure
not ready
ack
prepare
abort
ready
completed
prepare
Changes
Working
with
Pending
failure
RM1
and…
RM2 …
global abort
RM
Resource
Manager 1
RM
Resource
Manager 2
ready
Problem!!!
rollback
rollback
Ablauf 2PC, RM-Ausfall in Phase 2
get connections
global commit
committed
committed
RM
Resource
Manager 2
ready
ack
ready
X
RM
Resource
Manager 1
commit
commit
commit
prepare
commit
ready
completed
ack
ok
TM
Transaktions Manager, resp. Masterknoten
prepare
Working
with
Changes
okand…
RM1
Pending
RM2 …
commit
ready
Client oder
TM selber
prepare
Ablauf 2PC, TM-Ausfall in Phase 1
X
get connections
not ready
ack
prepare
abort
prepare
ready
failure
TM
Transaktions Manager, resp. Masterknoten
prepare
Working
with
Changes
RM1
failure
and…
Pending
RM2 …
commit
ready
Client oder
TM selber
RM
Resource
Manager 1
RM
Resource
Manager 2
ready
Connection lost!
rollback
rollback
prepare
global abort
completed
Ablauf 2PC, TM-Ausfall in Phase 2
X
get connections
RM
Resource
Manager 1
RM
Resource
Manager 2
ready
ready
committed
committed
ack
completed
ready
ack
global commit
commit
prepare
commit
commit
ack
ok
prepare
Working
with
Changes
RM1
okand…
Pending
RM2 …
TM
Transaktions Manager
commit
ready
Client oder
TM selber
prepare
2PC, Ausfall eines RM
Beim Restart des RM konsultiert dieser sein Log-File:
1. Verteilte Transaktionen, für die ein rollback oder nichts
eingetragen ist, werden zurückgesetzt.
2. Verteilte Transaktionen, für die ein commit eingetragen ist,
werden nachgespielt.
3. Bei verteilten Transaktionen, für die lediglich ein ready
eingetragen ist, muss der TM konsultiert oder auf dessen
commit/abort Befehl gewartet werden.
2PC, Ausfall des TM
Beim Restart des TM konsultiert dieser sein Log-File:
1. ist eine verteilte Transaktion im Zustand prepare, nimmt
TM mit allen RM Verbindung auf und schickt ihnen ein
global abort. Er kann auch versuchen, prepare
nochmals durchzuführen.
2. ist die verteilte Transaktion im Zustand global abort,
nimmt TM mit allen RM Verbindung auf und schickt ihnen
ein global abort.
3. ist die verteilte Transaktion im Zustand global commit,
nimmt TM mit allen RM Verbindung auf und schickt ihnen
ein global commit.
2PC, Netzwerkunterbruch
• Phase 1
1. Wenn einer der RM's einen Verbindungsabbruch vor
dem prepare bemerkt, leitet er ein lokales Rollback
ein.
2. Wenn der TM keine Antwort auf eine prepare-Meldung
bekommt, leitet er ein global abort ein.
• Phase 2
1. Die RM's erhalten die global abort oder global
commit Meldung nicht: Sie müssen auf die
Verfügbarkeit des Netzwerkes und eine
Verbindungsaufnahme resp. einen Befehl vom TM
warten.
Die X/Open XA Spezifikation
• Die X/Open XA-Spezifikation ist heute die wahrscheinlich
wichtigste, allgemeine DTP-Spezifikation, für die alle
grossen DB- und TM-Hersteller Implementationen
anbieten.
• Die X/Open XA-Spezifikation basiert auf dem Two-Phase
Commit.
• Sie enthält zusätzliche Methoden für das Abgeben und
Wiederaufnehmen einer Transaktion.
• Sie enthält zusätzliche Methoden für den (gleichzeitigen)
Gebrauch einer Transaktion durch mehrere Prozesse.
Methoden einer XA-Transaktion
• start(xid, flags)
• end(xid, flags)
• prepare(xid)
• commit(xid, flags) / rollback(xid)
• recover(flags)
• forget(xid)
Demo 1
Ablauf von XA Transaktionen, Java-Umfeld
1. XA-Transaktion: Schönwetter-Ablauf
2. Demo mit Fehlern in einem Resource Manager und im
Transaction Manager:
1. Fehler im RM2 nach end(), aber vor prepare()
2. Fehler im RM2 nach prepare() aber vor commit()
Demo 2
• SQL Server 2005, transparente Architektur
Globale Gesamttransaktion
begin transaction
insert into Kunde
values ( 2, 'Bitterli' )
insert Bestellung
values ( 2, 'IPod' )
commit
Was passiert, wenn hier die Remote-Datenbank ein Problem hat?
 Rollback der Gesamttransaktion, da bei verteilten Resourcen
automatisch ein Two Phase Commit abgewickelt wird.
 Bei zwei unabhängigen, lokalen Transaktionen könnte es dazu
kommen, dass die lokale Transaktion committed wird, die RemoteTransaktion aber fehlschlägt.
AppServer, Architekturschema für XA
Client
DataSource 1
getConnection()
Applikationsserver
oder
Middleware-Komponente
DataSource 2
getConnection()
XADataSource 1
XADataSource 2
XAConnection 1
XAConnection 2
XAResource 1
XAResource 2
DBMS 1
(Resource Manager)
mit
Database 1
TransaktionsManager
DBMS 2
(Resource Manager)
mit
Database 2
XADataSource in JDBC
• Eine XADataSource repräsentiert eine von mehreren
Datenquellen, die an einer verteilten Transaktion (XA)
teilnehmen.
• Für die Applikation soll transparent sein, dass ihre
Datenzugriffe im Rahmen einer verteilten Transaktion
stattfinden. Sie arbeitet funktional mit einer gewöhnlichen
Connection.
• Die Transaktionsabwicklung findet durch einen
Transaktions-Manager statt, bei dem die beteiligten
Datenquellen registriert sind.
Konfiguration von XA-Datenquellen
• Bei J2EE wird eine Datenquelle wird im Rahmen ihrer
Konfiguration als gewöhnliche oder XA-fähige Resource
deklariert.
• Das Transaktions-Management ist gegenüber der Business
Logik transparent.
• XA Datenquellen werden immer über XA-Transaktionen
bearbeitet.
• Messaging-Systeme sind häufig auch XA-Resourcen!
VI
Messaging und verteilte
Transaktionen
Messageing-Systeme mit 2PC
Messageing-System
Messages
Two Phase Commit
Message
Two Phase Commit
Message
Applikation 2
Applikation 1
DB 1
DB 2
Messageing-Systeme ohne 2PC
Messageing-Applikation
Message
Nr 12
Message
Nr 12
Empfänger
Sender
LMN
(z.B. 11)
DB 1
DB 2
VII
Replizierte Datenbanken
Was ist Replikation?
• Bestimmte Teile einer Datenbank werden mehrfach, auf
technisch unabhängigen Rechnerknoten abgelegt.
• Replikationtechnologien spielen eine zunehmende Rolle, weil
globale und permanente Verfügbarkeit immer wichtiger wird.
• Wichtige Gründe für die Replikation sind:
– Skalierbarkeit des Zugriffs
– Verfügbarkeit/ Bandbreite des Netzwerkes
– Gebrauchsweise (OLTP , OLAP, Warehousing, Data Mining)
• Für die technische Ausgestaltung der Replikation sind folgende
Klassifikationsmerkmale wichtig:
– Topologie und Partitionierung
– Synchronität
– Symmetrie
– Konfliktlösung
Topologie und Partitionierung
1. Welche Knoten sind Publisher, welche Subscriber?
2. Zwischen welchen Knoten bestehen überlappende Partitionen?
3. In welche Richtungen werden Daten repliziert?
4. Wie kräftig und verfügbar ist das Netzwerk zwischen den Knoten?
5. Push- oder Pull-Strategie?
6. Wie rasch müssen Änderungen propagiert werden?
7. Wie gross sind die replizierten Datenmengen?
Partionierungsmöglichkeiten
Vertikale Partition
horizontale Partition
•
•
•
Partitionen können sich grundsätzlich überlappen
Angaben zur horizontalen Partitionierung z.B. via SQL-Filterkriterium
(dynamische Zugehörigkeit)
Angaben zur vertikalen Partionierung meist fest konfiguriert (statische
Einteilung)
Topologie, Beispiel 1
• Bidirektionale Publisher-Subscriber
Replikation.
• "Geschäftsstellen/Mutterhaus"-Prinzip.
• Überlappende Partitionen nur zwischen
Mutterhaus und Geschäftsstellen,
nicht unter den Geschäftsstellen.
Topologie, Beispiel 2
• Transaktionale Peer-to-PeerReplikation
• Typische Topologie für Load
Balancing oder Failover/HotStandby-System
Topologie, Beispiel 3
• Unidirektionale PublisherSubscriber Replikation
• Typische Data Warehouse
Topologie. Im DW werden
Daten für die
Nachbearbeitung, Analyse,
Archivierung gesammelt.
Synchronität
• Die Synchronität bestimmt, ob eine Replikation zu den anderen
Knoten unmittelbar, in der gleichen Transaktion wie die
Datenänderung, stattfinden muss.
• synchron: Ein Two-Phase-Commit ist erforderlich. Der einzige
Vorteil einer synchronen Replikation ist die Skalierbarkeit von
Leseoperationen.
• asynchron: Änderungen werden via einen Abgleich-Prozess
nach und nach propagiert. Dies kann direkt von Datenbank zu
Datenbank oder via eine Message Queue erfolgen.
Symmetrie
• Die Symmetrie bestimmt, ob Daten in allen Replikationen
gelesen und geändert werden dürfen.
• symmetrisch: Daten dürfen in allen Replikaten gelesen und
geändert werden.
• asymmetrisch: Daten haben eine primäre Kopie, die gelesen
und geändert werden kann. Änderungen werden nur in einer
Richtung propagiert und dürfen an den sekundären Standorten
nur gelesen werden.
Synchronität / Symmetrie
Replikationsarten
Synchronität 
Asynchron
Synchron
Symmetrie 
Asymmetrisch
Symmetrisch
Lesen überall möglich,
Update nur an einem Ort
möglich. Master-SlaveTopologie. Schwache
Inkonsistenzen (kurzzeitig
unterschiedlicher
Informationsstand)
möglich.
Verteilte Transaktion
notwendig. Keine
Inkonsistenzen möglich.
Wird auch für HotStandbye-Systeme
verwendet.
Änderungen von Daten bei
jedem Replikat möglich.
Grundsätzlich schwere
Inkonsistenzen möglich.
KonfliktauflösungsStrategie erforderlich.
Verteilte Transaktion
notwendig. Keine
Inkonsistenzen möglich.
Einziger Vorteil: Lesen
wird verteilt.
Konfliktlösung
• Wenn Daten asynchron, symmetrisch und mit überlappendenden Partitionen repliziert werden, können Konflikte
entstehen: Daten können an zwei Replikaten geändert worden
sein, bevor der Abgleich stattgefunden hat.
• Beim nächsten Abgleich muss dieser Konflikt erkannt und
behandelt werden. Die meisten Replikations-Tools unterstützen
vordefinierte Regeln für die Konfliktauflösung:
– Feste Knotenpriorität
– Feste Benutzerpriorität
– Minimum/Maximumwert eines best. Attributes
– Jüngere/ältere Änderung
– Erster gewinnt
– Zurückstellen und interaktive Auflösung
Konvergenz
• Der Abgleich replizierter Daten findet immer sequentiell
zwischen je zwei Knoten statt. Beispiel mit einem
Publisher- und zwei Subscriber-Knoten (kleinster Zeitwert
gewinnt bei Konflikten):
Datensatz mit Bestzeit auf 100 m
Startzustand der Replikate
Änderung auf Subscriber 1
Änderung auf Subscriber 2
Abgleich Publisher / Subscriber 1
Abgleich Publisher / Subscriber 2
Abgleich Publisher / Subscriber 1
Endzustand nach 3 Abgleichen
Publisher
[Hans, 12.7]
[Hans, 12.7]
[Hans, 12.7]
[Hans, 11.5]
[Hans, 10.9]
[Hans, 10.9]
[Hans, 10.9]
Subscriber 1
[Hans, 12.7]
[Hans, 11.5]
[Hans, 11.5]
[Hans, 11.5]
[Hans, 11.5]
[Hans, 10.9]
[Hans, 10.9]
Subscriber 2
[Hans, 12.7]
[Hans, 12.7]
[Hans, 10.9]
[Hans, 10.9]
[Hans, 10.9]
[Hans, 10.9]
[Hans, 10.9]
Demo Merge-Replikation
Demo
Datenreplikation
•
SQL-Server 2005, Tabelle Laeufer mit bestzeit-Attribut. 1 Publisher
Datenbank und zwei Subscriber Datenbanken. Je eine Änderung bei den
beiden Subscribern, dann Start der Merge-Agents.
•
Partitionierung
Eine vollständige Tabelle auf einem Publisher und mehreren Subscribern
repliziert. Die Daten überlappen sowohl zwischen Publisher und
Subscriber, wie unter den Subscribern.
•
Synchronität
asynchroner, manuell ausgelöster Abgleich.
•
Symmetrie
Symmetrisch Datenhaltung, Daten können überall gelesen und geändert
werden.
•
Konfliktlösung
Minimumwert für Laufzeit