Transaktionsabwicklung in SQL-DB
Werbung
Transaktionsabwicklung in SQL-DB-Servern Vortrag von Michael Sand, MA Gliederung Abgrenzung des Themas Motivation Problemstellung Was ist Konsistenz? Was ist eine Transaktion? ACID-Eigenschaften Nebenläufigkeit: Concurrency Ansätze: pessimistisch vs. optimistisch Transaktionalität auf Applikationsebene Transaktionssicherung durch das DBMS Ausblick: Interaktion zwischen Systemen Abgrenzung des Themas Transaktionen zwischen Systemen TP Heavy Transaktionen in SQL-Datenbanken Transaktionen in Applikationen TP Lite Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick Abgrenzung Motivation Fehlerquellen Problemstellung Motivation Warum Transaktionen? Beispiel Banküberweisung: 1. < T: read( Konto1 ) > 2. < T: update Konto1. Betrag von 0 auf 100 > 3. < T: update Konto2. Betrag von 1000 auf 900 > Kommt es nach Schritt 2 zu einem Ausfall, sind die Daten nicht mehr konsistent. Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick Abgrenzung Motivation Fehlerquellen Problemstellung Fehler1: Dirty Read 1. <T1 Start> 2. <T1 Update Konto1 10.2000, 2.000> 3. 4. 5. 6. 7. <T1 Update Konto2 1.000, 9.000> 8. <T1 Commit> <T2 Start> <T2 Update Konto 1: * 1,04> <T2 Update Konto 2: * 1,04> <T2 Commit> Zinsen für 8.000 Euro wurden nicht berechnet! Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick Abgrenzung Motivation Fehlerquellen Problemstellung Fehler 2: Unrepeateable Read 1. <T1 Start> 2. <T1 Read Konto1> 3. <T1 Update Konto 10.000, 2.000> 4. 5. 6. 7. 8. 9. <T1 Update Konto2 1.000, 9.000> 10. <T1 Commit> <T2 Start> <T2 Read Konto 1> <T2 Read Konto 2> <T2 Sum Konto 1, Konto2> <T2 Commit> Gesamtsumme wird falsch berechnet, Werte wurden gelesen, während sie geändert wurden! Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick Abgrenzung Motivation Fehlerquellen Problemstellung Fehler 3: Lost Update 1. <T1 Start> 2. <T1 temp 1 = Konto1 + 1.000> 3. 4. 5. 6. 7. <T1 Konto 1 = temp 1> 8. <T1 Commit> <T2 Start> <T2 temp 2 = Konto 1 + 2000> <T2 Konto1 = temp 2> <T2 Commit> 2.000 Euro Zubuchung gehen verloren! Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick Abgrenzung Motivation Fehlerquellen Problemstellung Problemstellung Die Abbildung von Geschäftsfällen müssen in der Datenbank abgesichert werden gegen: Physische Fehler Unkontrollierte unvereinbare gleichzeitige Zugriffe auf den Datenbestand Inkonsistente Benutzereingaben Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick Abgrenzung Motivation Fehlerquellen Problemstellung Was ist Konsistenz? Physisch: korrekte interne Repräsentation und Speicherung der Daten im Datenbanksystem Logisch: Übereinstimmung mit dem abzubildenden Realitätsausschnitt R‘ R R: Realität M: Modell M‘ M Daten Daten Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick Konsistenz Transaktion Was ist eine Transaktion? Eine Transaktion ist für einen SQL Server eine in sich geschlossene Arbeitseinheit. Eine Arbeitseinheit wird entweder vollständig ausgeführt oder gar nicht. Eine nur teilweise Ausführung einer Arbeitseinheit würde zu Inkonsistenzen der Daten führen. Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick Konsistenz Transaktion Verschachtelte Transaktionen Main Transaction Begin Trans Commit Begin Trans Commit Begin Trans Begin Trans Commit Commit Begin Trans Commit Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick Konsistenz Transaktion ACID-Eigenschaften Atomicity Consistency Isolation Durability Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick Atomicity Consistency Isolation Durability ACID: Atomicity Alles oder Nichts Prinzip In Fehlersituationen wird die Transaktion abgebrochen und der Datenbestand wird in seinen ursprünglichen Zustand zurückversetzt. Begin Trans Commit Begin Trans Rollback Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick Atomicity Consistency Isolation Durability ACID: Consistency Konsistenz = Widerspruchsfreiheit Vor Begin und nach dem Ende einer Transaktion muss ein konsistenter Zustand der Datenbank vorliegen. Während einer Transaktion können die Daten inkonsistent sein. Jede technisch implementierte Integritätsbedingung muss erfüllt sein. Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick Atomicity Consistency Isolation Durability ACID: Isolation Jede Transaktion soll so durchgeführt werden, als wäre sie die einzige. Änderungen am Datenbestand durch eine Transaktion dürfen für andere Transaktionen erst am Ende der Transaktion sichtbar sein. Kein Unterschied zwischen Ein- und Mehrbenutzerbetrieb. Trans3 Trans2 Trans1 Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick Atomicity Consistency Isolation Durability ACID: Durability Nach Abschluss einer Transaktion müssen alle Änderungen am Datenbestand auf einem sicheren Speichermedium festgehalten sein. Trans1 Daten Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick Atomicity Consistency Isolation Durability Nebenläufigkeit: Concurrency Mehrere Transaktionen laufen gleichzeitig ab (Concurrency: Nebenläufigkeit) Mehrere Benutzer greifen gleichzeitig auf den Datenbestand zu. Transaktionen können im Konflikt zueinander stehen. Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick Ansätze Ansätze: pessimistisch vs. optimistisch Optimistischer Ansatz: Alle Clients können auf alle Informationen zugreifen + keine Wartezeiten - Operationen müssen kommutativ sein - Umverteilung in sehr kleine Operationseinheiten keine Transaktionalität Pessimistischer Ansatz: Verwendete Daten sind für andere Clients z.T. gesperrt + Wahrung der ACID-Eigenschaften - Einrichtung von Sperrmechanismen notwendig - evtl. Wartezeiten durch Sperren / Integritätsprüfungen Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick Ansätze Transaktionssicherung Transaktionalität auf Applikationsebene Stored Procedures Trigger TP Lite Transaktionalität auf DBMS-Ebene Rules Redo- / Undo-Logging Locks Validierung Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick TP Lite Applikationscode ist ins DBMS integriert. Funktionalität des DBMS ist erweitert. Keine Transaktionen zwischen heterogenen DBMS. Verschiedene aufgerufene SPs laufen als unterschiedliche Serverprozesse. Jeder Aufruf initiiert einen neuen Serverprozess (im Unterschied zu TP Heavy) Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick Applikationsebene: Stored Procedures Trigger TP-Lite Transaktionalität auf Applikationsebene Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick Stored Procedures Applikationscode, der mit SQL in das DBMS integriert ist. Alle Anweisungen der Prozedur werden ausgeführt, wenn die Prozedur aufgerufen wird Hat ACID-Eigenschaften (bei DB2, Oracle) Leistungsverhalten besser als bei SQLAnweisungen, die von der Applikation einzeln aufgerufen werden. wiederverwendbar Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick Applikationsebene: Stored Procedures Trigger TP-Lite Trigger Applikationscode, der mit SQL in das DBMS integriert ist. Ein mit einem Ereignis (insert, delete, update) verbundene Aktion, die eine Veränderung im Relationsinhalt nach sich zieht. (zusammengesetzte) SQL-Anweisung, die automatisch bei einer Änderung einer benannten Tabelle ausgeführt wird. Wird verwendet um referenzielle Integrität zu erzwingen, komplexe Geschäftsregeln durchzusetzen und Datenveränderungen zu überwachen. Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick Applikationsebene: Stored Procedures Trigger TP-Lite Trigger: inserted/deleted delete Trans insert Kopie der veränderten Daten Modell Typ Höhe Farbe Blizzard Tourenrad 26 Blau Flash Rennrad 26 Blau Jockl City-Bike 28 Rot Extreme Tourenrad 20 Weiss Boulder Bonanza 20 Rot Deleted (upd_old) Kopie der eingefügten Daten Modell Typ Höhe Farbe Runner Rennrad 26 Schwarz Boulder Bonanza 28 Rot Inserted (upd_new) Modell Typ Höhe Farbe Extreme Tourenrad 20 Weiss Boulder Bonanza 20 Rot Trigger Integritätsprüfung H A U P T S P E I C H E R Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick Integrity Rules Stored Procedures Trigger TP-Lite TP Lite Applikationscode ist ins DBMS integriert, wird auf dem Server ausgeführt. Funktionalität des DBMS ist erweitert. Keine Transaktionen zwischen heterogenen DBMS. Verschiedene aufgerufene SPs laufen als unterschiedliche Transaktionen. Jeder Aufruf initiiert einen neuen Serverprozess (im Unterschied zu TP Heavy) Bsp.: MSSQL: Stored Procedures; Informix: user defined routines) Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick Applikationsebene: Stored Procedures Trigger TP-Lite Transaktionalität auf DBMS-Ebene Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick DBMS: Rules Logging Locks Validierung Entity Rule Farbe Blau Grün Gelb In einer Grundrelation sind Null-Werte nicht zulässig. Schwarz violett rot <Null> Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick DBMS: Rules Logging Locks Validierung Integrity Rules Ein Eckstein des relationalen Modells, sichergestellt durch referentielle Integrität. Referentielle Integrität: Jede Wertausprägung eines Foreign Keys muß mit einer Wertausprägung eines Primary Keys in einer verknüpften Tabelle übereinstimmen. Farbe Blau Grün Gelb Schwarz violett rot weiss FK PK Modell Typ Höhe Farbe Bizzard Tourenrad 26 Blau Flash Jockl Extreme Rennrad City-Bike Tourenrad 26 28 20 Blau Rot Weiss Boulder Bonanza 20 Weiss Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick DBMS: Rules Logging Locks Validierung Enterprise Rules Vom Unternehmen festgelegte Bedingungen, die die Regeln der realen Welt in der Datenbank abbilden. Abteilung 5 20 MA max. Tabelle „Mitarbeiter“ darf maximal 20 Personen enthalten, die Abteilung 5 zugeordnet sind. Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick DBMS: Rules Logging Locks Validierung Logging: Log-Writer Database Buffer BenutzerProzesse Shared Pool DBWR Redo Log Buffer LGWR Online Redo Log-Dateien Datendateien Archive Offline Redo Log-Dateien Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick DBMS: Rules Logging Locks Validierung Logging einer Transaktion Schreib-Transaktionen werden in ein Log geschrieben, bevor sie auf der Datenbank ausgeführt werden. Commits werden ins Log geschrieben, nachdem sie auf der Datenbank durchgeführt wurden. Logbuch: 1. <T1 Start> 2. <T1 Konto 1 700, 600> 3. <T1 Konto 2 200, 300> 4. 5. 6. 7. <T1 Commit> Datenbank: <Konto 1 Update 600> <Konto 2 Update 300> <Commit> Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick DBMS: Rules Logging Locks Validierung Arten von Sperren: R/W Lesesperre (Rlock): hat eine Transaktion eine Lesesperre auf ein Objekt gesetzt, darf keine andere Transaktion darauf schreiben. Schreibsperre (Xlock): hat eine Transaktion eine Schreibsperre auf ein Objekt gesetzt, darf keine andere Transaktion darauf lesen oder schreiben. Kopatibilitätsmatrix: Angeforderte Rlock Sperre: Xlock Gehaltene Sperre: Rlock Xlock Ja Nein Nein Nein Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick DBMS: Rules Logging Locks Validierung Arten von Sperren: Granularität Ein modernes DBMS errichtet automatisch Sperren auf der kleinsten möglichen Ebene. Rowlock Modell Typ Höhe Farbe Blizzard Tourenrad 26 Blau Flash Rennrad 26 Blau Jockl City-Bike 28 Rot Extreme Tourenrad 20 Weiss Boulder Bonanza 20 Rot Tablock Modell Typ Höhe Farbe Blizzard Tourenrad 26 Blau Flash Rennrad 26 Blau Jockl City-Bike 28 Rot Extreme Tourenrad 20 Weiss Boulder Bonanza 20 Rot DML-Lock: Pagelock Blocksperre Keine Manipulationsänderungen DDL-Lock: Keine Definitionsänderungen Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick DBMS: Rules Logging Locks Validierung Arten von Sperren: Isolationsgrade Read_Uncommited: Daten können jederzeit gelesen werden. Read_Committed: Nur bestätigte Daten können gelesen werden. Repeatable Read: Dieselbe Anfragen liefern dasselbe Resultat. Serializable: Transaktionen, die gemeinsame Daten benutzen, werden faktisch nacheinander ausgeführt. Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick DBMS: Rules Logging Locks Validierung Fehler 4: Deadlocks 1. <T1: Start> 2. <T1: writelock (Konto 1)> 3. <T1: read (Konto 1)> 4. <T1:write (Konto 1)> 5. 6. 7. 8. <T1: writelock (Konto 2)> 9. T1 wartet auf T2 <T2: Start> <T2: writelock (Konto 2)> <T2: read (Konto 2)> <T2: writelock (Konto 1)> T2 wartet auf T1 Deadlock! Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick DBMS: Rules Logging Locks Validierung Two-Phase-Locking Jedes Datenelement wird vor dem Zugriff gesperrt und irgendwann nach dem Zugriff wieder freigegeben. In der 1. Phase werden Sperren nur angefordert, in der zweiten Phase nur freigegeben. In der 2. Phase darf eine Transaktion keine Sperren mehr anfordern, da sonst ein nicht serialisierbarer Ablauf entstehen könnte. Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick DBMS: Rules Logging Locks Validierung Two-Phase-Locking: Beispiel 1. <T1: Start> 2. <T1: writelock (Konto 1)> 3. <T1: write (Konto 1)> 4. <T1: unlock (Konto 1)> 5. 6. 7. 8. 9. 10. 11. 12. 13. <T1: writelock (Konto 2)> 14. <T1: write (Konto 2)> 15. <T1: unlock (Konto 2)> 16. <T1: Commit> Ende 1. Phase <T2: Start> <T2: readlock (Konto 1)> <T2: read (Konto 1)> Fehler! <T2: readlock (Konto 2)> Phantom Problem <T2: read (Konto 2)> <T2: unlock (Konto 1)> <T2: unlock (Konto 2)> <T2: Commit> Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick DBMS: Rules Logging Locks Validierung Transaktionen: Serialisierbarkeit Nebenläufige Transaktionen steigern die Performance. ? Nebenläufige Transaktionen gefährden die Konsistenz. Serialisierbarkeit durch Schedules Serialisierbarkeit ist der parallele Ablauf von Transaktionen in einer Weise, die einem seriellen Ablauf entspricht. Schedule: serialisierte, performance-optimierte und konsistenzsichernde Verzahnung von Transaktionen Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick DBMS: Rules Logging Locks Validierung Serialisierung: Schedule Serialisierbare Schedules gewährleisten, dass die einzelnen Schritte der verschiedenen Transaktionen serialisierbar sind (also nebeneinander ausgeführt werden können). Der Scheduler (System-Komponente) prüft die Transaktionen auf Serialisierbarkeit. Der Scheduler setzt und löscht Sperren automatisch. Dadurch wird die Serialisierung und Verzahnung der beteiligten Transaktionen gewährleistet. Konfliktserialisierbarkeit Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick DBMS: Rules Logging Locks Validierung Serialisierbarkeitsgraph Ein Pfeil führt von Transaktion Tm zu Transaktion Tn, wenn Tm vor Tn auf dasselbe Datenbankobjekt zugreift und mindestens eine Operation eine Schreiboperation ist. Enthält der Serialisierbarkeitsgraph keine Zyklen, sind die Transaktionen serialisierbar. Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick DBMS: Rules Logging Locks Validierung Serialisierbarkeitsgraph: Beispiel T1, T2, T3 bilden den Schedule S - T1 liest A, bevor T2 A schreibt: Pfeil von T1 nach T2 - T2 schreibt A bevor T3 A liest: Pfeil von T2 nach T3 - T3 liest B, bevor T1 B schreibt: Pfeil von T3 nach T1 Der Serialisierbarkeitsgraph ist zyklisch, die Transaktionen sind nicht serialisierbar. T1 T3 T2 Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick DBMS: Rules Logging Locks Validierung Drei-Phasen Validierung Alle Transaktionen werden zunächst ohne Rücksicht auf Konflikte durchgeführt und anschließend wird geprüft, welche parallel ablaufen durften und welche nicht. 1. Phase: Transaktionen dürfen in der Datenbank nur lesen, Schreiboperationen werden ins Logbuch eingetragen. 2. Phase (Validierungsphase): das DBMS testet, welche Konflikte die Transaktion mit parallelen Transaktionen hat. 3. Phase: falls die Validierung erfolgreich war, werden die Schreiboperationen aus dem Logbuch in die DB übertragen; falls nicht, wird die Transaktion nach Abschluss der parallelen Transaktionen nochmals durchgeführt. Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick DBMS: Rules Logging Locks Validierung Mögliche Validierungszustände 1. Transaktionen wurden beendet, bevor die neue Transaktion begann: T1: R/W keine Validierung notwendig. 2. Transaktionen, die während der Lesephase T2: R/W der neueren Transaktion ihre Schreibphase beendeten: Validierung der Schreiboperationen der älteren gegen die Leseoperationen der T1: W ? T2: R neueren Transaktion. 3. Transaktionen, die während der Validierungsphase der neueren Transaktion ihre Schreibphase beendete: Validierung der Schreiboperationen der T1: W älteren gegen Lese- und Schreiboperationen ? T2: R/W der neueren Transaktion. Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick DBMS: Rules Logging Locks Validierung Ausblick: verteilte Systeme Einfache und schnelle Verknüpfung der Anwendungssysteme auf Basis flexibeler Kollaborationsszenarien. Unternehmensübergreifende Interoperabilität auf Basis einer gemeinsam genutzten Plattform. Zukünftige ERPLösung Datenverarbeitung nahezu in Echtzeit über alle Applikationen, hinweg. Hohe Datenqualität durch unternehmensübergreifend integrierte Verwaltung verteilt gehaltener und gepflegter Datenbestände. Quelle: Detecon White Paper: ERP-Strategien im Collaborativen Busniess, März 2003 Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick Interaktion Two Phase Commit Three Phase Commit TP Heavy Transaktionen der Zukunft Quelle: Detecon White Paper: ERP-Strategien im Collaborativen Busniess, März 2003 Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick Interaktion Two Phase Commit Three Phase Commit TP Heavy Two-Phase-Commit 1. Phase: Prepare-to-Commit-Anfrage des Koordinators an alle Teilnehmer, die Transaktion vorzubereiten (Can Commit?). Die Teilnehmer führen die Operatonen aus und antworten mit „Ready to Commit!“. 2. Phase: Der Koordinator sendet je nach Reaktion der Teilnehmer (Ready/Not Ready) sein globales Commit oder Abort. Die Teilnehmer antworten mit „Have Committed“. Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick Interaktion Two Phase Commit Three Phase Commit TP Heavy Three-Phase Commit 1. Phase: Prepare-to-Commit-Aufruf des Koordinators an alle Teilnehmer, ihre Operationen auszuführen (Can Commit?). Die Teilnehmer führen die Operationen aus und antworten mit „Ready!“. 2. Phase: Der Koordinator sendet je nach Reaktion der Teilnehmer (Ready/Not Ready) eine Prepare- oder Abort-Aufforderung. Die Teilnehmer antworten mit „Acknowledged“. Schlägt der Koordinator fehl, führen die Teilnehmer automatisch einen Abort durch. 3. Phase: Sendet ein Teilnehmer kein „Acknowledged“ gibt der Koordinator einen globalen Abort aus, bestätigen alle Teilnehmer positiv, sendet der Koordinator ein globales Commit. Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick Interaktion Two Phase Commit Three Phase Commit TP Heavy Transaktionsmonitoring: TP-Heavy ACID-Aktualisierungen werden durch mehreren heterogenen Ressourcenmanagern durchgeführt und bleiben trotzdem im Rahmen einer einzigen Transaktion. Garantierte Neutralität gegenüber Ressourcen. Multiplexing der Client-Anfragen: TP-Monitor ist „Platzanweiser“ und weist DLL-Ausführungen Serverklassen (Pools von bereits laufenden Prozessen oder Threads) zu (Trichterfunktion). Bei Bedarf erzeugt der TP-Monitor neue Serverklassen (load balancing) Priorisierung der Anfragen (RPCs, MOM-Queues, Batch-Läufe etc.) Einleitung Definitionen ACID-Eigenschaften Nebenläufigkeit Transaktionssicherung Ausblick Interaktion Two Phase Commit Three Phase Commit TP Heavy Vielen Dank für Ihre Aufmerksamkeit! Ende
