data tier aufgaben und dienste l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Data-Tier Aufgaben und Dienste PowerPoint Presentation
Download Presentation
Data-Tier Aufgaben und Dienste

Loading in 2 Seconds...

play fullscreen
1 / 97

Data-Tier Aufgaben und Dienste - PowerPoint PPT Presentation


  • 206 Views
  • Uploaded on

Data-Tier Aufgaben und Dienste.  Arno Schmidhauser Letzte Revision: Juli 2006 Email: arno.schmidhauser@bfh.ch Webseite: http://www.sws.bfh.ch/db. I Übersicht. Aufgaben und Dienste.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Data-Tier Aufgaben und Dienste' - niveditha


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
data tier aufgaben und dienste

Data-Tier Aufgaben und Dienste

 Arno Schmidhauser

Letzte Revision: Juli 2006

Email: arno.schmidhauser@bfh.ch

Webseite: http://www.sws.bfh.ch/db

aufgaben und dienste
Aufgaben 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

OLTP und OLAP-Bedürfnisse

Business Tier

Web Tier

Data Tier

Client Tier

Data Watehouse-Srvices

Data Warehouse-Clients

was ist eine transaktion
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
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
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
Das Recovery-System
  • Zweck
  • Logfile
  • Fehlerbehebung
zweck des recovery systems
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
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
Ablauf von Modifikationsbefehlen

SQL-Befehl eines Clients

2. Neue Datenwerte

Workspace

1.

Alte und neueDatenwerte

Checkpoint (Gelegentlich)

Logfile

DB-Storage

logging beispiel
Logging, Beispiel

M11

T1

M21

M22

T2

M31

M32

T3

M42

M41

T4

Zeit

Checkpoint

Systemfehler

BOT T1

M11

CMT T1

BOT T2

M21

BOT T3

M31

BOT T4

M41

B_CKPT (T2,T3,T4)

E_CKPT (T2,T3,T4)

M22

CMT T2

M32

RBK T3

M42

Logfile

behebung von transaktionsfehlern
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
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
Concurreny Control
  • Zweck
  • Serialisierbarkeit
  • Neue Methoden
ziel des concurrency control
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
Transaktion 1

1.1 select * from Kundewhere name = "Muster"

1.2 delete from Kunde

where 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

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.

serialisierbarkeit ff
Serialisierbarkeit ff

Unter der Annahme, dass die Datenbank keine Synchro-nisationsmittel einsetzt und jedes SQL-Statement ein atomarer Schritt ist, sind verschiedene zeitliche Abläufe der beiden Transaktionen denkbar:

  • 1.1  2.1 1.2 2.2 1.3 (k)
  • 1.1 2.1 1.2 1.3 2.2 (f)
  • 1.1 2.1 2.2 1.2 1.3 (k)
  • 1.1 1.2 2.1 1.3 2.2 (f)
  • 1.1 1.2 2.1 2.2 1.3 (f)
  • 1.1 1.2 1.3 2.1 2.2 (s)
  • 2.1  1.1 1.2 2.2 1.3 (k)
  • 2.1 1.1 2.2 1.2 1.3 (k)
  • 2.1 1.1 1.2 1.3 2.2 (f)
  • 2.1 2.2 1.1 1.2 1.3 (s)
locking
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:

Angeforderte Sperre

Angeforderte Sperre wird gewährt (+) oder nicht gewährt (-)

Bestehende Sperre

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

Modus Inkonsistenzen

SERIALIZABLE keine Inkonsistenzen

REPEATABLEREAD Phantom-Problem

READCOMMITTED Lost-Update

READUNCOMMITTED Lesen unbestätigter Daten

Paralleliät

Isolation

phantom problem
Phantom-Problem

Hier tauch neuer Datensatz auf

lost update
Lost-Update

Änderungen von T2 gehen beim Update von T1 verloren !

slide29
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
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 (1)
  • Range Locks werden für die Realisierung des Isolation Levels SERIALIZABLE verwendet.
  • Mit Range Locks werden Datensätze nach einer logischenBedingung 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)

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

Datensatz mit resDatum 1.6.2005

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

Datensatz mit resDatum 1.6.2004

Datensatz mit resDatum 1.6.2003

Datensätze mit

gesetztem Range Lock

Datensatz mit resDatum 1.6.2002

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 schreiber

6

1

Lesende Transaktion/Befehl, TNC = 6

4

Lesende Transaktion/Befehl, TNC = 5

2

Schreibende Transaktion/Befehl, TNC = 4

Lesende Transaktion/Befehl, TNC = 3

Kopie des Datensatz

commit

5

3

Datensatz X, TNC = 2

Datensatz X, TNC = 4

7

Kann gelöscht werden

Versionen, Leser gegen Schreiber

Datensatz X, TNC = 2

Datensatz X, TNC = 1

versionen schreiber gegen schreiber

4

Änderungsbefehl

1

2

Datensatz X, TNC = 2

Schreibende Transaktion, TNC = 3

Schreibende Transaktion, TNC = 4

3

Datensatz X, TNC = 2

6

Datensatz X, TNC = 3

Kopie Datensatz

Kopie Datensatz

7

commit: abort, weil TNC 2  max TNC im Pool

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

5

Versionen, Schreiber gegen Schreiber

Datensatz X, TNC = 2

Datensatz X, TNC = 1

slide36
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
Concurrency Control mit Zeitstempeln
  • Zeitstempel + Daten in die Applikation lesen.
  • Beim Zurückschreiben werden Zeitstempel verglichen:Bei Veränderung Abbruch der Transaktion.
zeitstempel in sql
Zeitstempel in SQL

create table T (

ts integer default 1,

id integer primary key,

data ... )

select ts asts_old, id, data

from T

where id = id_gesucht

A

-- dataändern

B

update T

set ts = ts_old + 1, data = ...

where id = id_gesucht

and ts = ts_old

C

if rowcount = 0 then rollback

D

oltp und olap applikationen
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
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
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
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

definition
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
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
Verteilte Datenbank, Beispiel

Gesamtsystem

Knoten 1

Knoten 3

Knoten 2

zugriff auf verteilte db beispiele
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
Zugriffsarchitektur

Explizite Architektur

  • Eine "Drittpartei", der Transaktions-manager, steuert die beteiligten Datenbanken.
  • Oft für produktheterogene, verteilte Datenbanken, z.B. mit Java EE

Transparente Architektur

  • Einer der beteiligten Knoten spielt den Master und steuert die beteiligten Datenbanken.
  • Oft für produkthomogene verteilten Datenbanken.

Applikation

Applikation

Knoten 1

AppServer/Transaktionsmanager

Knoten 3

Knoten 1

Knoten 2

Knoten 2

Knoten 3

integration mit business tier
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

slide52
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
  • begin [distributed] transaction
    • select *
    • from Kunde k, Bestellung b
    • where k.idKunde = b.idKunde
  • commit

Verteilte Änderungstransaktion

begin [distributed] transaction

insert into Kunde values ( 2, 'Bitterli' )

insert Bestellung values ( 2, 'IPod' )

commit

verteilte optimierung
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 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 optimierung
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
Plan 1
  • Grau: Tabellen/Operationen auf dem Remote-Server
  • Weiss: Tabellen/Operationen auf dem lokalen Server
  • Fett: Netzwerk-Transfers
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 tsbedingungen
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 2

create table Bestellung( ... )

-- host 1

create table Kunde ( ... )

create synonym Bestellung for ...

create trigger t_casc_del on Kunde

for deleteasbegin

delete Bestellung

where idKunde in ( select idKunde fromdeleted )

grunds tze
Grundsätze
  • Zugriffe in verteilten Datenbanken unterliegen dem Transaktionsmodell:
    • Es gilt die ACID-Regel und das Serialisierbarkeits-Prinzip.
    • Eine verteilte Transaktion konkurriert mit anderenlokalen 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
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
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
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 normalfall

get connections

ok

commit

commit

prepare

commit

prepare

ready

ready

ack

ack

Ablauf 2PC, Normalfall

Client oder

TM selber

TM

Transaktions Manager, resp. Masterknoten

prepare

global commit

completed

ok

Changes Pending …

Working with RM1 and RM2 …

RM 2Resource Manager 2

RM 1Resource Manager 1

ready

ready

committed

committed

ablauf 2pc rm fehler in phase 1

get connections

commit

failure

abort

prepare

prepare

ack

ready

not ready

Ablauf 2PC, RM-Fehler in Phase 1

Client oder

TM selber

TM

Transaktions Manager, resp. Masterknoten

prepare

global abort

completed

Changes Pending …

failure

Working with RM1 and RM2 …

RMResource Manager 2

RMResource Manager 1

Problem!!!

ready

rollback

rollback

ablauf 2pc rm ausfall in phase 2

get connections

ok

commit

commit

commit

prepare

commit

prepare

commit

ack

ack

ready

ready

Ablauf 2PC, RM-Ausfall in Phase 2

Client oder

TM selber

TM

Transaktions Manager, resp. Masterknoten

prepare

global commit

completed

ok

Working with RM1 and RM2 …

Changes Pending …

X

RMResource Manager 2

RMResource Manager 1

ready

ready

committed

committed

ablauf 2pc tm ausfall in phase 1

get connections

commit

failure

prepare

prepare

prepare

abort

ready

ready

ack

not ready

Ablauf 2PC, TM-Ausfall in Phase 1

X

Client oder

TM selber

TM

Transaktions Manager, resp. Masterknoten

prepare

global abort

completed

failure

Working with RM1 and RM2 …

Changes Pending …

RMResource Manager 2

RMResource Manager 1

Connection lost!

ready

rollback

rollback

ablauf 2pc tm ausfall in phase 2

get connections

ok

commit

commit

prepare

commit

prepare

commit

ack

ack

ack

ready

ready

Ablauf 2PC, TM-Ausfall in Phase 2

X

Client oder

TM selber

TM

Transaktions Manager

prepare

global commit

completed

ok

Working with RM1 and RM2 …

Changes Pending …

RMResource Manager 2

RMResource Manager 1

ready

ready

committed

committed

2pc ausfall eines rm
2PC, Ausfall eines RM

Beim Restart des RM konsultiert dieser sein Log-File:

  • Verteilte Transaktionen, für die ein rollback oder nichts eingetragen ist, werden zurückgesetzt.
  • Verteilte Transaktionen, für die ein commit eingetragen ist, werden nachgespielt.
  • 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
2PC, Ausfall des TM

Beim Restart des TM konsultiert dieser sein Log-File:

  • 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.
  • ist die verteilte Transaktion im Zustand global abort, nimmt TM mit allen RM Verbindung auf und schickt ihnen ein global abort.
  • ist die verteilte Transaktion im Zustand global commit, nimmt TM mit allen RM Verbindung auf und schickt ihnen ein global commit.
2pc netzwerkunterbruch
2PC, Netzwerkunterbruch
  • Phase 1
    • Wenn einer der RM's einen Verbindungsabbruch vor dem prepare bemerkt, leitet er ein lokales Rollback ein.
    • Wenn der TM keine Antwort auf eine prepare-Meldung bekommt, leitet er ein global abort ein.
  • Phase 2
    • 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
  • 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
Methoden einer XA-Transaktion
  • start(xid, flags)
  • end(xid, flags)
  • prepare(xid)
  • commit(xid, flags) / rollback(xid)
  • recover(flags)
  • forget(xid)
demo 1
Demo 1

Ablauf von XA Transaktionen, Java-Umfeld

  • XA-Transaktion: Schönwetter-Ablauf
  • Demo mit Fehlern in einem Resource Manager und im Transaction Manager:
    • Fehler im RM2 nach end(), aber vor prepare()
    • Fehler im RM2 nach prepare() aber vor commit()
demo 2
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 Remote- Transaktion aber fehlschlägt.
appserver architekturschema f r xa
AppServer, Architekturschema für XA

Client

Applikationsserver

oder

Middleware-Komponente

DataSource 2

DataSource 1

getConnection()

getConnection()

XADataSource 2

XADataSource 1

XAConnection 2

XAConnection 1

XAResource 2

XAResource 1

Transaktions-

Manager

DBMS 1 (Resource Manager)mit Database 1

DBMS 2 (Resource Manager)mit Database 2

xadatasource in jdbc
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
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!
messageing systeme mit 2pc
Messageing-Systeme mit 2PC

Messageing-System

Messages

Two Phase Commit

Two Phase Commit

Message

Message

Applikation 2

Applikation 1

DB 1

DB 2

messageing systeme ohne 2pc
Messageing-Systeme ohne 2PC

Messageing-Applikation

MessageNr 12

MessageNr 12

Empfänger

Sender

LMN

(z.B. 11)

DB 1

DB 2

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 partitionierung
Topologie und Partitionierung
  • Welche Knoten sind Publisher, welche Subscriber?
  • Zwischen welchen Knoten bestehen überlappende Partitionen?
  • In welche Richtungen werden Daten repliziert?
  • Wie kräftig und verfügbar ist das Netzwerk zwischen den Knoten?
  • Push- oder Pull-Strategie?
  • Wie rasch müssen Änderungen propagiert werden?
  • Wie gross sind die replizierten Datenmengen?
partionierungsm glichkeiten
Partionierungsmö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)
topologie beispiel 1
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
Topologie, Beispiel 2
  • Transaktionale Peer-to-Peer-Replikation
  • Typische Topologie für Load Balancing oder Failover/Hot- Standby-System
topologie beispiel 3
Topologie, Beispiel 3
  • Unidirektionale Publisher-Subscriber Replikation
  • Typische Data Warehouse Topologie. Im DW werden Daten für die Nachbearbeitung, Analyse, Archivierung gesammelt.
synchronit t
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
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.
konfliktl sung
Konfliktlö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
konvergenz
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):
slide97
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.
  • 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