Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Data-Tier Aufgaben und Dienste Arno Schmidhauser Letzte Revision: Juli 2006 Webseite:

Ähnliche Präsentationen


Präsentation zum Thema: "Data-Tier Aufgaben und Dienste Arno Schmidhauser Letzte Revision: Juli 2006 Webseite:"—  Präsentation transkript:

1 Data-Tier Aufgaben und Dienste Arno Schmidhauser Letzte Revision: Juli Webseite:

2 I Übersicht

3 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 Client Tier Web Tier Business Tier Data Tier Data Watehouse- Srvices Data Warehouse- Clients OLTP und OLAP- Bedürfnisse

4 II Transaktionsmodell

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

6 ACID-Regel Das Datenbanksystem garantiert für eine Transaktion folgende Eigenschaften: AAtomarität CKonsistenz IIsolation DDauerhaftigkeit Diese Eigenschaften werden als ACID Regel bezeichnet.

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

8

9 Das Recovery-System Zweck Logfile Fehlerbehebung

10 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

11 Fehlerarten Transaktionsfehler –Rollback-Befehl durch Applikation –Verletzung von Integritätsbedingungen –Verletzung von Zugriffsrechten –Deadlock –Verbindungsunterbruch oder Client-Crash Systemfehler –Stromausfall, Hardware- oder Memory-Fehler

12

13 Ablauf von Modifikationsbefehlen DB-Storage Checkpoint (Gelegentlich) SQL-Befehl eines Clients Neue Datenwerte Logfile Alte und neue Datenwerte Workspace

14 Logging, Beispiel Zeit T1 T2 T3 T4 Checkpoint Systemfehler BOT T1 M21M22 M31M32 M41 M42 M11 BOT T2BOT T3BOT T4CMT T1CMT T2RBK T3B_CKPT (T2,T3,T4)E_CKPT (T2,T3,T4)M21M11M22M31M32M41M42 Logfile

15

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

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

18

19 Concurreny Control Zweck Serialisierbarkeit Neue Methoden

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

21 Serialisierbarkeit, Beispiel Transaktion 1 1.1select * from Kunde where name = "Muster" 1.2 delete from Kunde where kunr = :kunr 1.3delete from Bestellung where kunr = :kunr commit Transaktion 2 2.1select * from Kunde where where name = "Muster" 2.2select * 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.

22 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: (k) (f) (k) (f) (f) (s) (k) (k) (f) (s)

23 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: Bestehende Sperre Angeforderte Sperre Angeforderte Sperre wird gewährt (+) oder nicht gewährt (-)

24

25 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. Serialisierbarkeit2004.ppt#121. Serialisierbarkeit

26 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: ModusInkonsistenzen SERIALIZABLE keine Inkonsistenzen REPEATABLE READ Phantom-Problem READ COMMITTED Lost-Update READ UNCOMMITTED Lesen unbestätigter Daten Paralleli ät Isolatio n

27 Phantom-Problem Hier tauch neuer Datensatz auf

28 Lost-Update Änderungen von T2 gehen beim Update von T1 verloren !

29 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

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

31 Range Locks (1) Range Locks werden für die Realisierung des Isolation Levels SERIALIZABLE verwendet. Mit Range Locks werden Datensätze nach einer logischen Bedingung und nicht nur rein physisch gesperrt. Mit Range Locks kann das Phantom Problem elegant gelöst werden. Voraussetzung: Die Abfragebedingung enthält einen oder mehrere Teile, welche über einen Index evaluiert werden können. Beispiel: select * from Reservation where resDatum > ' ' and resDatum < ' '

32 Range Locks (2) Datensatz mit resDatum Datensatz mit resDatum 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 Datensatz mit resDatum select * from Reservation where resDatum ' ' Wirkungsbereich des Range Locks

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

34 Versionen, Leser gegen Schreiber Datensatz X, TNC = 2 Lesende Transaktion/Befehl, TNC = 3 1 Schreibende Transaktion/Befehl, TNC = 4 2 Kann gelöscht werden 7 Lesende Transaktion/Befehl, TNC = 6 6 Datensatz X, TNC = 4 commit 5 Lesende Transaktion/Befehl, TNC = 5 4 Datensatz X, TNC = 2 Kopie des Datensatz 3 Datensatz X, TNC = 1

35 Versionen, Schreiber gegen Schreiber Datensatz X, TNC = 2 Schreibende Transaktion, TNC = 3 1 Datensatz X, TNC = 1 Schreibende Transaktion, TNC = 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 Pool Datensatz X, TNC = 2 Kopie Datensatz 3 Änderungsbefehl Datensatz X, TNC = 3 6

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

37 Concurrency Control mit Zeitstempeln Zeitstempel + Daten in die Applikation lesen. Beim Zurückschreiben werden Zeitstempel verglichen: Bei Veränderung Abbruch der Transaktion.

38 Zeitstempel in SQL create table T ( ts integer default 1, id integer primary key, data... ) select ts as ts_old, id, data from T where id = id_gesucht -- data ändern update T set ts = ts_old + 1, data =... where id = id_gesucht and ts = ts_old if rowcount = 0 then rollback A B C D

39 III OLTP, OLAP, Data Warehouse

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

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

42 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

43 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

44 Vergleich OLTP, OLAP, DW KriteriumOLTPOLAPDW Anwenderzahlhochmittel/niedrigniedrig Operationstyplesen, ändern, einfügen, löschen lesen Komplexität der Abfragenkleinmittelhoch Typischer IsolationsgradSerializableRead CommittedSnapshot Java EE AnbindungEntity KlassenTechnische Entities und Views, SQL- Durchgriff (spezialisierte Tools) verlangte Antwortzeiten< 1 sec1-3 sec> 1-3 sec GrunddatenAktueller, realitätskonformer Datenbestand. Aktuelle und historische Daten. Inkrementelle Fütterung aus Aktualdaten. Durch Einzeltransaktion berührtes Datenvolumen kleinklein bis mittelmittel bis gross Datenqualitätoperativ bereinigt

45 IV Verteilte Datenbanken

46 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

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

48 Gesamtsystem Verteilte Datenbank, Beispiel Knoten 1 Knoten 2 Knoten 3

49 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

50 Zugriffsarchitektur Transparente Architektur Einer der beteiligten Knoten spielt den Master und steuert die beteiligten Datenbanken. Oft für produkthomogene verteilten Datenbanken. Knoten 1 Knoten 3 Knoten 2 Applikation Knoten 1 Knoten 3 Knoten 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

51 Integration mit Business Tier Vorteile –Gleiche Datensicht für verschiedene Applikationswelten –Bessere Abfrageoptimierung –Globale Integritätsbedingungen Knoten 1 Knoten 3 Knoten 2 Applikation AppServer/Transaktionsmanager

52 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

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

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

55 Plan 1 Grau: Tabellen/Operationen auf dem Remote-Server Weiss: Tabellen/Operationen auf dem lokalen Server Fett: Netzwerk-Transfers

56 Plan 2 (günstiger) Grau: Tabellen/Operationen auf dem Remote-Server Weiss: Tabellen/Operationen auf dem lokalen Server Fett: Netzwerk-Transfers

57 Verteilte Integritätsbedingungen Im Grundsatz können Integritätsbedingungen über verteilte Daten definiert werden, da die Prüfung einer Integritätsbedingung oder Ausführung einer Integritätsaktion lediglich der Ausführung von versteckten SQL-Befehlen entspricht. Die Transparenz der Verteilung wird dadurch gewährleistet. Je nach Produkt ergeben sich aber Einschränkungen. SQL-Server erlaubt z.B. keine Fremdschlüssel-Beziehungen zu Remote-Tabellen, jedoch kann mit Triggern gearbeitet werden. -- host 1 create table Kunde (... ) create synonym Bestellung for... create trigger t_casc_del on Kunde for delete as begin delete Bestellung where idKunde in ( select idKunde from deleted ) -- host 2 create table Bestellung (... )

58 V Verteiltes Transaktionsmanagement

59 Grundsätze Zugriffe in verteilten Datenbanken unterliegen dem Transaktionsmodell: –Es gilt die ACID-Regel und das Serialisierbarkeits-Prinzip. –Eine verteilte Transaktion konkurriert mit anderen lokalen oder verteilten Transaktionen. Der Ablauf aus Applikationssicht ist grundsätzlich wie bei lokalen Transaktionen: –Beginn implizit oder explizt auf allen Knoten –Benutzung der Daten via SQL –commit / rollback Heikel: Die Atomaritätsanforderung. Was passiert, wenn einer der Knoten Änderungen bereits durchgeführt und freigegeben hat, und der andere abstürzt?

60 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();

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

62 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

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

64 Ablauf 2PC, Normalfall TM Transaktions Manager, resp. Masterknoten prepare ready commit ready RM 2 Resource Manager 2 prepare ready prepare global commit commit ack committed commit committed ack completed Client oder TM selber ok Working with RM1 and RM2 … Changes Pending … ok RM 1 Resource Manager 1 get connections

65 Ablauf 2PC, RM-Fehler in Phase 1 TM Transaktions Manager, resp. Masterknoten RM Resource Manager 1 prepare ready commit ready RM Resource Manager 2 prepare not ready prepare global abort rollback Problem!!! completed Client oder TM selber failure abort ack rollback Working with RM1 and RM2 … Changes Pending … failure get connections

66 Ablauf 2PC, RM-Ausfall in Phase 2 TM Transaktions Manager, resp. Masterknoten RM Resource Manager 1 prepare ready commit ready RM Resource Manager 2 prepare ready prepare global commit commit ack committed commit committed ack completed Client oder TM selber ok X commit Working with RM1 and RM2 … Changes Pending … ok get connections

67 Ablauf 2PC, TM-Ausfall in Phase 1 TM Transaktions Manager, resp. Masterknoten RM Resource Manager 1 prepare ready commit ready RM Resource Manager 2 prepare global abort abort ack rollback Client oder TM selber failure ready prepare not ready completed prepare X Connection lost! Working with RM1 and RM2 … Changes Pending … failure get connections

68 Ablauf 2PC, TM-Ausfall in Phase 2 TM Transaktions Manager RM Resource Manager 1 prepare ready commit ready RM Resource Manager 2 prepare ready prepare global commit commit ack committed commit committed ack completed Client oder TM selber ok X commit ack Working with RM1 and RM2 … Changes Pending … ok get connections

69 2PC, Ausfall eines RM Beim Restart des RM konsultiert dieser sein Log-File: 1.Verteilte Transaktionen, für die ein rollback oder nichts eingetragen ist, werden zurückgesetzt. 2.Verteilte Transaktionen, für die ein commit eingetragen ist, werden nachgespielt. 3.Bei verteilten Transaktionen, für die lediglich ein ready eingetragen ist, muss der TM konsultiert oder auf dessen commit/abort Befehl gewartet werden.

70 2PC, Ausfall des TM Beim Restart des TM konsultiert dieser sein Log-File: 1.ist eine verteilte Transaktion im Zustand prepare, nimmt TM mit allen RM Verbindung auf und schickt ihnen ein global abort. Er kann auch versuchen, prepare nochmals durchzuführen. 2.ist die verteilte Transaktion im Zustand global abort, nimmt TM mit allen RM Verbindung auf und schickt ihnen ein global abort. 3.ist die verteilte Transaktion im Zustand global commit, nimmt TM mit allen RM Verbindung auf und schickt ihnen ein global commit.

71 2PC, Netzwerkunterbruch Phase 1 1.Wenn einer der RM's einen Verbindungsabbruch vor dem prepare bemerkt, leitet er ein lokales Rollback ein. 2.Wenn der TM keine Antwort auf eine prepare -Meldung bekommt, leitet er ein global abort ein. Phase 2 1.Die RM's erhalten die global abort oder global commit Meldung nicht: Sie müssen auf die Verfügbarkeit des Netzwerkes und eine Verbindungsaufnahme resp. einen Befehl vom TM warten.

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

73 Methoden einer XA-Transaktion start(xid, flags) end(xid, flags) prepare(xid) commit(xid, flags) / rollback(xid) recover(flags) forget(xid)

74

75 Demo 1 Ablauf von XA Transaktionen, Java-Umfeld 1.XA-Transaktion: Schönwetter-Ablauf 2.Demo mit Fehlern in einem Resource Manager und im Transaction Manager: 1.Fehler im RM2 nach end(), aber vor prepare() 2.Fehler im RM2 nach prepare() aber vor commit()

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

77 AppServer, 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() Applikationsserver oder Middleware-Komponente Transaktions- Manager

78

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

80 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!

81 VI Messaging und verteilte Transaktionen

82 Messageing-Systeme mit 2PC Messageing-System Applikation 1 DB 1 Messages Applikation 2 DB 2 Message Two Phase Commit

83 Messageing-Systeme ohne 2PC Messageing-Applikation Sender DB 1 Empfänger DB 2 Message Nr 12 LMN (z.B. 11)

84 VII Replizierte Datenbanken

85 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

86 Topologie und Partitionierung 1.Welche Knoten sind Publisher, welche Subscriber? 2.Zwischen welchen Knoten bestehen überlappende Partitionen? 3.In welche Richtungen werden Daten repliziert? 4.Wie kräftig und verfügbar ist das Netzwerk zwischen den Knoten? 5.Push- oder Pull-Strategie? 6.Wie rasch müssen Änderungen propagiert werden? 7.Wie gross sind die replizierten Datenmengen?

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

88 Topologie, Beispiel 1 Bidirektionale Publisher-Subscriber Replikation. "Geschäftsstellen/Mutterhaus"-Prinzip. Überlappende Partitionen nur zwischen Mutterhaus und Geschäftsstellen, nicht unter den Geschäftsstellen.

89 Topologie, Beispiel 2 Transaktionale Peer-to-Peer- Replikation Typische Topologie für Load Balancing oder Failover/Hot- Standby-System

90 Topologie, Beispiel 3 Unidirektionale Publisher- Subscriber Replikation Typische Data Warehouse Topologie. Im DW werden Daten für die Nachbearbeitung, Analyse, Archivierung gesammelt.

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

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

93 Synchronität / Symmetrie Replikationsarten Synchronität Symmetrie AsynchronSynchron 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.

94 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

95 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):

96 Demo Merge-Replikation

97 Demo Datenreplikation SQL-Server 2005, Tabelle Laeufer mit bestzeit -Attribut. 1 Publisher Datenbank und zwei Subscriber Datenbanken. Je eine Änderung bei den beiden Subscribern, dann Start der Merge-Agents. Partitionierung Eine vollständige Tabelle auf einem Publisher und mehreren Subscribern repliziert. Die Daten überlappen sowohl zwischen Publisher und Subscriber, wie unter den Subscribern. Synchronität asynchroner, manuell ausgelöster Abgleich. Symmetrie Symmetrisch Datenhaltung, Daten können überall gelesen und geändert werden. Konfliktlösung Minimumwert für Laufzeit


Herunterladen ppt "Data-Tier Aufgaben und Dienste Arno Schmidhauser Letzte Revision: Juli 2006 Webseite:"

Ähnliche Präsentationen


Google-Anzeigen