Data-Tier Aufgaben und Dienste Arno Schmidhauser Letzte Revision: Juli 2006 Email:...
-
Upload
sigmund-martin -
Category
Documents
-
view
108 -
download
2
Transcript of Data-Tier Aufgaben und Dienste Arno Schmidhauser Letzte Revision: Juli 2006 Email:...
Data-TierData-Tier Aufgaben und Dienste Aufgaben und Dienste
Arno SchmidhauserLetzte Revision: Juli 2006Email: [email protected]: 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