Data-Tier Aufgaben und Dienste

Data-Tier Aufgaben und Dienste
 Arno Schmidhauser Letzte Revision: Juli 2006 Webseite: Inhalt I Einleitung II Transaktionsmodell III OLTP, OLAP, Data Warehouse IV Verteilte Datenbanken V Verteiltes Transkationsmanagement VI Messageing und verteilte Transaktionen VII Replizierte Datenbanken

I Übersicht Die Konzeption von Frameworks wie Java EE legt viel Wert auf Skalierbarkeit, Performance und Verlässlichkeit. Die Realisierung dieser Eigenschaften erfordert eine klare Aufgabenteilung zwischen Business Tier und Data Tier. Vergleicht man heute das JPA mit einer typischen Datenbank, so sind gewisse Überlappungen festzustellen. Beispielsweise bietet das JPA eine Versionenverwaltung von Objekten für das Concurrency Control an, was eigentlich eine typische Datenbank-Aufgabe darstellt. Datenbanken stellen andererseits immer mehr Funktionalität zur Verfügung in Form Triggern, Stored Procedures, einbaubarem Java- oder C#-Code usw. Dieses sind jedoch typische Aufgaben des Business Tiers, da ihr Lebenszykus nicht mit demjenigen der Daten übereinstimmt. In diesem Skript sollen die Kernaufgaben des Data Tier bezüglich OLTP Applikationen betrachtet werden, insbesondere auch in einem Umfeld mit grossen Datenmengen und hoher Last.

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 Client Tier Web Tier Business Tier Data Tier Data Warehouse-Clients Data Watehouse-Srvices

II Transaktionsmodell
Ein Transaktionsmodell ist notwendig, weil letzlich die phyischen Resourcen bestimmten Einschränkungen unterliegen: Der Zeitbedarf für eine Abfrage oder Änderung ist nicht beliebig klein. Speichermedien sind nicht beliebig gross und der Zugriff darauf nicht beliebig schnell. Programme, Hardware und Kommunikationskanäle können fehlerhaft sein. Aus diesen Gründen ist eine Zusammenarbeitsvereinbarung zwischen den Clients und der Datenbank notwendig. Das Transaktionsmodell definiert die Grundsätze dieser Zusammenarbeit.

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 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. Die Einhaltung der ACID-Regel ist ein zentraler Grundsatz aller Datenbanksysteme. Atomarität Eine Transaktion kann alle gewünschten Operationen durchführen, oder sie hat gar keine Auswirkungen auf den Zustand der Datenbank ("Alles oder Nichts"-Prinzip). In Fehlersituationen kann eine Transaktion durch das Applikations-programm oder durch das DBMS abgebrochen werden. Das DBMS ist dafür verantwortlich, dass dann alle Änderungen am Datenbestand seit Beginn der Transaktion rückgängig gemacht werden (Undo-Recovery). Konsistenz Bei Abschluss der Transaktion muss ein konsistenter Datenbankzustand vorliegen. Jede im DBMS enthaltene Integritätsregel muss spätestens beim Abschluss der Transaktion erfüllt sein. An einer umfassenden Konsistenzerhaltung ist natürlich auch die Applikation beteiligt, weil es praktisch unmöglich ist, alle Forderungen in Form von Constraints (siehe Folien über Constraints) in der Datenbank zu realisieren. Isolation Die Datenbank muss so erscheinen, wie wenn sie jedem Benutzer einzeln gehörte: Laufen mehrere Transaktionen quasi-parallel ab, so müssen die einzelnen Transaktionen so gesteuert werden, dass sie gegenseitig voneinander nichts merken (Wenigstens in Bezug auf den Datenzustand und die Abfrageresultate, sicher nicht vollständig in Bezug auf die Performance). Dauerhaftigkeit Nach Abschluss einer Transaktion sind die von ihr ausgeführten Änderungen gegen alle Arten von Ausfällen gesichert. Auch Prozessabstürze und Plattenfehler dürfen nicht zu Datenverlust führen.

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. Beispiel einer korrekten Transaktion: /* beginn der Transaktion durch ersten select-Befehl */ select * from Person delete from Person where name = 'Müller' commit /* Alle Änderungen sind nun definitiv */ Beispiel einer durch den Benutzer abgebrochenen Transaktion: delete from Person where name = 'Müller' rollback /* Änderungen werden rückgängig gemacht */ Eine Transaktion kann aus verschiedenen Gründen durch das Datenbanksystem zwangsweise abgebrochen werden: Deadlock von zwei Benutzerprozessen Verletzung von Zugriffsrechten oder Integritätsbedingungen Crash rsp. Verbindungsabbruch des Benutzerprozesses Das Datenbanksystem liefert dem Benutzer einen Fehlerstatus zurück. Diesen auszuwerten und ev. einen fehlgeschlagenen SQL-Befehl oder eine Transaktion zu wiederholen, ist Sache der Applikation.

Transaktion einzelner SQL-Befehl
Auch das reine Lesen von Daten kann ausdrücklich nur innerhalb einer Transaktion geschehen. Es werden zwar keine Daten verändert, der Anfangs- und der Endzustand sind daher derselbe, aber es wird ausdrücklich verlangt, dass ein konsistenter (korrekter) Zustand gelesen wird. Damit dies vom Datenbankmanagementsystem auch bei mehreren konkurrenzierenden Benutzern der Datenbank richtig gehandhabt werden kann, müssen z.B. Lesesperren auf die gelesenen Daten gesetzt werden. Dies beeinflusst wiederum schreibende Transaktionen, die warten müssen, bis die Lesetransaktionen beenden und damit (implizit) ihre Sperren freigeben. Letzlich kann nur der Datenbankbenutzer entscheiden, wann alle Änderungen oder Abfragen, die zu einem korrekten Zustandsübergang gehören, ausgeführt sind. Das Absetzen des commit-Befehles ist daher Sache des Datenbank-Benutzers (Clients) und nicht des Datenbanksystems. Das Datenbanksystem kann allenfalls prüfen, ob gewisse Integritätsregeln verletzt sind und die Transaktion zwangsweise abbrechen und zurücksetzen. Beispiel: Gemäss ERD wird verlangt, dass zu einer Person immer mindestens eine Adresse gehört. Das Eingeben einer neuen Person mit einer oder mehrerer Adressen ist nun Sache des Benutzers. Das DBMS kann nicht selber Adressen zu einer Person erzeugen. Es kann lediglich bei Abschluss der Transaktion prüfen ob mindestens eine Adresse da ist. Im allgemeinen gilt also auch: Transaktion einzelner SQL-Befehl Allerdings arbeiten viele Datenbanksysteme per Default in einem "Autocommit"-Modus, d.h. nach jedem SQL-Befehl wird durch das DBMS ein commit-Befehl ausgelöst. In sehr vielen Fällen ist das jedoch im Sinne des Datenmodells falsch und kann zu einem scheinkorrekten Zustand der DB führen. Eine Datenbank muss sich jederzeit in einem konsistenten (korrekten) Zustand befinden. Dies ist der Fall, wenn sich ihre Datenwerte mit allen Integritätsbedingungen vertragen, ihre Datenwerte mit der gegenwärtigen Realität übereinstimmen, alle relevanten Daten vollständig in der Datenbank vorhanden sind. Verletzungen der ersten Bedingung haben meist technische Ursachen, z.B. Speicherüberlauf, Systemabsturz, Disk-Crash, Hardware-Fehler, logische Fehler in der Applikation. Die beiden letzten Bedingungen können nur über organisatorische Massnahmen garantiert werden, es sei denn, die Datenbank arbeitet beispielsweise mit einem automatisierten Produktionssystem zusammen. Eine Transaktion wird immer über eine Verbindung (Session) mit der Datenbank abgewickelt. Eine Verbindung kann gleichzeitig nur eine Transaktion bedienen, und ein Verbindungsabbruch hat immer einen Transaktionsabbruch zur Folge. Über eine Verbindung werden nacheinander eine oder mehrere Transaktionen abgewickelt. Eine Transaktion sollte möglichst rasch abgewickelt werden, da sie immer Resourcen reserviert, welche anderen Transaktionen nicht zur Verfügung stehen. Jede Transaktion ist im DBMS meist ein eigener Thread. Die Transaktions-Threads konkurrieren um die vorhanden Resourcen.

Das Recovery-System Zweck Logfile Fehlerbehebung

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 Das Recovery-System bestimmt wesentlich die Performance eines Datenbanksystems. Eine Faustregel geht von Transaktionen pro Sekunde aus. Die Zahl ergibt sich dadurch, dass spätestens bei Transaktionsende für jede Änderungstransaktion einige I/O-Pages ungepuffert auf das Logfile geschrieben werden müssen. Bei hoher Transaktionslast kann die Anzahl Transaktionen pro Sekunde z.B. wesentlich erhöht werden, wenn die Änderungen mehrerer Transaktionen zusammen auf das Logfile geschrieben werden können ("grouped commit"). Ein Transaktionsfehler kann vielseitige Ursachen haben: Deadlock, Verbindungsabbruch, Verletzung von Integritätsbedingungen, expliziter Rollback durch Applikation oder einen Trigger, Rechteverletzung usw.

Fehlerarten Transaktionsfehler Rollback-Befehl durch Applikation
Verletzung von Integritätsbedingungen Verletzung von Zugriffsrechten Deadlock Verbindungsunterbruch oder Client-Crash Systemfehler Stromausfall, Hardware- oder Memory-Fehler Transaktionsfehler sind relativ häufig und müssen effizient gehandhabt werden. Die Aufgabe der Datenbank ist es, den Zustand der Daten wie vor der Transaktion wieder herzustellen. Bei Systemfehlern (auf Serverseite) gehen laufende Transaktionen und alle Memory-Inhalte des Servers verloren. Die Aufgabe des Datenbanksystems beim Restart ist es, den jüngsten korrekten Zustand der Datenbank wieder herzustellen. Dazu müssen die Änderungen aller zum Fehlerzeitpunkt laufenden Transaktionen rückgängig gemacht werden. Die Änderungen aller zum Fehlerzeitpunkt korrekt abgeschlossenen Transaktionen, welche aber nur im Memory abgelegt waren, müssen anhand des Logfiles rekonstruiert werden. Bei Plattenfehlern hilft nur eine Wiederherstellung der Datenbank aus speziellen Backup-Kopien (On-Line-Backups). Die Aufgabe der Datenbank besteht darin, regelmässig solche Backups herzustellen.

Beachte, dass eine wegen einem Deadlock abgebrochene Transaktion nicht durch das DBMS wiederholt werden kann! Beispiel: begin transaction select lohn from Mitarbeiter where mitarbId = 9 // Applikation berechnet: neuer_lohn = f(lohn) update Mitarbeiter set lohn = neuer_lohn where mitarbId = 9 // hier beispielsweise Deadlock ... Durch den Abbruch der Transaktion werden die Sperren auf dem Mitarbeiter-Datensatz freigegeben. Das DBMS kann also nicht garantieren, dass das Attribut lohn noch denselben Wert hat wie beim ersten select. Da es die Funktion f nicht kennt, kann es nicht entscheiden, ob der update nochmals durchgeführt werden darf oder nicht.

Ablauf von Modifikationsbefehlen
SQL-Befehl eines Clients 2. Neue Datenwerte Workspace 1. Alte und neue Datenwerte Im Logfile werden die Datensätze mit ihrem neuen und alten Zustand abgelegt. Damit ist grundsätzlich eine Wiederherstellbarkeit der Datenbank nach vorwärts wie nach rückwärts gewährleistet. Der Workspace ist ein von der Datenbank vollständig kontrollierter Cache der permanenten Datenbank (DB-Storage). Hier befinden sich alle in Gebrauch stehenden Datensätze. Der Workspace wird zu bestimmten Zeitpunkten auf die permanente Datenbank zurückgeschrieben. Die Bewirtschaftung des Logfiles kann nach zwei Strategien erfolgen: Jeder SQL-Befehl wird sofort und ungepuffert protokolliert. Damit besteht keine Abhängigkeit vom Status des Workspace und des Ausführens eines Checkpoints. Gleichzeitig ist diese Variante aus Performance-Sicht etwas langsam. 2. Das Logfile hat einen eigenen Cache. Dieser muss jedoch spätestens beim Commit-Befehl oder vor einem Checkpoint in das permanente Logfile übertragen werden. Vorteil: mehrere commit-willige Transaktionen können zusammengefasst werden und deren Änderungen in einem Durchlauf vom Cache des Logfiles in das permanente Logfile geschrieben werden. Nachteil: Schwieriger zu implementieren für den DB-Hersteller. Eine Applikation muss eventuell auf den Commit-Befehl etwas länger warten. Die Variante 2 ist aus globaler Sicht effizienter, aus lokaler Applikationssicht kann sie schlechter sein. Checkpoint (Gelegentlich) Logfile DB-Storage

Logging, Beispiel M11 T1 M21 M22 T2 M31 M32 T3 M41 M42 T4 Zeit
Das hier vorgestellte Logging dient der Behebung von Transaktions- und Systemfehlern. Es gibt verschiedenste Varianten in der Logging-Technik. Die hier präsentierte entspricht einem "guten Durchschnitt" der bekannten DB-Systeme, ohne allzu stark auf Details einzugehen. Sehr genaue Informationen sind in [3] zu finden. Das Logfile Jeder Eintrag im Logfile ist mit einer LSN (Log Sequence Number) eindeutig identifiziert. Die LSN entspricht der Adresse des Eintrages. Alle Einträge einer bestimmten Transaktion sind untereinander rückwärtsverkettet, damit eine effiziente Behandlung von Transaktionsfehlern möglich ist. Alle Einträge im Logfile müssen permanent sein. Das Schreiben in das Logfile darf nicht gepuffert sein. Jede Änderung am Transaktionsstatus eines Client-Prozesses wird im Logfile festgehalten. Es wird also der Beginn einer Transaktion (BOT), der Commit (CMT) oder Rollback (RBK) festgehalten. Ein Rollback-Eintrag wird durch das Datenbanksystem auch erzeugt, wenn der Transaktionsabbruch erzwungen ist, z.B. durch einen Deadlock. Bei jedem SQL-Befehl, der Änderungen am Datenbestand zur Folge hat, werden die alten und neuen Datenwerte, inkl. Transaktionsnummer und Verweis auf die zugehörige Datenadresse in der Hauptdatenbank, protokolliert. In der Regel werden ganze I/O-Page in das Logfile geschrieben (physisches Logging). Die Platzverschwendung steht dabei einer effizienten Wiederherstellung der Datenbank gegenüber. Eine I/O-Page mit den alten Werten ("Before-Image") wird für die Wieder-herstellung des Datenbankzustandes bei nicht korrekt abgeschlossenen Transaktionen verwendet. Eine I/O-Page mit neuen Werten ("After-Image") wird zur Wiederherstellung nach Systemfehlern benötigt, wenn eine Transaktion zwar korrekt beendet wurde, deren neue Datenwerte aber noch nicht vom Datenbank-Buffer in die physische Datenbank (Festplatte) geschrieben werden konnte. 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

Jeder Checkpoint (siehe unten) mit Verweisen auf die laufenden Transaktionen wird ebenfalls im Logfile festgehalten. Checkpoint Als Checkpoint bezeichnet man den Zeitpunkt, an dem modifizierte I/O-Pages im Workspace der Datenbank auf das Speichermedium (Festplatte) geschrieben werden. Aus der Sicht von Benutzerprozessen möchte man möglichst wenige Checkpoints durchführen, da diese die Performance negativ beeinflussen. Aus Sicht einer raschen Wiederherstellung der Datenbank nach einem Crash möchte man möglichst viele Checkpoints durchführen. Zwingend wird ein Checkpoint, wenn der Workspace für alle modifizierten Seite zu klein wird. Nach dem Checkpoint können alte, nicht mehr benötigte I/O-Pages, ob geändert oder nicht, entfernt werden. Grösse des Logfiles jede Änderung eines Datensatzes erfordert die Speicherung des alten und des neuen ganzen Datensatzes im Logfile. Eingefügte resp. gelöschte Datensätze erfordern das Abspeichern des Datensatzes im Log. Die Grösse des Logfiles wächst also proportional zur Anzahl Änderungen. Da das Logfile häufig für inkrementelle Backups verwendet wird, muss genügend Platz für alle Änderungen zwischen zwei Backups vorhanden sein: Grösse = a * ( ( ( m * g * 2 ) div p ) + p ) a = Anzahl Transaktionen, die im Logfile aufbewahrt werden müssen m = Anzahl geänderte Datensätze pro Transaktion g = Grösse eines geänderten Datensatzes div = Ganzzahl-Division, ( 3 div 2 ist also beispielsweise 0 ) p = Seitengrösse der Datenbank (typischerweise ca Bytes) Beispiel: * ( ( 10 * 2 * 1000 ) div ) = 200 MB Eine exakte Berechnung ist schwierig, da weitere Hilfsinformationen im Logfile abgelegt werden, was die Grösse erhöht. Eventuell können Transaktionen zusammengefasst werden, wenn sie zeitlich sehr nahe beeinanderliegen, was die Grösse verkleinert. Gewisse Datenbanken bewahren nur die neuen Datenwerte auf, weil die alten ausschliesslich im Cache gehalten werden. Dann entfällt der Faktor 2. Gelegentlich wird auch mit einem logischen Logfile (Befehlslog) gearbeitet.

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
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. Beim Restart des Datenbanksystems wird folgendes Recovery-Prozedere angewendet: Ausgehend vom letzten Checkpoint werden Gewinner- und Verlierer-Transaktionen ermittelt. Gewinner sind alle, für die ein Commit-Eintrag existiert. Verlierer sind alle, für die ein Rollback oder gar kein Eintrag vorliegt. In einem Redo-Lauf werden alle I/O-Pages in den Workspace zurückgeladen. Es müssen nur I/O-Pages berücksichtigt werden, die jünger als der letzte Checkpoint sind. In einem Undo-Lauf werden von den Verlierer-Transaktionen alle I/O-Pages mit den alten Datenwerten ("Before-Images") in den Workspace zurückgeladen. Das Logfile wird hierzu rückwärts abgearbeitet. Die Logfile-Einträge müssen zurückreichen bis zum Beginn der ältesten beim letzten Checkpoint noch laufenden Transaktion. Beachte, dass bei Verlierer-Transaktionen auch alle 'Before-Images' vor dem Checkpoint benötigt werden. Wurde nämlich eine Verlierer-Transaktion bei einem Rollback (nach dem Checkpoint) bereits einmal zurückgesetzt, ist diese Rücksetzung durch den Systemfehler ev. zunichte, wenn noch kein weiterer Checkpoint stattgefunden hat. Anschliessend an das Recovery wird ein Checkpoint ausgelöst und die Datenbank für den Multiuser-Betrieb freigegeben.

Neuere Datenbanktechnologien (Objektdatenbanken) verfolgen einen Pure-Redo Strategie. Diese geht davon aus, dass sämtliche Änderungen einer Transaktion bis zum commit-Befehl, rollback-Befehl oder Transaktionsabbruch im Speicher des Benutzerprozesses, rsp. in einem für ihn reservierten, privaten Workspace der Datebank gehalten werden können. Bei einem Transaktionsabbruch wird einfach dieser Workspace freigegeben. Das DBMS muss lediglich noch den Abbruch der Transaktion notieren und allfällige Sperren freigeben. Bei korrektem Abschluss der Transaktion mit einem commit-Befehl werden alle modifizierten Daten (After-Images) zum DBMS übertragen, dort in das Logfile geschrieben und anschliessend in die Datenbank übertragen. Bei einem Crash des DBMS muss bei der Wiederherstellung lediglich der Inhalt des Logfiles seit dem letzten Checkpoint nochmals auf die Datenbank übertragen werden (Redo-Lauf).

Concurreny Control Zweck Serialisierbarkeit Neue Methoden

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. Isolation ist ein allgemeine Anforderung, die an die Datenbank gestellt wird. Sie bedeutet, dass eine laufende Transaktion A alle noch nicht definitiven Änderungen einer anderen laufenden Transaktion B nicht sehen darf. Das ist an sich klar, liefert aber keine Hinweise darauf, wie der Ablauf mehrerer Transaktionen zu steuern ist, damit diese parallel ablaufen können und trotzdem die Isolationsbedingung erfüllt ist. Hier nimmt man das Prinzip der Serialisierbarkeit zu Hilfe, das sehr allgemein und vorallem leicht nachprüfbar ist. Transaktionen dürfen parallel arbeiten (Daten lesen, ändern, einfügen, löschen), jedoch immer nur so, dass wenn man die Transaktionen im Nachhinein vollständig hintereinander schalten würde, dasselbe Resultat bezüglich Lesen, Ändern, Löschen Einfügen herauskommen würde, für jede einzelne der beteiligten Transaktionen. Die beiden Anforderungen Isolation und Parallelität arbeiten im Prinzip gegeneinander, wobei der Isolation die höhere Priorität zukommen muss. Ein sehr einfache Realisierung der Isolationsbedingung wäre es, die Datenbank exklusiv für die gerade laufende Transaktion arbeiten zu lassen. Alle anderen Transaktionen müssten warten, bis die gerade laufende fertig ist. Alle Transaktionen werden also faktisch hintereinandergeschaltet oder serialisiert. Das Concurrency-Control muss jedoch nur für Sserialisierbarkeit, nicht für Serialisierung sorgen. Es nimmt hierzu Locking, Timestamping und Datenversionierung als Techniken zu Hilfe. Für jede Technik muss nachgewiesen sein, dass sie die Serialiserbarkeit gewährleistet. Objekte, die durch eine Business-Methode eines Session-Beans (in einem Appserver) in Gebrauch sind, unterliegen Transaktionsgrenzen. Das Cache-Management des Appservers ist daher engstens mit den Transaktions- und Isolationsanforderungen der Datenbank gekoppelt.

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

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) Die beiden mit (s) gekennzeichneten Abläufen entsprechen dem vollständigen Nacheinander beider Transaktionen (serialisierte Abläufe). Alle anderen Abläufe müssen bezüglich Ausgabe zum Prozess, rsp. bezüglich Datenbankzustand einem der beiden serialisierten und damit korrekten Abläufe entsprechen (k), sonst sind sie falsch (f). Das Datenbanksystem muss Synchronisations-Mittel besitzen und einsetzen, damit eine hohe Parallelität gewährleistet ist. keine falschen Abläufe möglich sind ( garantierte Serialisierbarkeit ). Serialisierbarkeit löst die Frage nicht, in welcher Reihenfolge die Transaktionen am besten ausgeführt werden, sondern gibt nur an, dass eine parallele Ausführung keine anderen Resultate als eine serielle Ausführung haben darf. Die durch die sequenzielle Ausführung einer Reihe von Transaktionen erzielten Ergebnisse gelten alle als richtig. Vertauscht man auf der vorhergehenden Seite, die Statements 1.2 und 1.3 (commit bleibt am Schluss), was aus applikatorischer Sicht keinen Unterschied macht, so ergeben sich andere korrekte und falsche Abläufe. Die inkorrekten werden durch das Entstehen eines Deadlocks erkannt und behoben.

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: Das Datenbanksystem setzt für jeden SQL-Befehl automatisch entsprechende Sperren auf den ausgewählten Datenelementen. Schreibsperren werden bis zum Transaktionsende gehalten. Eine vorherige Freigabe würde die Isolationsbedingung verletzen: Vor dem Transaktionsabschluss ist nicht garantiert, dass Änderungen nicht noch rückgängig gemacht werden, sei es durch den Client (Rollback-Befehl) oder den Datenbankserver (Crash, Deadlock). Schreibsperren können nicht umgangen oder ausser Kraft gesetzt werden. Lesesperren werden ebenfalls bis zum Transaktionsende gehalten. Ein Benutzerprozess kann daher sicher sein, dass einmal eingelesene Daten in der Datenbank zwischenzeitlich nicht geändert werden. Im Gegensatz zum Sperren von Daten beim Schreiben sind aber auf Wunsch des Programmierers oder des Datenbank-Administrators verschärfte oder erleichterte Sperren beim Lesen möglich: Es dürfen X-Locks zum Lesen gesetzt werden oder man kann ohne Sperren lesen (Dirty Read). Bei gewissen Datenbanksystemen können Lesesperren auch unmittelbar nach dem Lesen, anstatt erst bei Transaktionsende zurückgegeben werden (Short Locks). Jedes Datenbanksystem hat eigene Feinheiten in der Locking Strategie, die es bei einer stark gebrauchten Datenbank zu beachten gilt, und die Ausgangspunkt für Tuning-Massnahmen sind. Einige Spezialitäten sind im folgenden beschrieben. Angeforderte Sperre Angeforderte Sperre wird gewährt (+) oder nicht gewährt (-) Bestehende Sperre

Spezialitäten Mit D-Locks (Sybase, SQL-Server) kann verhindert werden, dass zeitlich überlappende Lesesperren einen schreibwilligen Prozess dauernd vom Zugriff ausschliessen. Ein D-Lock wird von einem Schreiber angefordert, und sobald alle Lesesperren verschwunden sind, in einen X-Lock umgewandelt. Update-Locks (U) werden für die Deadlock-Verhinderung eingesetzt. U ist mit S verträglich, aber nicht mit anderen U und X. Sobald tatsächlich die gelesenen Daten geändert werden, wird U in X konvertiert. Dies ist nur möglich, wenn keine anderen Lesesperren vorhanden sind. Update-Locks sind insbesonde für das Arbeiten mit Cursorn geeignet: Die Datenbank liest die potentiell zu modifizierenden Daten relativ rasch ein, der genaue Zeitpunkt des Updates ist aber durch den Datenbank-Client bestimmt: declare c cursor for select persnr from person for update of adresse; /* Records werden mit U statt mit S gesperrt. */ update person set adresse = "neu" where current of c; /* Hier wird U in X umgewandelt. */ Null-Locks werden für unsicheres Lesen (Dirty Read) eingesetzt. Ein Null-Lock ist gar keine Sperre und ist daher mit allen anderen Locks verträglich. Der Zugriff auf die Indextabellen ist ebenfalls zu berücksichtigen, es gelten meist diesselben Regeln wie auf den eigentlichen Datentabellen. Neben den "High-Level" Locks für die eigentlichen Daten, die durch das DBMS wie oben beschrieben gehandhabt werden, kommen für den Zugriff auf Hilfsresourcen (z.B. die Locktabelle selbst) auch die Synchronisations-Mechanismen des Betriebssystems zum Einsatz, beispielsweise Semaphore, Mutex-Variablen oder Spin Locks bei Multiprozessor-Systemen.

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 Mögliche Deadlocks sind der Preis für die Anforderung hoher Parallelität. Man kann die Serialisierbarkeit auch erreichen ohne Deadlock-Bedrohung, indem die involvierten Tabellen oder Datensätze zum vornherein exklusiv gesperrt werden. Die meisten Datenbankssysteme kennen entsprechende Befehle, beispielsweise: LOCK TABLE tablename in EXCLUSIVE MODE. Damit ist aber jede Parallelität von Transaktionen verhindert.

Isolationsgrade Modus Inkonsistenzen SERIALIZABLE keine Inkonsistenzen
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 Realisierungsvarianten mit einfachem Locking Paralleliät Isolation

Phantom-Problem Hier tauch neuer Datensatz auf Phantom-Problem
Eine erste Transaktion selektiert Datensätze nach bestimmten Kriterien. Eine zweite Transaktion fügt einen neuen Datensatz ein und committet diesen. Wenn die erste Transaktion ihre Abfrage nochmals durchführt, findet sie den neuen Datensatz. Der neue Datensatz wird bezüglich der ersten Transaktion als Phantom bezeichnet. Phantome können zu Schwierigkeiten bei statistischen Auswertungen führen. Phantome können auch zu Programmierproblemen führen, wenn beispielsweise eine Abfrage abgesetzt wird, um die Anzahl Datensätze zu zählen, dann aufgrund der Zählung Speicherplatz für die zu erwartenden Datensätze bereitsgestellt wird. Wenn in der zweiten Abfrage für die eigentlichen Datensätze dann plötzlich zusätzliche Datensätze auftreten, kann dies zu Speicherüberläufen führen.

Lost-Update Änderungen von T2 gehen beim Update von T1 verloren !
Lost Update-Problem Wenn die gelesenen Daten verändert und anschliessend wieder in die Datenbank zurückgeschrieben werden kann das Problem auftreten, dass eine andere Transaktion in der Zwischenzeit die Daten ebenfalls gelesen, verändert und bereits committet hat. Die erste Transaktion wird dann beim Zurückschreiben ihrer Daten die Änderungen der anderen Transaktion zunichten machen. Der Update der anderen Transaktion geht damit verloren. Änderungen von T2 gehen beim Update von T1 verloren !

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 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 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: In den klassischen Lock-Verfahren werden nur vorhandene Datensätze gesperrt. Damit kann das sogenannte Phantom-Problem auftreten, welches eine Verletzung des Serialierbarkeits-Prinzips darstellt: Liest eine Transaktion mit obigem SQL-Befehl eine bestimmte Anzahl Datensätze ein, so sind diese Datensätze mit einer Lesesperre belegt und damit vor Änderungen durch andere Transaktionen geschützt. Eine andere Transaktion kann jedoch neue Datensätze einfügen, welche diese Bedingung erfüllen und anschliessend committen. Die erste Transaktion würde beim Nochmaligen Durchführen ihrer Abfrage diese neuen Datensätze sehen. Die neue Datensätze sind für die erste Transaktion sogenannte Phantome. In Reservationssystemen ist dies unerwünscht, weil beispielsweise folgende Situation auftreten kann: T T2 select * select * from Reservation from Reservation where resDatum > ' ' where resDatum > ' ' and resDatum < ' ' and resDatum < ' ' -> keine Datensätze gefunden, keine Datensätze gefunden, daher: daher insert Reservation(resDatum) insert Reservation(resDatum) values ( ) values ( ) Die beiden eingefügten Datensätze ergeben einen Konflikt untereinander. Würden durch obige select-Befehle nicht nur die effektiv vorhandenen Datensätze, sondern alle in Frage kommenden Datensätze gesperrt, so wäre der Konflikt nicht möglich, weil T2 auf T1 respektive T1 auf T2 warten müsste im Rahmen der insert-Operation. select * from Reservation where resDatum > ' ' and resDatum < ' '

Range Locks (2) Der Range Lock werden auf Index-Einträge gesetzt, nicht auf Datensätze, wie gewöhnliche Locks. Datensatz mit resDatum select * from Reservation where resDatum < ' ' and resDatum > ' ' Datensatz mit resDatum Tabellen in Datenbanken sind kaum nach dem Auswahl-Kriterium sortiert. Hingegen definiert ein Index auf einer Tabelle eine Sortierung, welche für das Range Locking geeignet sein kann. Durch Sperren aufeinanderfolgender Einträge in den Blattknoten eines Index kann ein Range-Lock realisiert werden. Das Datenbanksystem muss dazu den normalen Locktyp (Beispielsweise S) ergänzen mit einem Range-Lock (Beispielsweise R genannt) auf Indexeinträge. Der R-Lock sichert die Lücke zwischen dem Datensatz auf den er gesetzt ist und dem nächsten Datensatz. Spezielle Fälle: Der zu sperrende Bereich beginnt vor dem ersten (in obiger Zeichnung dem untersten) Datensatz. Das Datenbanksystem benützt in diesem Fall einen sogenannten virtuellen Indexeintrag mit dem Wert -. Damit gilt die Bereichssperre von - bis zum oberen gewählten Wert. Die Tabelle enthält keine Datensätze. Das Datenbanksystem benützt in diesem Fall einen sogenannten virtuellen Indexeintrag mit dem Wert -. Damit gilt die Bereichssperre von - bis +. Das ergibt das gleiche Verhalten wie eine komplette Tabellensperre. Im Gegensatz zum Sperren von ganzen Tabellen, sind bei der Verwendung von Range Locks noch viele Datensätze für das Lesen und Schreiben durch andere Transaktionen verfügbar. Eine Voraussetzung für Range-Locks ist allerdings, dass die Abfragebedingung über einen Index abgearbeitet werden. Unter Umständen muss ein entsprechender Index erzeugt werden. Je mehr Datensätze eine Tabelle enthält und je besser deren Werte über den Wertebereich verteilt sind, umso vorteilhafter sind Range Locks. Datensatz mit resDatum Datensätze mit gesetztem Range Lock Datensatz mit resDatum Wirkungsbereich des Range Locks

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. Das Versionenverfahren hat einen enormen Performance-Gewinn in hochbelasteten Systemen zur Folge. Insbesondere werden heute immer mehr OLAP und OLTP Abfragen auf der gleichen Datenbank durchgeführt. Das Versionenverfahren entschärft die Konkurrenz auf den gemeinsamen Daten. OLAP = Online Analytical Processing: Umfangreiche lesende Abfragen auf Daten für statistische Angaben. Beispiel: Einem Amazon-Kunden wird angezeigt, wieviele andere Kunden dasselbe Buch und welche anderen Bücher diese Kunden gekauft haben, und wieviel Prozent der Gesamtbestellungen dieses Buch ausmacht. Das Zusammenstellen dieser Information erfordert recht komplexe SQL-Abfragen, welche natürlich einen gewisssen Zeitbedarf haben. Wenn gerade viele Kunden Amazon benützen, können sich deren Abfragen zeitlich lückenlos überlappen. Wenn Abfragen und Änderungen (beispielsweise das Einfügen einer neuen Bestellung) über Lock-Mechanismen koordiniert werden, sind Schreiboperationen während einer Leseoperation (Abfrage) ausgeschlossen. Die zeitlich überlappenden Abfragen führen zu einer grossen Behinderung oder sogar einem vollständigem Ausschluss von Schreiboperationen. Mit einem Versionenverfahren ist dies ausgeschlossen. OLTP = Online Transaction Processing: Viele ähnliche, einfache und zu einem Grossteil schreibende SQL-Operationen. Das Einfügen einer neuen Bestellung ist typischerweise ein OLTP-Vorgang.

Versionen, Leser gegen Schreiber
Lesende Transaktion/Befehl, TNC = 6 6 Lesende Transaktion/Befehl, TNC = 5 4 Schreibende Transaktion/Befehl, TNC = 4 2 Lesende Transaktion/Befehl, TNC = 3 1 Datensatz X, TNC = 2 Kopie des Datensatz 3 Es wird eine Nummerierung der laufenden Transaktionen oder SQL-Befehle benötigt: Jeder Transaktion resp. jedem Modifikationsbefehl wird aus einem globalen Zähler (TNC=Transaction Number Counter) des Datenbanksystems ein fortlaufender Wert zugeteilt. 1. Ändert eine Transaktion einen Datensatz, wird der Datensatz eingelesen mit der bestehenden TNC. Beim Zurückschreiben wird diese TNC mit der neuesten Version in der Datenbank verglichen. Stimmt diese noch mit dem eigenen TNC überein, wird der Datensatz zurückgeschrieben und ihm der TNC der eigenen Transaktion zugewiesen, ansonsten wird ein Rollback durchgeführt. 2. Greift eine Transaktion T lesend auf einen Datensatz zu, erhält sie die Version mit dem grössten TNC der a) noch kleiner als der TNC von T ist, b) nicht in der Liste aller Transaktionen vorkommt, die beim Start von T aktiv waren. Damit wird ausgeschlossen, dass vor T gestartete Transaktionen einen Datensatz ändern (oder einfügen) und committen und dieser dann plötzlich für T sichtbar wird. Damit wird das Phantomproblem gelöst, und sichergestellt, dass T über seine ganze Lebenszeit die gleiche Version eines Datensatzes liest. Eine Version im Versionen-Pool kann gelöscht werden, wenn es eine jüngere Version gibt, die älter als die älteste laufende Transaktion ist. Datensatz X, TNC = 4 commit 5 Datensatz X, TNC = 2 Kann gelöscht werden 7 Datensatz X, TNC = 1

Versionen, Schreiber gegen Schreiber
Schreibende Transaktion, TNC = 4 2 Datensatz X, TNC = 2 Kopie Datensatz 4 Schreibende Transaktion, TNC = 3 1 Datensatz X, TNC = 2 Kopie Datensatz 3 Änderungsbefehl 7 commit: abort, weil TNC 2  max TNC im Pool  Obige Animation zeigt eine Konfliktsituation mit mehreren Schreibern auf. Varianten des Versionenverfahrens Auf Bedingung 2.b) wird verzichtet. Das ergibt einen kleineren Verwaltungs-aufwand für die Datenbank. Allerdings kann das Phantom-Problem entstehen und es ist nur noch der Isolationsgrad REPEATABLE READ statt SERIALIZABLE garantiert. Beim Ändern eines Datensatzes wird mit einer Schreibsperre gearbeitet. Es wird zuerst geprüft, ob eine andere Schreibsperre besteht. Wenn ja, muss gewartet werden. Wenn nein, wird eine unveränderte Kopie der aktuellen Version in den Pool abgespalten (Für lesende Transaktionen), dann wird die aktuelle Version gesperrt für den Schreiber. Die Sperre wird mit dem Commit freigegeben und der neue, freigegebene Datensatz bekommt die TNC der Schreibtransaktion. Es kann ohne Schreibsperre oder ohne Vergleich des TNC beim Zurückschreiben gearbeitet werden Dann ergibt sich ein Verhalten für schreibende Transaktionen analog zum Isolationsgrad READ COMMITTED im SQL-Standard. Das Lost Update Problem kann also entstehen. 5 commit: ok, weil TNC 2 = max TNC im Pool Datensatz X, TNC = 3 6 Datensatz X, TNC = 2 Datensatz X, TNC = 1

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
Zeitstempel + Daten in die Applikation lesen. Beim Zurückschreiben werden Zeitstempel verglichen: Bei Veränderung Abbruch der Transaktion. Vorteile des Zeitstempel-Verfahrens Keine Deadlocks möglich. Keine Wartesituation für Schreibende Prozesse: Entweder kann sofort geschrieben werden, oder aufgrund eines misslungen Zeitstempelvergleiches muss ein Rollback durchgeführt werden. Leseprozesse werden durch Schreibprozesse nicht behindert. Derselbe Effekt wäre mit Null-Locks oder kurzen S-Locks beim Lesen erreicht. Beim Zeitstempel-Verfahren jedoch keine Lost Updates auftreten. Das Zeitstempelverfahren wird zum Concurrency-Control ausserhalb von Transaktionsgrenzen verwendet werden. Daten können ausgelesen, Offline bearbeitet, später wieder ind die Datenbank, unter Prüfung des Zeitstempels, zurückgeschrieben werden. Anstelle eines Zeitstempels wird meist einfach ein fortlaufender Zähler verwendet. Die Methode wird deshalb fälschlicherweise auch als Versionenverfahren bezeichnet. Nachteile des Zeitstempel-Verfahrens Das Zeitstempelverfahren entspricht einem Isolationsgrad READ COMMITTED. Es kann daher grundsätzlich zu Serialisierbarkeitsproblemen kommen, z.B. in einem Reservationssystem, wo jeder Reservationseintrag einem neuen Datensatz entspricht. In einem solchen System können zwei gegenseitig unverträgliche Datensätze eingefügt werden, ohne dass dies auf der Datenbank bemerkt wird. Unterstützung durch kommerzielle DBMS eher schwach. Meist in Zusammenhang mit O/R Mapping oder Objektdatenbanken verfügbar. Sehr oft muss in der Klassendefinition ein Zeitstempelattribut definiert werden, das dann vom jeweiligen Framework oder der OO-Datenbank verwaltet wird. Beispiel in EJB 3.0: @Entity public class Dokument { @Version protected long version; protected Date datum; protected String inhalt; // …

Zeitstempel in SQL create table T ( ts integer default 1,
id integer primary key, data ... ) A select ts as ts_old, id, data from T where id = id_gesucht Dieses Beispiel zeigt einen einfachen Ablauf, der mit dem Zeitstempelverfahren arbeitet. In A wird ein Datensatz inkl. Zeitstempel gelesen. In B werden die Daten während oder ausserhalb einer Transaktion geändert. In C werden die geänderten Daten in die Datenbank zurückgeschrieben. Das Zurückschreiben beinhaltet gleichzeitig die Prüfung, ob der Zeitstempel noch auf dem ursprünglichen Wert liegt. Wenn nein, findet faktisch gar kein Update statt, weil die where-Bedingung niemals wahr ist. In D wird ein Rollback der gesamten Transaktion durchgeführt. Für das vorliegende, einfach Beispiel ist der Rollback nicht zwingend notwendig, da keine Daten in der DB blockiert sind oder geändert wurden. In den meisten praktischen Situation wird jedoch ein Rollback notwendig sein, da mehr als eine Tabelle und mehr als ein Datensatz betroffen sind, von welchen nur einige einen Zeitstempelkonflikt beim Zurückschreiben verursachen, andere nicht. Die Variable rowcount bezeichent die vom der letzten SQL-Befehl betroffene Anzahl Datensätze. Je nach SQL-Dialekt ist die Syntax oder der Name leicht anders. B -- data ändern C update T set ts = ts_old + 1, data = ... where id = id_gesucht and ts = ts_old D if rowcount = 0 then rollback

III OLTP, OLAP, Data Warehouse

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
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 ) Gegegen seien die Tabellen: Kunde ( idKunde, name ) Bestellung( idBestellung, idArtikel, menge, bestellDatum ) Artikel (idArtikel, name, idGruppe ) Gruppe( idGruppe, name )

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 In der Praxis kann dieses einfach Beispiel leicht komplexere Formen annehmen, z.B. wenn zusätzlich nach Häufigkeit gefiltert und sortiert werden soll, Datumsbedingungen dazukommen, sowie Produkt-Gruppen berücksichtigt werden müssen. OLAP-Transaktionen sind in der Regel Lese-Transaktionen. Sie umfassen meist ein grösseren Anteil des Datenbestandes, und sie nehmen meist eine Aggregation (Zusammenfassung mit count(), sum(), avg(), min(), max() usw) vor. OLAP-Transaktionen sind komplex und erfordern eine grosse Optimierungsfähigkeit durch die DB, damit sie auch bei grösseren Datenbeständen noch schnell genug ablaufen. In der Regel ist die Anzahl OLAP-Transaktionen kleiner als die Anzahl OLTP-Transaktionen in einem System. Bei OLTP-Transaktionen wird in der Regel mit gegebenen Entitäten, resp. Java-Entity-Klassen im Business Tier gearbeitet (Kunde, Bestellung, Artikel, Gruppe). OLAP-Abfragen dagegen sind Report-orientiert zurück.

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 Für OLAP-Anfragen wurden im Rahmen von SQL 2003 und proprietären Produkterweiterungen weitere Operationen (sog. analytische Funktionen) erfunden, welche die statistische Auswertung von Datenbeständen erleichtern. Obiges Beispiel zeigt den over( partition by ) Operator und ein Subselect in der from-Klausel. Die Operatoren sind insbesondere auch auf die Durchführungsoptimierung ausgelegt.

Vergleich OLTP, OLAP, DW Kriterium OLTP OLAP DW Anwenderzahl hoch
mittel/niedrig niedrig Operationstyp lesen, ändern, einfügen, löschen lesen Komplexität der Abfragen klein mittel 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. Aktuelle und historische Daten. Inkrementelle Fütterung aus Aktualdaten. Durch Einzeltransaktion berührtes Datenvolumen klein bis mittel mittel bis gross Datenqualität operativ bereinigt Zu betonen ist, dass OLTP und OLAP auf gemeinsamen, aktiven Datenbanken durchgeführt werden. Data Warehouse-Aktivitäten werden in der Regel auf einer oder mehreren speziell dafür gesschaffenen Datenbanken ausgeführt. Bei der Fütterung des Datawarehouse kommt der Konsolidierung der Daten eine grosse Bedeutung zu: Formate müssen angepasst, einheitliche Bezeichnung (z.B. Artikel) gepflegt werden usw. Ein Data Warehouse hat gegenüber dem operativen System eigene Modellierungsregeln (Faktentabellen und Dimensionstabellen). Während in einem Webshop beispielsweise 'Bestellung' und 'Bestellposition' die zentralen Arbeitstabellen sind, ist im Data Warehouse vielleicht die Tabelle 'Verkauf' der Mittelpunkt. Diese Tabelle könnte die Artikel-ID, Kunden-ID, Laden-ID, Verkaufsmenge und Verkaufsdatum als zentral wichtige Fakten enthalten.

IV Verteilte Datenbanken

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 Im engeren Sinn wird unter einer verteilten Datenbank ein Gesamtsystem verstanden, wo jede Information nur einmal vorkommt. Das Gesamtsystem ist redundanzfrei. In der Praxis entsteht aus einer verteilten Datenbank sehr rasch eine replizierte Datenbank, das heisst ein Gesamtsystem, wo gewisse Information mehrfach auf verschiedenen Knoten existiert.

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
Gesamtsystem Knoten 1 Knoten 3 Knoten 2

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

AppServer/Transaktionsmanager
Zugriffsarchitektur Transparente Architektur Einer der beteiligten Knoten spielt den Master und steuert die beteiligten Datenbanken. Oft für produkthomogene verteilten Datenbanken. Explizite Architektur Eine "Drittpartei", der Transaktions-manager, steuert die beteiligten Datenbanken. Oft für produktheterogene, verteilte Datenbanken, z.B. mit Java EE Applikation Applikation Der Transaktionsmanager wird oft kurz mit TM bezeichnet. Die Knoten heissen häufig auch Resource-Manager RM. Die Bezeichungen "transparent" und "explizit" sind willkürlich gewählt. "transparent" bezieht sich darauf, dass die zugreifende Applikation, resp. der Appserver keinerlei Kenntnisse darüber hat, ob und wie die Daten verteilt sind. Die Daten aus Knoten 2 und 3 treten im Knoten 1 wie lokale Tabellen auf. Bei der expliziten Architektur werden, z.B. in J2EE, die Datenquellen in Form eines Namens explizit angesprochen. Der Transaktionsmanager innerhalb des Appservers erledigt aber, in diesem Sinne dann auch "transparent", die Abwicklung des Transaktionsprotokolls. Knoten 1 AppServer/Transaktionsmanager Knoten 2 Knoten 3 Knoten 1 Knoten 2 Knoten 3

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

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 Die physische Adressierung der beteiligten Server ist sehr produktspezifisch. Die Ortstransparenz wird oft mit einem "Synonym"- oder "Alias"-Konstrukt realisert. Beispiel für SQL-Server: create synonym Bestellung for remote_server.remote_db.dbo.Bestellung; Die verteilte Abfragetransaktion lässt die Frage nach Optimierungstrategien für verteilte Systeme aufkommen. Die verteilte Änderungstransaktion macht ersichtlich, dass die beiden Einfügungen voneinander abhängig sind.  Verteiltes Transaktionsmanagement. SQL Server 2005, Oracle und sichere weitere können dynamisch eine verteilte Transaktion einleiten, sobald Tabellen aus anderen Knoten ins Spiel kommen. Das "distributed" entfällt oder ist optional.

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. Das Anfordern und der Transport einer IO-Page über ein Netzwerk bei einem anderen Datenbanksystem benötigt als grobe Faustregel die doppelte Zeit der Anforderung bei einem lokalen IO-System (Protokollstack-Zeit, IO-Zeit auf dem Remote-Rechner).

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 Grau: Tabellen/Operationen auf dem Remote-Server
Weiss: Tabellen/Operationen auf dem lokalen Server Fett: Netzwerk-Transfers

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

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

V Verteiltes Transaktionsmanagement

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?

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(); Obiges Code-Beispiel zeigt ganz plakativ das Arbeiten mit mehreren Datenquellen und verteilten Transaktionen. Sowohl die Applikation, wie der Transaktionsmanager müssen die Datenquellen kennen. Die Applikation will allerdings nur die Daten verwenden, und der Transaktionsmanager will nur die Transaktionsgrenzen steuern. start() und end() sind Funktionen, welche im Rahmen des XA Industriestandards den Beginn und das Ende einer Transaktion markieren. start() kann vereinfacht mit einem begin transaction gleichgesetzt werden. end() darf aber nicht mit commit gleichgesetzt werden, es markiert dem Transaktionsmanager lediglich, dass die Applikation die Transaktion nicht mehr für Abfragen oder Änderungen benützen will. Die Applikation könnte die Transaktion mit start() wieder aufnehmen. start() und end() sind aus konzeptioneller Sicht nicht notwendig für das Two Phase Commit, wurden jedoch als zusätzliche Funktionalität in den XA-Standard aufgenommen.

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)
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 Der prepare-Eintrag enthält die Transaktions-ID der verteilten Transaktion und Verbindungsinformation zu den beteiligten Datenbanksystemen. Phase 1 Nachdem der prepare-Eintrag in das Logfile geschrieben ist, schickt TM jedem beteiligten Datenbanksystem (RM) eine prepare-Meldung. Gleichzeitig beginnt ein Timeout-Countdown zu laufen. Wenn TM von allen beteiligten RM's eine ready-Meldung bekommen hat, bevor das Timeout abgelaufen ist, schreibt er einen global commit-Eintrag in sein Log-File. Wenn TM von einem der beteiligten RM's eine not-ready Meldung bekommt, oder das Timeout abgelaufen ist bevor alle ready-Meldungen eingetroffen sind, schreibt TM einen global abort-Eintrag in sein Log-File. Mit der Entscheidung des TM ein global commit oder ein global abort durchzuführen, beginnt Phase 2. Phase 2 TM startet einen zweiten Timeout-Countdown und schickt jedem RM im ready-Zustand seine globale Entscheidung (commit oder rollback). Jeder RM führt daraufhin ein lokales Commit oder Rollback durch, schreibt dieses in seinem Log-File fest und sendet eine acknowledge-Meldung an den TM zurück. Hat dieser alle acknowledge-Meldungen erhalten, schreibt er einen complete-Eintrag in sein Log-File und das 2PC ist beendet. Melden sich gewisse RM's nicht in der vorgesehenen Zeit, schickt der TM diesen seine globale Entscheidung immer wieder zu, bis er von allen ein acknowledge zurückbekommen hat.

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 ) Der ready-Eintrag enthält zusätzlich die Transaktions-ID der verteilten Transaktion und die Adresse des TM. Bevor RM dem TM die ready-Meldung geschickt hat, kann RM die lokale Transaktion jederzeit abbrechen, weil ein Fehler aufgetreten ist, beispielsweise eine Verletzung von Constraints, ein Deadlock etc. Er schickt in diesem Fall ein not-ready an den TM. Nachdem RM dem TM die ready-Meldung geschickt hat, ist RM verpflichtet, auf das definitive Commit oder Rollback des TM zu warten. Dieses Warten bezeichnet man als Unsicherheits-Fenster. RM darf in diesem Zeitfenster keine selbstständige Entscheidung treffen.

Transaktions Manager, resp. Masterknoten
Ablauf 2PC, Normalfall get connections Client oder TM selber TM Transaktions Manager, resp. Masterknoten prepare commit global commit ok completed ok Working with RM1 and RM2 … Changes Pending … prepare ready commit prepare ready commit ack ack Ausgangslage: Der Client hat eine Verbindungen zu den beiden Resourcen. Diese bekommt er vorgängig vom Transaction Manager. Der Zustand ‚begin‘ bei den Resource-Managern wird nicht gezeigt. RM 1 Resource Manager 1 RM 2 Resource Manager 2 ready ready committed committed

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

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

Ablauf 2PC, TM-Ausfall in Phase 1
X get connections Client oder TM selber TM Transaktions Manager, resp. Masterknoten prepare commit global abort failure completed failure Changes Pending … Working with RM1 and RM2 … prepare ready prepare ready abort ack prepare not ready Was passiert, wenn der TM ausfällt, nachdem er allen RM's ein prepare geschickt hat, jedoch bevor er den global commit-Eintrag in sein Log-File geschrieben hat? RM Resource Manager 1 RM Resource Manager 2 ready Connection lost! rollback rollback

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

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. Die Fälle 1 und 2 sind identisch zum Recovery einer lokalen Transaktion und können unabhängig vom TM durchgeführt werden. Der TM hat ja dem RM seine Entscheidung offenbar bereits mitgeteilt. Wenn im Logfile gar kein Eintrag zum Transaktionsstatus vorhanden ist, fand der Absturz des RM offensichtlich noch vor der prepare-Meldung an den TM statt. Der RM ist in diesem Fall keine Verpflichtung gegenüber dem TM eingegangen und setzt daher die nicht beendete Transaktion selbstständig zurück. Der Fall 3 bedarf einer Absprache mit dem TM, weil RM nicht weiss, ob sich TM für ein global commit oder ein global abort entschieden hat. Der RM hat verschiedene Möglichkeiten: Der RM meldet sich von sich aus beim TM und schickt im sein Ready Set. Das Ready Set ist die Menge aller verteilten Transaktionen, die einen Entscheid des TM benötigen. Der TM stellt dann dem RM seine Entscheidung zu. Der RM wartet, bis sich der TM bei ihm meldet, um seine Entscheidung mitzuteilen. Der RM stellt sein Ready Set bereit, liefert es aber erst auf Verlangen des TM aus. Der TM teilt dem RM dann seine Entscheidung mit. Diese Variante entspricht dem X-Open Protokoll.

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. In den Fällen 2 und 3 kann es RM's geben, welche vor dem Absturz des TM bereits die abort oder commit Meldung bekommen haben. Diese RM's müssen auf eine erneute commit oder abort Meldung einfach mit einem acknowledge antworten. Der TM kann dann die verteilte Transaktion zu Ende bringen und bei sich ein complete in das Log-File eintragen. Im Fall 1 kann der TM eine Wiederholung des prepare versuchen. Bedingung beim RM ist, dass dieser einen bereits bestehenden ready-Eintrag nochmals mit einer ready-Meldung bestätigt. Für eine verteilte Transaktion im Zustand complete braucht der TM nichts mehr zu unternehmen. Die Transaktion ist ja vollständig abgeschlossen. Administratoren von RM's können manuell auf eigene Verantwortung eine Transaktion in Phase 2 committen oder rollbacken wenn der TM abgestürzt ist. Der Transaktionsstatus wird aufbewahrt zuhanden des TM's, sobald dieser wieder verfügbar ist. Der Transaktionsstatus wird gelöscht, wenn der Administrator oder der Koordinator einen forget-Befehl (X-Open Standard) auslösen.

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 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
start(xid, flags) end(xid, flags) prepare(xid) commit(xid, flags) / rollback(xid) recover(flags) forget(xid) start Begin einer XA-Transaktion in der entsprechenden Resource. Eine eindeutige Xid wird durch den Transaktionsmanager festgelegt. Start() ist mit verschiedenen Flags ausgestattet. TMNOFLAGS heisst, es wird eine neue Transaktion gestartet. TMJOIN heisst, es wird mit einer in der Resource vorhandenen Transaktion verbunden und mit ihr gearbeitet. Eine Verbindung zu einer Resource kann mehrmals verwendet werden, um nacheinander unterschiedliche Transaktionen zu verbinden. Da mehrere Prozesse dieselbe Transaktion über unterschiedliche Verbindungen verbunden haben können, besteht mit dem Flag TMSUSPEND in der end()-Methode und dem Flag TMRESUME in der start()-Methode die Möglichkeit, den Zugriff auf die Transaktion unter den Prozessen zu koordinieren. Innherhalb einer verbundenen Transaktion kann mit TMRESUME eine vorher suspendierte Transaktion wieder aufgenommen werden. end Zurückgeben (nicht committen!) einer Transaktion. Der Prozess ist nicht mehr mit der Transaktion verbunden, diese lebt aber in der Resource weiter und kann allenfalls wieder verbunden werden. End() ist mit verschiedenen Flags ausgestattet. TMSUCCESS zeigt an, dass die Arbeit (aus Sicht des Clientprozesses) erfolgreich war, und die Resource die Transaktion im momentanen Stand aufbewahren soll. Das Aufbewahren bedeutet nicht, dass dazugehörige Sperren freigegeben werden. Diese bleiben bis zum korrekten Ende des Commit-Protokolles bestehen. Das Flag TMFAIL zeigt an, dass die Transaktion aus Sicht des Clientprozesses nicht erfolgreich war und gegenüber der Datenbank zum Rollback freigegeben ist. Genauer gesagt: Eine mit TMFAIL zurückgegebene Transaktion kann nicht wieder verbunden werden mit start() und sie darf vom Datenbanksystem lediglich einem Rollback, nicht einem Commit, unterzogen werden. Eine mit end() zurückgegebene Transaktionen geht verloren, wenn die dazugehörige Resource (Datenbanksystem) einen Crash erleidet. Sie bleibt jedoch erhalten, wenn ein Clientprozess nach dem end() terminiert. Der Clientprozess kann später wieder beginnen und die Transaktion mit start(xid, TMJOIN ) wieder aufnehmen. Mit dem Flag TMSUSPEND kann die Transaktion zuhanden anderer Clientprozesse, die mit dieser Transaktion verbunden sind, freigegeben werden.

Client A Client B Tx1 Tx3 Tx4 prepare
Die Transaktion wird in der Resource sichergestellt. Sie kann nach dem Prepare nicht mehr verlorengehen, auch nicht bei einem Crash der Resource. commit Eine Transaktion wird in der Resource als endgültig markiert, und die zugehörigen Sperren werden freigegeben. Mit einem zweiten boolschen Parameter kann die commit-Methode ein einphasiges Commit durchführen. Die prepare-Methode kann dann übersprungen werden. recover Der angesprochene Resource Manager liefert alle Transaktionen (Xid), die prepared oder heuristic committed sind. Aufgrund dieser Anfrage kann der TM dann ein endgülitiges Commit, ein Rollback oder ein Forget auslösen. rollback Eine zurückgegebene oder prepared Transaktion wird dauerhaft zurückgesetzt. forget Eine durch einen lokalen Systemadministrator bereits mit commit oder rollback beendete Transaktion aus der Liste der hängigen Transaktion streichen. Der Transaktionsmanager streicht damit diese bereits manuell beendeten, lokalen Transaktionen aus seiner Liste. Client A Client B Koordination unter den verbundenen Prozessen mit end(Tx3, TMSUSPEND) start( Tx3, TMRESUME) Verbinden/Lösen start( Tx1, TMJOIN) end( Tx1, TMSUCCESS) Verbinden/Lösen start( Tx4, TMJOIN) end( Tx4, TMSUCCESS) Tx1 Tx3 Tx4

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() Die ResourceManager können in Windows über Settings->Control Panel->Services heruntergefahren und gestartet werden.

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
Client Applikationsserver oder Middleware-Komponente DataSource 1 DataSource 2 getConnection() getConnection() XADataSource 2 XADataSource 1 XAConnection 2 XAConnection 1 XAResource 2 XAResource 1 Transaktions- Manager Implementationen für XADataSource, XAConnection und XAResource werden vom JDBC-Hersteller bereitgestellt. Der "Transaktions-Manager" ist eine Implementation des JTA (Java Transaction API), typischerweise von einem Middleware-Hersteller. Dieser implementiert auch das Interface DataSource für den Client. Das Interface XAResource ist über getXAResource() in XAConnection zugänglich. Während sich der Client in vielen Fällen nur für die Connection interessiert, ist der Transaktions-Manager an sich nur an den Methoden von XAResource interessiert, um die Transaktion durchführen zu können. Interface XAResource { void start(Xid xid, int flags) void end(Xid xid, int flags) int prepare(Xid xid) void commit(Xid xid) void rollback(Xid xid) void forget(Xid xid) Xid[] recover(int flag) } DBMS 1 (Resource Manager) mit Database 1 DBMS 2 (Resource Manager) mit Database 2

Der Transaktionsmanager erzeugt ein Xid und startet auf allen XA Resourcen die verteilte Transaktion mit start(). Danach kann ein Client mit den Daten jeder Resource arbeiten. Der Transaktionsmanager leitet das Two Phase Commit ein, wenn für jede Resource das end() eingetroffen ist. Dies geschieht zum Beispiel über das Zurückgeben der Verbindung vom Client an den Pool-Manager. Der Transaktionsmanager schickt allen XA Resourcen ein Prepare. Falls dabei keine Fehler aufgetreten sind, wird allen XA Resourcen ein Commit geschickt und die verteilte Transaktion ist beendet. Ist beim Prepare irgendeiner XA Resource ein Fehler aufgetreten, verschickt der Transaktionsmanager ein Rollback. Kann einer Resource, welche das Prepare bereits quittiert hat, nicht mehr das abschliessende Rollback oder Commit geschickt werden, muss der Transaktionsmanager periodisch versuchen, eine neue Verbindung zu dieser XA Resource aufzubauen, mit recover() die pendenten Transaktionen zu ermitteln und diese dann ordnungsgemäss abzuschliessen.

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. Das Interface XADataSource ist sehr ähnlich zum Interface DataSource: public Interface javax.sql.XADataSource { XAConnection getXAConnection() XAConnection getXAConnection(String user, String passwd) int getLoginTimeout() void setLoginTimeout(int secs) PrintWriter getLogWriter() void setLogWriter( PrintWriter out ) } Eine XAConnection repräsentiert eine physische Verbindung zur Datenbank: public Interface javax.sql.XAConnection extends PooledConnection { XAResource getXAResource() // getConnection() wird geerbt von PooledConnection Ein Pool-Manager (innerhalb eines Applikationsservers oder einer entsprechenden, selber gebauten Komponente implementiert) fordert über die XADataSource eine physische Datenbank-Verbindungen an (XAConnection). Das XADataSource-Interface ist von einem JDBC-Hersteller implementiert. In die XAConnection trägt sich der Pool-Manager selber als Event Listener ein. Fordert eine Applikation eine Verbindung an, liefert der Pool-Manager eine gewöhnliche Connection via XAConnection.getConnection() aus. Die XAConnection wird zusätzlich in einem globalen Transaktionsobjekt (siehe javax.transaction.Transaction und javax.transaction.TransactionManager) registriert. Über dieses Transaktionsobjekt kann dann zu den geforderten Zeitpunkten (zum Beispiel durch einen Applikationsserver gemäss Transaktions-Angaben für die Methoden eines Session-Beans) die verteilte Transaktion durchgeführt werden.

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! Es gibt grundsätzlich die Möglichkeit, in der Applikation die Transaktionskontrolle explizit zu übernehmen. Der zugehörige Mechanismus heisst Bean Managed Transactions. Die Applikation kann in diesem Fall aus dem Kontext ein Objekt der Klasse javax.transaction.UserTransaction bekommen. Ausschnitt aus der Konfiguration der J2EE Referenzimplementation zur Definition von XA-Resourcen:

VI Messaging und verteilte Transaktionen

Messageing-Systeme mit 2PC
Messages Two Phase Commit Two Phase Commit Message Message Um Daten (Messages) von einer Applikation in eine andere zu transportieren werden oft asynchrone Messageing-Systeme verwendet. In diesem Fall wird eine Meldung von Applikation 1 zum Messageing-System mit einem sicheren Two Phase Commit transportiert. Danach wird sie vom Messageing-System in die Applikation 2, ebenfalls mit Two Phase Commit transportiert. Der logische Transport von Applikation 1 nach Applikation 2 ist damit sicher, aber asynchron. Es gehen keine Meldungen verloren und Meldungen werden nicht mehrfach verschickt. Applikation 1 Applikation 2 DB 1 DB 2

Messageing-Systeme ohne 2PC
Messageing-Applikation Message Nr 12 Message Nr 12 Der Empfänger hat eine Nummer, welche die Nummer der letzten erhaltenen Meldung enthält (LMN). Beim Verschicken einer Meldung wird beim Empfänger die LMN ermittelt. Anschliessend werden beim Sender alle Meldungen mit einer Nummer grösser als LMN gelesen (nicht gelöscht), und zum Empfänger übertragen. Das Schreiben der Meldungen in die Empfängerdatenbank und das Aktualisieren von LMN muss in einer einzigen (lokalen, nicht zweiphasigen) Transaktion geschehen. Alle Meldungen beim Sender, die eine kleinere Nummer als LMN haben, können gelöscht werden. Dies kann zu einem beliebigen Zeitpunkt geschehen. Vorteile: Es wird kein 2PC benötigt, das Messageing-System braucht nicht zwingend eine transaktionelle Datenbank. Sender Empfänger LMN (z.B. 11) DB 1 DB 2

VII Replizierte Datenbanken

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 Gerade die Forderungen nach umfangreichem Lesezugriff verhilft der Replikationstechnologie zu hoher Bedeutung. Ein Kunde will jederzeit seine eigenen Daten abrufen können, sei es m elektronischen Bücherladen, bei der Bank oder der Telecom-Anbieter. Reports- und Statistiken müssen jederzeit, überall und über alle Daten erstellt werden können, gleichzeitig mit dem laufenden Transaktionsbetrieb. Hier prallen auch gegenläufige Anforderungen aufeinander: Die transaktionale Verarbeitung muss sofort und ohne Zeitverzögerung geschehen. Analytische Auswertungen sollen im Gegensatz dazu über einen Datenbestand laufen, der für eine gewisse Zeit konstant bleibt, damit alle Aspekte der Analyse auf denselben Daten beruhen. Replikationstechnologien vermögen hier Lösungen zu bieten.

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? Eine Partition ist eine Teilmenge aus dem gesamten Datenbestand, in der Regel eine Teilmenge der Datensätze einer Tabelle, und/oder eine Teilmenge der Spalten einer Tabelle. Der Publisher trägt die Information, welche Daten repliziert werden. Er definiert die Replikationsart, zum Beispiel 'Snapshot', 'Transactional' oder 'Merge'. Der Publisher ist ausserdem der Ausgangspunkt für die Initialisierung der Replikation. Relativ einfach zu handhaben sind sternförmige Replikationen, wo nur zwischen dem Zentrum (Publisher) und den Aussenstationen (Subscribern) eine Überlappung besteht. Aufwendig bezüglich Netzwerkverkehr und bei Störungen sind Peer-to-Peer Replikation, wo jeder Knoten mit jedem Verbunden ist und jeder alle Daten besitzt. Eine Replikation in nur einer Richtung ist natürlich am einfachsten zu unterhalten und bedeutet, dass nur am Ursprung Daten geändert werden. Eine bidirektionale Replikation kann bedeuten, dass in beiden Knoten Änderungen stattfinden können. Diese können zu Konflikten führen beim Abgleich. Es kann aber auch sein, dass auf jedem Knoten nur neue Daten eingefügt werden. Dann ist der Transfer bidirektional, führt aber zu keinen Konflikten. Verlässliche und kräftige Netzwerke erlauben einen permanenten transaktionalen Abgleich mit kleinen Zeitverzögerungen, z.B. für OLAP-Anwendungen. Push- oder Pullstrategie beeinflusst weniger die Logik der Replikation als viemehr die Prozessauslastung der beteiligten Recher. Abgleiche im Sekundenbereich erfordern transaktionale Replikation (Nachspielen der Transaktionslogs). Abgleiche im Tageszyklus können mit einer 'Merge'-Strategie geführt werden.

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 Bidirektionale Publisher-Subscriber Replikation.
"Geschäftsstellen/Mutterhaus"-Prinzip. Überlappende Partitionen nur zwischen Mutterhaus und Geschäftsstellen, nicht unter den Geschäftsstellen.

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

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

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. Bei allen asynchronen Verfahren gelten folgende Grundsätze: Es werden nur korrekte und bestätigte Daten aus der Quelldatenbank repliziert. Daten, die sich gerade in Änderung befinden, werden nie für die Replikation berücksichtigt. Der Replikationsprozess ändert am Zielort Daten. Diese Änderungen müssen den allgemeinen Transaktionsregeln (ACID-Eigenschaften) unterliegen. Ein unvorhergesehen abgestürzter Replikationsprozess darf keine Inkonsistenzen zurücklassen. Der Replikationsprozess muss darauf Rücksicht nehmen, dass die Daten während der (Erneuerungs-) Replikation durch andere Benützer in Gebrauch sind (mindestens lesend). Der Replikationsprozess führt also eine eigene Transaktion gegen die Zieldatenbank aus, die dem Concurreny Control unterliegt.

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.

Synchronitä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ö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 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): Wird während diesen paarweisen Abgleichen auf keiner Datenbank eine Änderung vorgenommen, so erreichen schliesslich alle Replikate einen identischen Zustand. In einem Umfeld, wo während den Abgleichen aber sofort wieder Änderungen stattfinden, wird durch diesen sequentiell paarweisen Abgleich eventuell gar nie ein global einheitlicher Zustand erreicht (Die Replikation konvergiert nicht). Dies ist eine Eigenschaft jeder asynchronen Replikationstechnologie und muss in Kauf genommen werden.

Demo Merge-Replikation
Die Merge-Replikation ist für folgende Situationen ausgelegt: Replikation und Abgleich von Datenbanken, die zeitweise offline betrieben werden. Änderungen an den replizierten Daten sind sowohl auf dem Publisher wie auf den Subscribern möglich. Daten werden zu einem bestimmten Zeitpunkt repliziert, dann offline bearbeitet und später wieder abgeglichen. Der Abgleich zwischen den Replikation kann zu unterschiedlichsten Zeitpunkten stattfinden. Beim Abgleich zwischen den beteiligten Replikaten sind nur Brutto-Änderungen von Interesse, also nur der Zustand der Daten unmittelbar vor dem Abgleich. Die Merge-Replikation ist vielseitig konfigurierbar: Transfer bidirektional oder unidirektional Der Abgleich der Daten kann auf Ebene Feld, physischer Datensatz oder logischer Datensatz (z.B. Bestellung inkl. Bestellpositionen) erfolgen. Der Ablauf der Merge-Replikation besteht aus einer Initalisierungsphase und einer Betriebsphase. In der Initialisierungsphase wird durch einen Snapshot-Agent ein Snapshot der Publisher-Datenbank erstellt und in den Subscriber-Datenbanken installiert. In der Betriebsphase werden durch einen Merge-Agent periodisch die Änderungen bei den beteiligten Datenbanken eingesammelt, konsolidiert und zurückgespielt. Die Publisher-Datenbank hat einerseits eine Drehscheibenfunktion für die Durchführung des Abgleichs: Änderungen von Subscribern werden zum Publisher propagiert, von dort zu allen anderen Subscribern. Auf dem Publisher können aber andererseits auch direkt Änderungen an den Datentabellen vorgenommen werden. Eigenschaften der Merge-Replikation Die einzelnen Replikate sind untereinander praktisch unabhängig. Es können Abgleich-Konflikte auftreten, die aufgelöst werden müssen. Für diese Konfliktauflösung stehen verschiedenste vorprogrammierte Varianten zur Verfügung (Prioritäten, Zeitstempel, Sum/Min/Max/Avg-Wert usw.) Die Merge Replikation ist für eine hohe Funktionalität, aber für kleine Datenmengen ausgelegt. Die Performance ist kritisch, da umfangreiche Hilfsdaten gesammelt werden und ein N:N – Abgleich unter allen beteiligten Datenbanken stattfindet. Die abzugleichenden Datensätze werden einzeln behandelt, so dass pro Datensatz mindestens ein SQL-Update-, Insert- oder Delete-Befehl für jede abzugleichende Datenbank notwendig ist, neben zahlreichen Kontrollabfragen und –aktionen.

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

Data-Tier Aufgaben und Dienste

Ähnliche Präsentationen

Präsentation zum Thema: "Data-Tier Aufgaben und Dienste"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback

Anmelden

Anmeldung über soziales Netzwerk:

Data-Tier Aufgaben und Dienste

Ähnliche Präsentationen

Präsentation zum Thema: "Data-Tier Aufgaben und Dienste"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback