Data-TierData-Tier Aufgaben und Dienste Aufgaben und Dienste

Arno SchmidhauserLetzte Revision: Juli 2006Email: arno.schmidhauser@bfh.chWebseite: http://www.sws.bfh.ch/db

I I ÜbersichtÜbersicht

Aufgaben und DiensteAufgaben und Dienste

Dieses Skript erläutert Aufgaben und Dienste des Data-Tier, die unmittelbar für die Anwendungsentwicklung in Multi-Tier-Applikationen wichtig sind:

• Transaktionssicherheit– ACID-Transaktionen

• Concurrency Control– Locking– Versioning– Timestamping

• Lokalitätstransparenz– Verteilte Daten

• Datenbereitstellung– OLTP und OLAP Abfragen– Replikation, Warehouse-Befüllung

Clie

nt

Tie

r

Web

Tie

r

Busi

ness

Tie

r

Data

Tie

rD

ata

W

ate

house

-S

rvic

es

Data

W

are

house

-C

lients

OLT

P u

nd

OLA

P-

Bed

ürfn

isse

IIIITransaktionsmodellTransaktionsmodell

Was ist eine TransaktionWas 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-RegelACID-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 TransaktionenArbeiten 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-SystemDas Recovery-System

• Zweck• Logfile• Fehlerbehebung

Zweck des Recovery-SystemsZweck 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

FehlerartenFehlerarten

• 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 ModifikationsbefehlenAblauf von Modifikationsbefehlen

DB-Storage

Checkpoint (Gelegentlich)

SQL-Befehl eines Clients

1.

2. Neue Datenwerte

Logfile

Alte und neueDatenwerte

Workspace

Logging, BeispielLogging, Beispiel

Zeit

T1

T2

T3

T4

Checkpoint Systemfehler

BO

T T

1

M21 M22

M31 M32

M41 M42

M11

BO

T T

2

BO

T T

3

BO

T T

4

CM

T T

1

CM

T T

2

RB

K T

3

B_C

KPT (T

2,T

3,T

4)

E_C

KPT (T

2,T

3,T

4)

M21

M11

M22

M31

M32

M41

M42

Logfile

Behebung von TransaktionsfehlernBehebung 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 SystemfehlernBehebung 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 ControlConcurreny Control

• Zweck• Serialisierbarkeit• Neue Methoden

Ziel des Concurrency ControlZiel 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, BeispielSerialisierbarkeit, Beispiel

Transaktion 1

1.1 select * from Kundewhere name = "Muster"

1.2 delete from Kundewhere kunr = :kunr

1.3 delete from Bestellungwhere kunr = :kunr commit

Transaktion 2

2.1 select * from Kunde where 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 ffSerialisierbarkeit 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 (f)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)

LockingLocking

• 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 (-)

DeadlocksDeadlocks

• 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

IsolationsgradeIsolationsgrade

• 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:

Modus Inkonsistenzen

SERIALIZABLE keine Inkonsistenzen

REPEATABLE READ Phantom-Problem

READ COMMITTED Lost-Update

READ UNCOMMITTED Lesen unbestätigter

Daten

Para

lleliät

Isola

tion

Phantom-ProblemPhantom-ProblemT1 T2select *from Personwhere name = 'Muster'

insert Person ( name )values ( 'Muster')

commitselect *from Personwhere name = 'Muster'commit

Hier tauch neuer Datensatz auf

Lost-UpdateLost-Update

T1 T2select saldo from Kontowhere idKonto = 3

select saldo from Kontowhere idKonto = 3neuerSaldo = saldo + 100

update Kontoset saldo = neuerSaldowhere idKonto = 3commit

neuerSaldo = saldo + 100update Kontoset saldo = neuerSaldowhere idKonto = 3commit

Änderungen von T2 gehen beim Update von T1 verloren !

DemoDemo

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 MethodenNeue 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 (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 Reservationwhere resDatum > '1.1.2004' and resDatum < '31.12.2004'

Range Locks (2)Range Locks (2)

Datensatz mit resDatum 1.6.2005

Datensatz mit resDatum 1.6.2003

Der Range Lock werden auf Index-Einträge gesetzt, nicht auf Datensätze, wie gewöhnliche Locks.

Datensätze mit

gesetztem Range Lock

Datensatz mit resDatum 1.6.2004

Datensatz mit resDatum 1.6.2002

select * from Reservationwhere resDatum < '31.12.2004'and resDatum > '1.1.2004'

Wirkungsbereich des Range Locks

Concurrency Control mit Versionen (1)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 SchreiberVersionen, Leser gegen Schreiber

Datensatz X, TNC = 2

Lesende Transaktion/Befehl, TNC = 3

1Schreibende Transaktion/Befehl, TNC = 4

2

Kann gelöscht werden7

Lesende Transaktion/Befehl, TNC = 6

6

Datensatz X, TNC = 4

commit5

Lesende Transaktion/Befehl, TNC = 5

4

Datensatz X, TNC = 2

Kopie des Datensatz3

Datensatz X, TNC = 1

Versionen, Schreiber gegen SchreiberVersionen, Schreiber gegen Schreiber

Datensatz X, TNC = 2

Schreibende Transaktion, TNC = 3

1

Datensatz X, TNC = 1

Schreibende Transaktion, TNC = 4

2

5 commit: ok, weil TNC 2 = max TNC im Pool

Datensatz X, TNC = 2

Kopie Datensatz

4

7

commit: abort, weil TNC 2 max TNC im PoolDatensatz X, TNC = 2

Kopie Datensatz

3

Änderungsbefehl

Datensatz X, TNC = 3

6

DemoDemo

Isolationsverbesserung mit Versionenverfahrenin 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 ZeitstempelnConcurrency Control mit Zeitstempeln

• Zeitstempel + Daten in die Applikation lesen.• Beim Zurückschreiben werden Zeitstempel verglichen:

Bei Veränderung Abbruch der Transaktion.

T1 T2 T3 Zeitstempel in DB

/* BEGIN TRANS * / /* BEGIN TRANS * / /* BEGIN TRANS * / READ A (13:00) READ A (13:00) A (13:00) LOCALLY MODIFY A A (13:00) READ A (13:00) A (13:00) COMMIT/WRITE A A (13:01) COMMIT A (13:01) LCCALLY MODIFY A A (13:01) COMMIT/WRITE A

/* Rollback ! * / A (13:01)

Zeitstempel in SQLZeitstempel in SQL

create table T (

ts integer default 1,

id integer primary key,

data ... )

select ts as ts_old, id, data from Twhere id = id_gesucht

-- data ändern

update Tset ts = ts_old + 1, data = ...where id = id_gesucht and ts = ts_old

if rowcount = 0 then rollback

A

B

C

D

IIIIIIOLTP, OLAP, Data WarehouseOLTP, OLAP, Data Warehouse

OLTP- und OLAP-ApplikationenOLTP- 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-TransaktionenBeispiele OLTP-Transaktionen

Kundenlogin prüfenselect count(*) from Kunde

where username = eingegebener Name

and password = eingegebenes Passwort

Anzeigen von Artikelnselect *

from Artikel

where idGruppe = gewählte Gruppe

order by name

Bestellung einfügeninsert Bestellung (idKunde, idArtikel, menge, bestellDatum )

values ( vom Benützer eingegebene Daten )

Beispiel 1, OLAP-TransaktionBeispiel 1, OLAP-TransaktionWelche Artikel wurden wie oft von Kunden gekauft, die auch denArtikel 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-TransaktionBeispiel 2, OLAP-TransaktionZeige für jeden Artikel, wieviele Verkäufe im Jahr 2007 realisiert wurden:Absolute Menge, relativ zu allen verkauften Artikeln, relativ zu allenVerkä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, DWVergleich OLTP, OLAP, DWKriterium 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, SQL-Durchgriff

(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

IVIVVerteilte DatenbankenVerteilte Datenbanken

DefinitionDefinition

• 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?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.

Gesamtsystem

Verteilte Datenbank, BeispielVerteilte Datenbank, Beispiel

Knoten 1

Knoten 2

Knoten 3

Kunde

Bestellung

Kreditkarte

0..*

1 1

0..*

Artikel

Zugriff auf verteilte DB, BeispieleZugriff 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

ZugriffsarchitekturZugriffsarchitektur

Transparente Architektur• Einer der beteiligten Knoten

spielt den Master und steuert die beteiligten Datenbanken.

• Oft für produkthomogene verteilten Datenbanken.

Knoten 1

Knoten 3Knoten 2

Applikation

Knoten 1 Knoten 3Knoten 2

Applikation

Explizite Architektur• Eine "Drittpartei", der Transaktions-

manager, steuert die beteiligten Datenbanken.

• Oft für produktheterogene, verteilte Datenbanken, z.B. mit Java EE

AppServer/Transaktionsmanager

Integration mit Business TierIntegration mit Business Tier

• Vorteile– Gleiche Datensicht für verschiedene Applikationswelten – Bessere Abfrageoptimierung– Globale Integritätsbedingungen

Knoten 1

Knoten 3Knoten 2

Applikation

AppServer/Transaktionsmanager

DemoDemoVerteilte 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

begin [distributed] transactionselect * from Kunde k, Bestellung bwhere k.idKunde = b.idKunde

commit

Verteilte Änderungstransaktion

begin [distributed] transaction insert into Kunde values ( 2, 'Bitterli' ) insert Bestellung values ( 2, 'IPod' )commit

Verteilte OptimierungVerteilte 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 Remote-

Datenbank betreffen, wird die gesamte Abfrage an diese Remote-Datenbank delegiert.

– Für Abfragen, welche Tabellen aus verschiedenen Datenbank-systemen enthalten, wird versucht, möglichst geringe Transferraten zu erreichen.

Beispiel für OptimierungBeispiel 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.

Kunde Bestellung Artikel

Join

Join

Restriction

select

Transfer 100'000 Datensätze

Plan 1Plan 1

• Grau: Tabellen/Operationen auf dem Remote-Server

• Weiss: Tabellen/Operationen auf dem lokalen Server

• Fett: Netzwerk-Transfers

Artikel

Kunde

Restriction

Join

Bestellung

Join

select

Transfer 10 Datensätze

Transfer 1 Datensatz

Plan 2 (günstiger)Plan 2 (günstiger)

• Grau: Tabellen/Operationen auf dem Remote-Server

• Weiss: Tabellen/Operationen auf dem lokalen Server

• Fett: Netzwerk-Transfers

Verteilte IntegritätsbedingungenVerteilte 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 1create table Kunde ( ... )create synonym Bestellung for ...create trigger t_casc_del on Kunde for delete as begindelete Bestellung where idKunde in ( select idKunde from deleted )

-- host 2create table Bestellung( ... )

VVVerteiltes Verteiltes

TransaktionsmanagementTransaktionsmanagement

GrundsätzeGrundsä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?

ProgrammbeispielProgrammbeispiel// get resourcesxaDs[i] = new MyXADataSource( ... );

// create transaction manager (tm) for this data sourcesXATransactionManager tm = new XATransactionManager( xaDs );

// get JDBC connections for all resources, start transactionConnection con[] = tm.getConnections();tm.start(); // use resources with sql/jdbcfor ( int i = 0; i < xaDs.length; i++ ) { Statement stmt = con[i].createStatement(); stmt.executeUpdate( "..." );} // end transaction, execute two phase committm.end();tm.commit();

Two Phase Commit ProtocolTwo 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)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)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, NormalfallAblauf 2PC, Normalfall

TMTransaktions Manager, resp. Masterknoten

pre

par

e

ready

commit

ready

RM 2Resource Manager 2

pre

par

e

ready

ready

prepareglobal

commit

com

mit

ack

committed

com

mit

committed

ack

completed

Client oderTM selber

ok

Working with RM1 and RM2 …

Changes Pending …ok

RM 1Resource Manager 1

get connections

Ablauf 2PC, RM-Fehler in Phase 1Ablauf 2PC, RM-Fehler in Phase 1

TMTransaktions Manager, resp. Masterknoten

RMResource Manager 1

pre

pare re

ady

commit

ready

RMResource Manager 2

pre

pare n

ot

ready

prepare

global abort

rollback

Problem!!!

completed

Client oderTM selber

failure

abort a

ck

rollback

Working with RM1 and RM2 …

Changes Pending …failure

get connections

Ablauf 2PC, RM-Ausfall in Phase 2Ablauf 2PC, RM-Ausfall in Phase 2

TMTransaktions Manager, resp. Masterknoten

RMResource Manager 1

pre

par

e

ready

commit

ready

RMResource Manager 2

pre

par

e

ready

ready

prepareglobal

commit

com

mit

ack

committed

com

mit

committed

ack

completed

Client oderTM selber

ok

X

com

mit

com

mit

Working with RM1 and RM2 …

Changes Pending …ok

get connections

Ablauf 2PC, TM-Ausfall in Phase 1Ablauf 2PC, TM-Ausfall in Phase 1

TMTransaktions Manager, resp. Masterknoten

RMResource Manager 1

pre

pare re

ady

commit

ready

RMResource Manager 2

prepare

global abort

abort a

ck

rollback rollback

Client oderTM selber

failure

ready

pre

pare

not

read

y

completed

pre

pare

X

Connection lost!

Working with RM1 and RM2 …

Changes Pending …failure

get connections

Ablauf 2PC, TM-Ausfall in Phase 2Ablauf 2PC, TM-Ausfall in Phase 2

TMTransaktions Manager

RMResource Manager 1

pre

par

e

ready

commit

ready

RMResource Manager 2

pre

par

e

ready

ready

prepareglobal

commit

com

mit

ack

committed

com

mit

committed

ack

completed

Client oderTM selber

okX

com

mit

ack

Working with RM1 and RM2 …

Changes Pending …ok

get connections

2PC, Ausfall eines RM2PC, 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 TM2PC, 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, Netzwerkunterbruch2PC, Netzwerkunterbruch

• Phase 11. 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 21. 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 SpezifikationDie 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-TransaktionMethoden einer XA-Transaktion

• start(xid, flags)

• end(xid, flags)

• prepare(xid)

• commit(xid, flags) / rollback(xid)

• recover(flags)

• forget(xid)

Demo 1Demo 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 2Demo 2

• SQL Server 2005, transparente Architektur

Globale Gesamttransaktionbegin 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 Remote- Transaktion aber fehlschlägt.

AppServer, Architekturschema für XAAppServer, Architekturschema für XA

Client

DataSource 1 DataSource 2

DBMS 1 (Resource Manager)

mit Database 1

DBMS 2 (Resource Manager)

mit Database 2

XADataSource 1

XAConnection 1

XAResource 1

getConnection()

XADataSource 2

XAConnection 2

XAResource 2

getConnection()

Applikationsserveroder

Middleware-Komponente

Transaktions-Manager

XADataSource in JDBCXADataSource 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-DatenquellenKonfiguration 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!

VIVIMessaging und verteilte Messaging und verteilte

TransaktionenTransaktionen

Messageing-Systeme mit 2PCMessageing-Systeme mit 2PC

Messageing-System

Applikation 1

DB 1

Messages

Applikation 2

DB 2

Message Message

Two Phase Commit Two Phase Commit

Messageing-Systeme ohne 2PCMessageing-Systeme ohne 2PC

Messageing-Applikation

Sender

DB 1

Empfänger

DB 2

MessageNr 12

MessageNr 12

LMN

(z.B. 11)

VIIVIIReplizierte DatenbankenReplizierte Datenbanken

Was ist Replikation?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 PartitionierungTopologie 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öglichkeitenPartionierungsmöglichkeiten

• 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)

Vertikale Partition

horizontale Partition

Topologie, Beispiel 1Topologie, 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 2Topologie, Beispiel 2

• Transaktionale Peer-to-Peer-Replikation

• Typische Topologie für Load Balancing oder Failover/Hot- Standby-System

Topologie, Beispiel 3Topologie, Beispiel 3

• Unidirektionale Publisher-Subscriber Replikation

• Typische Data Warehouse Topologie. Im DW werden Daten für die Nachbearbeitung, Analyse, Archivierung gesammelt.

SynchronitätSynchronitä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.

SymmetrieSymmetrie

• 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 / SymmetrieSynchronität / Symmetrie

Replikationsarten

Synchronität Symmetrie

Asynchron Synchron

Asymmetrisch

Lesen überall möglich, Update nur an einem Ort möglich. Master-Slave-Topologie. Schwache Inkonsistenzen (kurzzeitig unterschiedlicher Informationsstand) möglich.

Verteilte Transaktion notwendig. Keine Inkonsistenzen möglich. Wird auch für Hot-Standbye-Systeme verwendet.

Symmetrisch

Änderungen von Daten bei jedem Replikat möglich.Grundsätzlich schwere Inkonsistenzen möglich. Konfliktauflösungs-Strategie erforderlich.

Verteilte Transaktion notwendig. Keine Inkonsistenzen möglich. Einziger Vorteil: Lesen wird verteilt.

KonfliktlösungKonfliktlösung

• Wenn Daten asynchron, symmetrisch und mit überlap-pendenden 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

KonvergenzKonvergenz

• 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 mPublisher Subscriber 1 Subscriber 2

Startzustand der Replikate [Hans, 12.7] [Hans, 12.7] [Hans, 12.7]Änderung auf Subscriber 1 [Hans, 12.7] [Hans, 11.5] [Hans, 12.7]Änderung auf Subscriber 2 [Hans, 12.7] [Hans, 11.5] [Hans, 10.9]Abgleich Publisher / Subscriber 1 [Hans, 11.5] [Hans, 11.5] [Hans, 10.9]Abgleich Publisher / Subscriber 2 [Hans, 10.9] [Hans, 11.5] [Hans, 10.9]Abgleich Publisher / Subscriber 1 [Hans, 10.9] [Hans, 10.9] [Hans, 10.9]Endzustand nach 3 Abgleichen [Hans, 10.9] [Hans, 10.9] [Hans, 10.9]

Demo Merge-ReplikationDemo Merge-Replikation

DemoDemoDatenreplikation

• 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.

• PartitionierungEine vollständige Tabelle auf einem Publisher und mehreren Subscribern repliziert. Die Daten überlappen sowohl zwischen Publisher und Subscriber, wie unter den Subscribern.

• Synchronitätasynchroner, manuell ausgelöster Abgleich.

• SymmetrieSymmetrisch Datenhaltung, Daten können überall gelesen und geändert werden.

• KonfliktlösungMinimumwert für Laufzeit