Inhaltsverzeichnis. Inhaltsverzeichnis

Save this PDF as:
 WORD  PNG  TXT  JPG

Größe: px
Ab Seite anzeigen:

Download "Inhaltsverzeichnis. Inhaltsverzeichnis"

Transkript

1 Inhaltsverzeichnis Das Script für die Lehrveranstaltung Datenmanagement wurde im Wintersemester 2007/2008 komplett überarbeitet und neu strukturiert. Wir bitten darum, eventuelle Fehler im Script an Milan Karow zu melden. Inhaltsverzeichnis 5 Datenbanksnychronisation und Transaktionen Synchronisation von Datenbankprozessen Transaktionen Atomicity (Atomarität) Consistency (Konsistenz) Isolation (Isoliertheit) Durability (Dauerhaftigkeit) Anomalien bei konkurrierenden Zugriffen auf Daten Dirty Read (Schreib-Lese-Konflikt) Lost Update (Verlorene Aktualisierung) Nonrepeatable Read (nicht-wiederholbares Lesen) Phantom Serialisierbarkeit von Transaktionen Lese- und Schreibsperren Zwei-Phasen-Protokoll

2 5 Datenbanksnychronisation und Transaktionen 5.1 Synchronisation von Datenbankprozessen Bei der Datenbanksynchronisation geht es um die Möglichkeit, mit mehreren Nutzern gleichzeitig auf einer Datenbank zu arbeiten. Beim parallelen Zugriff auf Daten kann es zu Konkurrenzsituationen kommen, die im ungünstigsten Fall die Konsistenz der Daten gefährden. 5.2 Transaktionen Operationen auf Datenbanksystemen werden in so genannten Transaktionen durchgeführt. Transaktionen sind Operationen, die eine Datenbank von einem konsistenten Zustand in einen anderen konsistenten Zustand versetzen. Eine Transaktion ist dabei eine vom Benutzer definierte Folge von Aktionen, die bestimmte Eigenschaften erfüllen soll. Die erwünschten Eigenschaften von Transaktionen werden unter dem Akronym ACID zusammengefasst. ACID steht für Atomicity (Atomarität), Consistency (Konsistenz), Isolation (Isoliertheit) und Durability (Dauerhaftigkeit) Atomicity (Atomarität) Die Atomarität von Transaktionen beschreibt deren Eigenschaft der Unteilbarkeit. Eine Transaktion wird nach diesem Prinzip entweder vollständig oder gar nicht auf einem Datenbestand wirksam. Eine Transaktion die erfolgreich vollständig durchgeführt wurde und deren Effekt auf den Datenbestand gesichert werden soll, bestätigt diese Persistierung durch den so genannten. Kann eine Transaktion nicht erfolgreich durchgeführt werden, gilt diese als abgebrochen (abort). Das DBMS muss nun dafür sorgen, dass alle Änderungen im Datenbestand, die durch die Transaktion hervorgerufen wurden, wieder rückgängig gemacht werden. Man spricht dabei von einem roll back Consistency (Konsistenz) Die Eigenschaft der Konsistenz von Transaktionen bezeichnen, dass das Ergebnis einer Transaktion eine Datenbank in einen konsistenten Zustand versetzen muss, vorausgesetzt, die Datenbank befand sich vor der Transaktion in einem solchen Zustand. Konsistent bedeutet in diesem Zusammenhang die fachliche Korrektheit (Integrität) der Daten. Beispielsweise darf in einem doppischen Buchhaltungssystem keine Buchung ohne Gegenbuchung erfolgen. Oder werden in einem System Daten redundant gehalten, so müssen diese bei Änderung konsistent (identisch) gehalten werden Isolation (Isoliertheit) Die Isoliertheit von Transaktionen sorgt dafür, dass eine Transaktion, welche noch nicht vollständig ausgeführt wurde, keinen Einfluss auf die Ergebnisse einer parallel ausgeführten Transaktion haben darf. Die Ergebnisse der Transaktion werden also erst nach dem für andere Transaktionen sichtbar. 77

3 Die einfachste Möglichkeit, Isoliertheit von Transaktionen zu gewährleisten ist deren streng serielle Abarbeitung. Da dies bei größeren Mengen konkurrierender Zugriffe zu nicht akzeptablen Wartezeiten führen würde, ist diese Lösung in vielen Fällen nicht praktikabel. Isoliertheit heißt also, dass die Ergebnismenge von konkurrent (bzw. parallelisiert) ausgeführten Transaktionen identisch mit der Ergebnismenge ist, wären die Transaktionen seriell ausgeführt worden Durability (Dauerhaftigkeit) Die Dauerhaftigkeit von Transaktionen bezeichnet die Eigenschaft des Datenbankmanagementsystems, dass, sobald eine Transaktion durch bestätigt wurde, deren Effekt in der Datenbank wirksam bleibt. Im Gegensatz zu den übrigen Eigenschaften richtet sich die Dauerhaftigkeit weniger an die Sicherung der (fachlichen) Integrität der Daten, als vielmehr die Sicherung der Daten vor Systemausfällen, Hardwarefehlern und anderen externen Risiken. 5.3 Anomalien bei konkurrierenden Zugriffen auf Daten Verstößt eine Transaktion gegen eine oder mehrere der oben genannten Eigenschaften, kann es bei konkurrierenden Zugriffen auf gleiche Datenobjekte zu unterschiedlichen Anomalien kommen Dirty Read (Schreib-Lese-Konflikt) Der Dirty Read bezeichnet grundsätzlich eine Situation, in der eine Transaktion A einen Wert liest, welcher von einer Transaktion B verändert (geschrieben) wurde, Transaktion B jedoch noch nicht via bestätigt wurde. Beispiel 1: Dirty Read A = 100 read a1<-a a1 = 100 a1 = a1-10 a1 = 90 write a1->a A = 90 read a2<-a a2 = 90 a2 = a a2 = 140 write a2->a A = 140 rollback T2 liest einen Wert für A, der von T1 überschrieben wurde. T2 ändert diesen Wert und überschreibt A erneut. T2 bestätigt mit, wogegen T1 abgebrochen wird. Das Ergebnis von T2 ist somit nicht konsistent, da die Transaktion einen Dirty Read für A durchgeführt hat. Die Anomalie kommt zustande, da die Transaktionen die Eigenschaft der Isoliertheit nicht erfüllen. Beispiel 2: Inconsistent Analysis Integritätsbedingung: A + B = 0 Ziel: Umbuchung von 1,- EUR 78

4 read a1<-a a1 = 0 a1 = a1-1 a1 = -1 write a1->a A = -1 read a2<-a a2 = -1 read b2<-b b2 = 0 read b1<-b b1 = 0 b1 = b1 + 1 b1 = 1 write b1->b B = 1 Wird die Transaktion 2 zum angegebenen Zeitpunkt ausgeführt, d.h. während die Transaktion 1 noch läuft, so erhält sie eine inkonsistente Sicht auf die Werte A und B (A wurde bereits geschrieben, B noch nicht). Die inkonsistente Sicht (Inconsistent Analysis) ist ein Spezialfall des Dirty Reads. Die Anomalie kommt zustande, da die Transaktionen ebenfalls die Eigenschaft der Isoliertheit nicht erfüllen Lost Update (Verlorene Aktualisierung) Das Lost Update bezeichnet eine Situation, in der eine Transaktion einen Wert schreibt, eine andere Transaktion denselben Wert wieder überschreibt, ohne dass die Aktualisierung der ersten Transaktion berücksichtigt wird. Im Unterschied zum Dirty Read lesen beide Transaktionen das Datum in einem konsistenten Zustand. Beispiel 3: Lost Update Beide Transaktionen wollen A um 10 erhöhen, A habe einen Wert von 20. read a1<-a a1 = 20 read a2<-a a2 = 20 a1 = a a1 = 30 write a1->a A = 30 a2 = a a2 = 30 write a2->a A = 30 Auswertung: A hat jetzt den Wert 30. Bei einzelnen Betrachtungen der Transaktionen hat es den Anschein, als wären sie korrekt durchgeführt worden. Bei Betrachtung beider Transaktionen ergibt sich ein Fehler (A hätte 40 betragen müssen, die Auswirkung einer Transaktion ging verloren), der nicht genau lokalisiert werden kann und nur schwer für den einzelnen Benutzer zu erkennen ist, da dieser nur seine Transaktion isoliert sieht. Ein Problem des Lost Updates ist, dass es nicht zu einem inkonsistenten Zustand der Datenbank führen muss und daher bei Überprüfung der Konsistenzbedingungen der Datenbank nicht unbedingt entdeckt wird. Er sollte deshalb von vornherein durch geeignete Mechanismen vermieden werden Nonrepeatable Read (nicht-wiederholbares Lesen) Der Nonrepeatable Read bezeichnet eine Situation, in der eine Transaktion ein Datum mehrmals liest, dieses Datum in der Zwischenzeit jedoch durch eine andere Transaktion geändert wurde. 79

5 Der Unterschied zum Dirty Read ist, dass die lesende Transaktion bei jedem Zugriff auf einen konsistenten Zustand der Datenbank zugreift, jedoch im Laufe ihrer Abarbeitung unterschiedliche Zustände vorfindet. Der Unterschied zur inkonsistenten Sicht liegt darin, dass es sich hier bei allen Lesezugriffen um das gleiche Datum handelt. Bei der Inconsistent Analysis werden dagegen unterschiedliche Daten gelesen, welche aber gemeinsam (fälschlicherweise als konsistent) betrachtet werden. Beispiel 4: Nonrepeatable Read L = 200, B = 100, R = 100, E = 50 Konsistenzregel: L R > 0 read l1<-l l1 = 200 read r1<-r r1 = 100 read b1<-b b1 = 0 l1 = l1 - r1 - b1 l1 = 0 read l2<-l l2 = 200 read r2<-r r2 = 100 read e2<-e e2 = 50 l2 = l2 - r2 - e2 l2 = 50 read l2<-l l2 = 200 l2 = l2-50 l2 = 150 write l2->l L = 150 read l1<-l l1 = 150 l1 = l1 - b1 l1 = 50 write l1->l L = 50 Im diesem Beispiel steht L für einen Lagerbestand, R für Reservierungen auf den Bestand, B für eine aktuelle Bestellung und E für eine Entnahme für die Produktion. Transaktion 1 überprüft zunächst, ob der Lagerbestand L abzüglich der Reservierung R groß genug ist, um Bestellung B zu bedienen. Da l1=0, kann die Bestellung durchgeführt werden. Transaktion 1 liest nun den Lagerbestand erneut und zieht die bestellte Menge ab. In Zwischenzeit hat jedoch Transaktion 2 den Lagerbestand um eine Entnahme E verringert, so dass Transaktion 1 nun eine Operation durchführt, die auf Grundlage veralteter Daten entschieden wurde. Das Ergebnis ist ein inkonsistenter Zustand des Systems, da nun die Reservierungen den Lagerbestand überschreiten Phantom Phantome sind ein Problem, welches bei Transaktionen entsteht, die sich auf mehrere Tupel beziehen. Das Problem ähnelt dem Nonrepeatable Read mit dem Unterschied, dass sich das wiederholte Lesen nicht auf ein Datum, sondern auf eine Menge von Daten einer (oder mehrerer) Tabellen bezieht. Beispiel 5: Phantom Transaktion 1 soll den durchschnittlichen Umsatz pro Kunde berechnen. 80

6 read a1<-count(kunde) a1 = 110 insert into Kunde read u1<-sum(umsatz) u1 = 220 du1 = u1 / a1 du1 = 2 write du1->du DU = 2 Der Wert DU, den die Transaktion 1 berechnet, ist zum Zeitpunkt des s der Transaktion bereits nicht mehr gültig. Transaktion 2 hat in der Zwischenzeit einen zusätzlichen Datensatz in die Tabelle Kunde eingetragen, der in der Durchschnittsberechnung nicht berücksichtigt wird. Ein solcher Datensatz wird als Phantom bezeichnet. Der korrekte Wert für DU wäre 1, Serialisierbarkeit von Transaktionen Eine Menge von Ausführungen von Transaktionen führt immer zu einem konsistenten Zustand der Datenbank, wenn alle Transaktionen der Reihe nach (seriell) abgearbeitet werden. Die Reihenfolge der Transaktionen ist dabei egal. Würde das Datenmanagement nur jeweils die Ausführung einer Transaktion gleichzeitig zulassen, so wäre damit die Konsistenz der Datenbank gewährleistet. Diese Einschränkung durch das DBMS führt jedoch zu einer geringen Effizienz des Datenbanksystems, da auch Transaktionen, die überhaupt nicht auf gemeinsame Teile der Datenbank zugreifen, nicht parallel ausgeführt werden dürfen. Das DBMS soll einen möglichst hohen Grad an paralleler Abarbeitung von Transaktionen zulassen, ohne dass Fehler in der Datenbank auftreten. Dies ist immer dann der Fall, wenn die Wirkung der parallel ausgeführten Transaktionen der Wirkung irgendeiner seriellen Ausführung der gleichen Transaktionen entspricht. Das System paralleler Transaktionen heißt dann serialisierbar. Definition: Ein System von parallelen Transaktionen ist dann korrekt synchronisiert, wenn es serialisierbar ist, d.h. wenn mindestens eine (gedachte) serielle Ausführung derselben Transaktionen existiert, die das Datenbanksystem in denselben Zustand überführt, wie die parallele Ausführung. Anders ausgedrückt ist ein System von parallelen Transaktionen genau dann nicht serialisierbar, wenn es die Datenbank in einen Zustand versetzt, der mit keiner der möglichen seriellen Reihenfolgen der beteiligten Transaktionen reproduzierbar wäre (ausgehend vom jeweils gleichen Vorzustand). Zur Gewährleistung der Serialisierbarkeit eines Systems paralleler Transaktionen werden Synchronisationsverfahren angewendet. Man unterscheidet zwei Arten solcher Verfahren: Verifizierende Verfahren: Zu bestimmten Zeitpunkten wird getestet, ob die Serialisierbarkeit noch gegeben ist. Liegt eine Verletzung der Serialisierbarkeit vor, so wird eine geeignete Transaktion zurückgesetzt und neu gestartet. Präventive Verfahren: Es wird verhindert, dass nicht-serialisierbare Folgen von Transaktionsausführungen überhaupt entstehen. In diese Kategorie fallen insbesondere die Sperrverfahren. 81

7 5.4.1 Lese- und Schreibsperren Die Synchronisation eines Systems paralleler Transaktionen kann geschehen, indem jede Transaktion die Objekte in der Datenbank sperrt, die für ihre Abarbeitung benötigt werden. Möchte eine Transaktion ein Objekt nur lesen, so kann sie eine sog. Lesesperre (RLOCK) für das entsprechende Objekt anfordern. Auf einem Objekt dürfen gleichzeitig beliebig viele Lesesperren gesetzt sein. Soll das Objekt auch verändert werden, so ist eine exklusive Sperre (oder auch Schreibsperre, WLOCK) anzufordern. Alternativ kann eine Lesesperre in eine Schreibsperre umgewandelt werden, sofern keine weitere Lesesperre auf diesem Objekt gesetzt ist. Bei der Anforderung von Sperren sind bestimmte Protokolle zu beachten, da durch den Gebrauch von Sperren alleine keine Serialisierbarkeit garantiert wird: Beispiel 6: Inkonsistenzen trotz Sperren read a1<-a a1 = 1 a1 = a1 + 1 a1 = 2 write a1->a A = 2 read b1<-b b1 = 1 b1 = a1 b1 = 2 write b1->b B = 2 read b2<-b b2 = 2 b2 + 2 b2 = 4 write b2->b B = 4 read a2<-a a2 = 2 a2 = b2 a2 = 4 write a2->a A = 4 Haben A und B vor der Ausführung von t1 und t2 beide den Wert 1, so führt sowohl die Hintereinanderausführung t1- t2 als auch die Hintereinanderausführung t2- t1 zu dem Endwert 4 für A und B. Eine parallele Ausführung von t1 und t2 ist somit nur dann korrekt, wenn sie ebenfalls zu dem Wert 4 für die Objekte A und B führt: 82

8 wlock A wlock B read a1<-a a1 = 1 read b2<-b b2 = 1 a1 = a1 + 1 a1 = 2 b2 + 2 b2 = 3 write a1->a A = 2 write b2->b B = 3 unlock A unlock B wlock B wlock A read b1<-b b1 = 3 read a2<-a a2 = 2 b1 = a1 b1 = 2 a2 = b2 a2 = 3 write b1->b B = 2 write a2->a A = 3 unlock B unlock A Die Datenbank hat nach dieser parallelen Ausführung den Wert 3 für A und den Wert 2 für B. Es gibt keinen äquivalenten seriellen Ablauf von t1 und t2, obwohl Sperren verwendet wurden Zwei-Phasen-Protokoll Das Zwei-Phasen-Protokoll ist ein Sperrprotokoll, das Serialisierbarkeit garantiert. Das Protokoll fordert, dass die Anforderung und die Freigabe von Sperren durch eine Transaktion in zwei getrennten Phasen erfolgen. Nachdem eine Transaktion eine Sperre freigegeben hat, darf sie keine weiteren Sperren mehr anfordern. Beispiel 7: Vorheriges Beispiel mit Zwei-Phasen-Protokoll rlock A rlock B read a1<-a a1 = 1 read b2<-b b2 = 1 a1 = a1 + 1 a1 = 2 b2 + 2 b2 = 3 wlock A wlock B write a1->a A = 2 write b2->b B = 3 rlock B: Muss warten, da B gesperrt rlock A: Muss warten, da A gesperrt --- DEADLOCK

9 t1 und t2 befinden sich in einem Deadlock, da beide Transaktionen auf die Freigabe einer Sperre warten, die durch die jeweils andere Transaktion gehalten wird. Die Deadlock-Situation wird durch das DBMS erkannt und aufgehoben, indem eine der beiden Transaktionen (hier beispielhaft t2) zurückgesetzt wird. rollback: zurücksetzen B = 1 der Transaktion, B wird frei und auf den Wert 1 gesetzt. rlock B (Sperre kann jetzt gesetzt werden) read b1<-b b1 = 1 b1 = a1 b1 = 2 wlock B b1 = 2 rlock B: muss warten write b1->b B = 2 unlock B read b2<-b b2 = 2 unlock A b2 + 2 b2 = 4 wlock B write b2->b B = 4 rlock A read a2<-a a2 = 2 a2 = b2 a2 = 4 wlock A write a2->a A = 4 unlock A unlock B A und B haben beide den Wert 4. Der parallele Ablauf von t1 und t2 ist somit serialisierbar. Würde an dieser Stelle die Transaktion t2 mit einem rlock B erneut gestartet werden, dann käme es zu einem späteren Zeitpunkt zu einem erneuten Deadlock. Dieser müsste dann ebenfalls durch rollback aufgelöst werden. Daher wurde in diesem Beispiel der Neustart von t2 verzögert. Es gibt zwei besondere Formen des Zwei-Phasen-Protokolls: Preclaiming und Sperren bis Ende der Transaktion (EOT) Preclaiming: Beim Preclaiming müssen zu Beginn einer Transaktion vor der eigentlichen Verarbeitung alle gewünschten Sperren angefordert werden. Dies hat den Vorteil, dass jede Transaktion, die in die Verarbeitungsphase kommt, Sperren für alle zur Verarbeitung notwendigen Objekte besitzt. Die Transaktion kann somit nicht mehr an einem Deadlock beteiligt sein. Tritt der Deadlock bereits vor der Verarbeitung beim Anfordern der Sperren auf, so ist das Zurücksetzen der Transaktion problemlos möglich, da sie noch keine Objekte in der Datenbank verändert hat. Preclaiming ist nur dann möglich, wenn schon vor Beginn der Verarbeitung alle an der Verarbeitung beteiligten Objekte bekannt sind. Weiterhin schränkt Preclaiming die mögliche Parallelität bei der Abarbeitung von Transaktionen ein, da Sperren länger als notwendig gesetzt sind. 84

10 Sperren bis EOT: Beim Sperren bis EOT (End of Transaction) werden alle Sperren bis zum Ende einer Transaktion gehalten. Dies hat den Vorteil, dass keine andere Transaktion Werte gelesen haben kann, wenn eine Transaktion zurückgesetzt werden muss. Durch Sperren bis EOT wird der mögliche Parallelitätsgrad bei der Ausführung von Transaktionen eingeschränkt, da Sperren länger als notwendig gehalten werden. Ein Deadlock kann durch Sperren bis EOT nicht verhindert werden. 85

Darunter versteht man die Anmeldung eines Benutzers beim System unter Angabe einer Benutzererkennung.

Darunter versteht man die Anmeldung eines Benutzers beim System unter Angabe einer Benutzererkennung. Datenmanagement 60 5 Datenschutz und Datensicherheit 5.1 Datenschutz Wer wird hier geschützt? Personen Ein anderer Begriff für Datenschutz ist Zugriffskontrolle. Datenschutz soll sicherstellen, dass alle

Mehr

Datenintegrität und Transaktionskonzept

Datenintegrität und Transaktionskonzept und Transaktionskonzept 1. / Datenkonsistenz 1 Mögliche Gefährdung der : Missachtung von Konsistenzbedingungen ("Semantische Integrität") Inkorrekte Verweise auf Datensätze in verschiedenen Tabellen ("Referentielle

Mehr

1 Transaktionen in SQL. 2 Was ist eine Transaktion. 3 Eigenschaften einer Transaktion. PostgreSQL

1 Transaktionen in SQL. 2 Was ist eine Transaktion. 3 Eigenschaften einer Transaktion. PostgreSQL 1 Transaktionen in SQL Um Daten in einer SQL-Datenbank konsistent zu halten, gibt es einerseits die Möglichkeit der Normalisierung, andererseits sog. Transaktionen. 2 Was ist eine Transaktion Eine Transaktion

Mehr

Synchronisation in Datenbanksystemen in a nutshell

Synchronisation in Datenbanksystemen in a nutshell Synchronisation in Datenbanksystemen in a nutshell 1. Modell für nebenläufige Transaktionen und Korrektheitskriterium Transaktionsmodell: Folgen von Lese und Schreiboperationen abgeschlossen durch c=commit.

Mehr

Datenbanken: Transaktionskonzept und Concurrency Control

Datenbanken: Transaktionskonzept und Concurrency Control Wesentlich für das Arbeiten mit Datenbanken sind konsistente Datenbestände! Folgerung: es muss sichergestellt werden, dass Datenmanipulationen von Benutzern immer in einem erneut konsistenten Zustand der

Mehr

Kapitel 12 Integrität der Datenbank

Kapitel 12 Integrität der Datenbank Kapitel 12 Integrität der Datenbank 12 Integrität der Datenbank 12 Integrität der Datenbank...1 12.1 Aspekte des Integritätsproblems...3 12.2 Semantische Integrität...4 12.3 Das Konzept der Transaktion...6

Mehr

Software-Engineering und Datenbanken

Software-Engineering und Datenbanken Software-Engineering und Datenbanken Transaktionskonzepte 1 Der Transaktionsbegriff Eine Transaktion ist eine Folge von Operationen, die die Datenbank von einem konsistenten Zustand in einen neuen überführen.

Mehr

Beispielszenarien. 12. Transaktionen. ACID-Eigenschaften. Transaktion

Beispielszenarien. 12. Transaktionen. ACID-Eigenschaften. Transaktion 12. Transaktionen Beispielszenarien Transaktionsbegriff Probleme im Mehrbenutzerbetrieb Serialisierbarkeit Sperrprotokolle zur Synchronisation Isolationsebenen in SQL Platzreservierung für Flüge quasi

Mehr

Übungen zur Vorlesung. Mobile und Verteilte Datenbanken. WS 2008/2009 Blatt 4. Lösung

Übungen zur Vorlesung. Mobile und Verteilte Datenbanken. WS 2008/2009 Blatt 4. Lösung Dr. rer. nat. Sven Groppe Übungen zur Vorlesung Mobile und Verteilte Datenbanken WS 2008/2009 Blatt 4 Lösung Aufgabe 1: Bestimmen Sie zu den folgenden Transaktions-Schedules, ob diese (konflikt-) serialisierbar

Mehr

Kapitel 3 Synchronisation

Kapitel 3 Synchronisation LUDWIG- MAXIMILIANS- UNIVERSITY MUNICH DEPARTMENT INSTITUTE FOR INFORMATICS DATABASE Skript zur Vorlesung: Datenbanksysteme II Sommersemester 2014 Kapitel 3 Synchronisation Vorlesung: PD Dr. Peer Kröger

Mehr

8. Transaktionsverarbeitung. Architektur von Datenbanksystemen I

8. Transaktionsverarbeitung. Architektur von Datenbanksystemen I 8. Transaktionsverarbeitung Architektur von Datenbanksystemen I Einordnung ARCHITEKTUR VON DATENBANKSYSTEMEM I - Key/Value Store - Row Store - Column Store - Data Compression - Transaction Processing -

Mehr

Transaktionen und Synchronisation konkurrierender Zugriffe

Transaktionen und Synchronisation konkurrierender Zugriffe Transaktionen und Synchronisation konkurrierender Zugriffe Fragestellungen Aufgaben des Transaktionsmanagers Aktivieren von Transaktionen entsprechend den Anforderungen von Anwendungsprogrammen. Dabei

Mehr

Datenbanken: Ablaufpläne und Serialisierbarkeit

Datenbanken: Ablaufpläne und Serialisierbarkeit Theoretische Konzepte zur Abarbeitung parallel arbeitender Transaktionen Definition: (Ablaufplan, Schedule) Ein Ablaufplan S ist die verschränkte Anordnung bzw. Ausführung der Einzeloperationen einer Menge

Mehr

6.3 Verteilte Transaktionen

6.3 Verteilte Transaktionen 6.3 Verteilte Transaktionen Situation: Fragmentierung: Ein Datenbestand ist über mehrere Stationen verteilt (z.b. verteilte Datenbank, verteiltes Dateisystem,...) d.h. in Fragmente aufgeteilt, für die

Mehr

Übungen zur Vorlesung. Datenbanken I. WS 2002/2003 Blatt 4 MUSTERLÖSUNG

Übungen zur Vorlesung. Datenbanken I. WS 2002/2003 Blatt 4 MUSTERLÖSUNG Prof. Dr. S. Böttcher Adelhard Türling Übungen zur Vorlesung Datenbanken I WS 2002/2003 Blatt 4 MUSTERLÖSUNG Aufgabe 4.1: Bestimmen Sie zu den folgenden Transaktions-Schedules, ob diese (konflikt-) serialisierbar

Mehr

Konfliktgraph. Satz und Definition

Konfliktgraph. Satz und Definition 9. Transaktionsverwaltung 9.2. Mehrbenutzerkontrolle Seite 1 Konfliktgraph Der Konfliktgraph von S ist ein gerichteter Graph KG(S) = (V, E), wobei V die Menge aller Transaktionen in S und E die Menge der

Mehr

Kommunikation und Datenhaltung

Kommunikation und Datenhaltung Kommunikation und Datenhaltung Transaktionsverwaltung Überblick über den Datenhaltungsteil Motivation und Grundlagen Architektur von Datenbanksystemen Datenbankanfragen Relationenmodell und Relationenalgebra

Mehr

Transaktionskonzept Eine Transaktion ist eine Folge von Operationen mit folgenden ACID Eigenschaften: Atomicity: Es werden alle Operationen oder gar k

Transaktionskonzept Eine Transaktion ist eine Folge von Operationen mit folgenden ACID Eigenschaften: Atomicity: Es werden alle Operationen oder gar k Transaktionsverwaltung 1. Schnellkurs: Serialisierbarkeit, Isolationslevel, Synchronisationsverfahren, Savepoints, Logging, Implementierungsaspekte! Harder, Rahm Buch 2. Erweiterte Transaktionskonzepte!

Mehr

mathematik und informatik

mathematik und informatik Prof. Dr. Gunter Schlageter et. al. Kurs 01672 Datenbanken II LESEPROBE mathematik und informatik Das Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere das Recht der Vervielfältigung

Mehr

In diesem Abschnitt stehen Transaktionen im Mittelpunkt. Hierbei geht es darum, wie bei Mehrbenutzerbetrieb die Integrität von Datenbanken

In diesem Abschnitt stehen Transaktionen im Mittelpunkt. Hierbei geht es darum, wie bei Mehrbenutzerbetrieb die Integrität von Datenbanken In diesem Abschnitt stehen Transaktionen im Mittelpunkt. Hierbei geht es darum, wie bei Mehrbenutzerbetrieb die Integrität von Datenbanken gewährleistet wird. 1 Im einzelnen geht es in diesem Abschnitt

Mehr

1 Referentielle Aktionen

1 Referentielle Aktionen 1 Referentielle Aktionen Betrachten Sie das folgende Datenbankschema: Person(Vorname, Nachname, DOB, Wohnort, Lieblingsfilm Film.IMDb-ID, Videothek Videothek.VID) Film(IMDb-ID, Titel, (ProduzentVN, ProduzentNN)

Mehr

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann Blatt Nr. 2 Übung zur Vorlesung Einsatz und Realisierung von Datenbanksystemen im SoSe15 Moritz Kaufmann (moritz.kaufmann@tum.de)

Mehr

3.6 Transaktionsverwaltung

3.6 Transaktionsverwaltung 3.6 Transaktionsverwaltung Transaktionen erlauben Bündelung von Operationen und gelten als wichtigster Beitrag des Bereichs Datenbanken zur Informatik; sie werden heute auch außerhalb von Datenbanksystemen

Mehr

fbi h_da Datenbanken Kapitel 7: Transaktionsmanagement Schestag Datenbanken (Cnam) Kapitel 7-1

fbi h_da Datenbanken Kapitel 7: Transaktionsmanagement Schestag Datenbanken (Cnam) Kapitel 7-1 Datenbanken Kapitel 7: Transaktionsmanagement Schestag Datenbanken (Cnam) Kapitel 7-1 Transaktionsmanagement Inhalte des Kapitels Das Transaktionskonzept Konkurrierende Zugriffe und Sperren (Concurrency

Mehr

Koordination des Mehrbenutzerbetriebs 9. Koordination des Mehrbenutzerbetriebs

Koordination des Mehrbenutzerbetriebs 9. Koordination des Mehrbenutzerbetriebs 9. Mehrbenutzerbetrieb: DBS bedient gleichzeitig mehrere Benutzer Benutzer arbeiten zwar unabhängig voneinander, können aber die gleiche Relation oder sogar den gleichen Datensatz bearbeiten! Aktivität

Mehr

Datenbanken 1. Sommersemester Übung 8

Datenbanken 1. Sommersemester Übung 8 Datenbanken 1 Sommersemester 2017 Übung 8 (v3.0-9.6.2017) Übersicht Aufgabe 1: Einfache Transaktionen Model (Lock/Unlock) Aufgabe 2: 2-Phasen-Sperrprotokoll (Two phase locking) Aufgabe 3: 2-Phasen-Sperrprotokoll

Mehr

OPTIMISTIC & PESSIMISTIC LOCK Design Patterns PILLER NADIA SARBACH MATTHIAS

OPTIMISTIC & PESSIMISTIC LOCK Design Patterns PILLER NADIA SARBACH MATTHIAS OPTIMISTIC & PESSIMISTIC LOCK Design Patterns PILLER NADIA SARBACH MATTHIAS Agenda 2 Persistenz und ihre Muster (3 ) Optimistic Offline Lock (6 ) (Optimistisches Sperren) Pessimistic Offline Lock (5 )

Mehr

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann Blatt Nr. 13 Übung zur Vorlesung Grundlagen: Datenbanken im WS14/15 Harald Lang (harald.lang@in.tum.de) http://www-db.in.tum.de/teaching/ws1415/grundlagen/

Mehr

Literatur und Quellen. Datenbanken. Inhalt. Inhalt. Transaktionen. Nikolaus Augsten. Wintersemester 2013/14

Literatur und Quellen. Datenbanken. Inhalt. Inhalt. Transaktionen. Nikolaus Augsten. Wintersemester 2013/14 Literatur und Quellen Datenbanken Nikolaus Augsten nikolaus.augsten@sbg.ac.at FB Computerwissenschaften Universität Salzburg Wintersemester 2013/14 Lektüre zu den Themen : Kapitel 9 () aus Kemper und Eickler:

Mehr

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Alfons Kemper, Ph.D.

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Alfons Kemper, Ph.D. TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Alfons Kemper, Ph.D. Blatt Nr. 2 Übung zur Vorlesung Einsatz und Realisierung von Datenbanksystemen im SoSe14 Moritz Kaufmann (moritz.kaufmann@tum.de)

Mehr

5. Transaktionsverarbeitung

5. Transaktionsverarbeitung 5. Transaktionsverarbeitung 5.1. Einführung Viele Anwendungsprogramme / interaktive Benutzer arbeiten gleichzeitig (konkurrierend) auf gemeinsamer Datenbank (mit den gleichen Daten). Notwendigkeit: Abwicklung

Mehr

Kapitel 2 Transaktionsverwaltung

Kapitel 2 Transaktionsverwaltung LUDWIG- MAXIMILIANS- UNIVERSITY MUNICH DEPARTMENT INSTITUTE FOR INFORMATICS DATABASE Skript zur Vorlesung: Datenbanksysteme II Sommersemester 2014 Kapitel 2 Transaktionsverwaltung Vorlesung: PD Dr. Peer

Mehr

Grundlagen von Datenbanken. Referentielle Aktionen, Sichten, Serialisierbarkeit und Locking

Grundlagen von Datenbanken. Referentielle Aktionen, Sichten, Serialisierbarkeit und Locking Grundlagen von Datenbanken Referentielle Aktionen, Sichten, Serialisierbarkeit und Locking SQL DDL: Referentielle Aktionen (1/3) Potentielle Gefährdung der referentiellen Integrität durch Änderungsoperationen

Mehr

Synchronisierung von Transaktionen ohne Sperren. Annahme: Es gibt eine Methode, zu erkennen, wann eine Transaktion die serielle Ordnung verletzt.

Synchronisierung von Transaktionen ohne Sperren. Annahme: Es gibt eine Methode, zu erkennen, wann eine Transaktion die serielle Ordnung verletzt. OPTIMISTIC CONCURRENCY CONTROL Synchronisierung von Transaktionen ohne Sperren. Annahme: Es gibt eine Methode, zu erkennen, wann eine Transaktion die serielle Ordnung verletzt. Abbruch einer Transaktion

Mehr

Übung Datenbanksysteme I Transaktionen, Selektivität und XML. Thorsten Papenbrock

Übung Datenbanksysteme I Transaktionen, Selektivität und XML. Thorsten Papenbrock Übung Datenbanksysteme I Transaktionen, Selektivität und XML Thorsten Papenbrock Übersicht: Übungsthemen 2 Transaktionen Selektivität XML Thorsten Papenbrock Übung Datenbanksysteme I JDBC Transaktionen:

Mehr

Datenbanken Konsistenz und Mehrnutzerbetrieb III

Datenbanken Konsistenz und Mehrnutzerbetrieb III Datenbanken Konsistenz und Mehrnutzerbetrieb III 1. Oracle Architektur! Komponenten des Oracle Servers! Zugriff über Netzwerk 2. Zugriffsrechte! Starten und Schließen der Datenbank! Nutzer und Rollen!

Mehr

View. Arbeiten mit den Sichten:

View. Arbeiten mit den Sichten: View "individuelle Sicht" (vgl. 3-Schichten-Modell) virtuelle Tabellen: in der DB wird nicht deren Inhalt, sondern nur die Ableitungsregel gespeichert. Arbeiten mit den Sichten: Anfragen: kein Problem.

Mehr

Mehrbenutzersynchronisation

Mehrbenutzersynchronisation Kapitel 10 Mehrbenutzersynchronisation 381 / 520 Mehrbenutzersynchronisation Alle TAs strikt seriell (also nacheinander) auszuführen ist sicher, aber langsam Oft werden Systemressourcen nicht voll ausgenutzt,

Mehr

9. Transaktionsverwaltung 9.3. Fehlerbehandlung Seite 1

9. Transaktionsverwaltung 9.3. Fehlerbehandlung Seite 1 9. Transaktionsverwaltung 9.3. Fehlerbehandlung Seite 1 9.3 Fehlerbehandlung Im realen Betrieb eines Datenbanksystems muss mit Fehlersituationen gerechnet werden. Transaktionsfehler: Hierunter verstehen

Mehr

Übungen zur Vorlesung. Datenbanken I

Übungen zur Vorlesung. Datenbanken I Prof. Dr. S. Böttcher Adelhard Türling Übungen zur Vorlesung Datenbanken I WS 2002/2003 Blatt 6 Aufgabe 1: In der Vorlesung haben Sie für die Einbringstrategie Update in Place die Vorgehensweisen steal,

Mehr

Vorlesung Datenbanksysteme Univ.-Prof. Dr. Günther Specht. Universität Innsbruck Institut für Informatik Datenbanken und Informationssysteme (DBIS)

Vorlesung Datenbanksysteme Univ.-Prof. Dr. Günther Specht. Universität Innsbruck Institut für Informatik Datenbanken und Informationssysteme (DBIS) Synchronisation paralleler Transaktionen Kapitel X Vorlesung Datenbanksysteme Univ.-Prof. Dr. Günther Specht Universität Innsbruck Institut für Informatik Datenbanken und Informationssysteme (DBIS) Vorlesungsinhalt

Mehr

Übungen zu Datenbanksysteme

Übungen zu Datenbanksysteme Institut für Informatik Universität Osnabrück, 30.06.2009 Prof. Dr. Oliver Vornberger http://www-lehre.inf.uos.de/ dbs Dipl.-Math. Patrick Fox Abgabe bis 06.07.2009, 12:00 Uhr Aufgabe 10.1 (35 Punkte)

Mehr

Grundlagen von Datenbanken SS Synchronisation paralleler Transaktionen

Grundlagen von Datenbanken SS Synchronisation paralleler Transaktionen Grundlagen von Datenbanken SS 2010 9. Synchronisation paralleler Transaktionen Prof. Dr. Stefan Böttcher Universität Paderborn Agenda: Grundlagen von Datenbanken - SS 2010 - Prof. Dr. Stefan Böttcher Folie

Mehr

Transaktionen Recovery Isolationslevel. Datenbanksysteme. Transaktionen. Burkhardt Renz. Fachbereich MNI Technische Hochschule Mittelhessen

Transaktionen Recovery Isolationslevel. Datenbanksysteme. Transaktionen. Burkhardt Renz. Fachbereich MNI Technische Hochschule Mittelhessen Transaktionen Fachbereich MNI Technische Hochschule Mittelhessen Sommersemester 2015 Motivation ACID-Eigenschaften Übersicht Transaktionen Motivation ACID-Eigenschaften Ursachen für Logging und Backup

Mehr

Datenbanken II Literatur

Datenbanken II Literatur Datenbanken II Literatur C. J. Date: An Introduction to Database Systems; Addison-Wesley Systems Programming Series. 6th ed. 1995 H. E. Erbs, S. Karczewski und I. Schestag: Datenbanken (Datenmodelle, Objekte,

Mehr

Datenbankadministration

Datenbankadministration Datenbankadministration 11. Synchronisation AG DBIS University of Kaiserslautern, Germany Karsten Schmidt kschmidt@informatik.uni-kl.de (Vorlage TU-Dresden) Wintersemester 2008/2009 Transaktion Transaktion

Mehr

Tag 4 Inhaltsverzeichnis

Tag 4 Inhaltsverzeichnis Tag 4 Inhaltsverzeichnis Normalformen Problem Formen (1-4) Weitere Formen Transaktionen Synchronisationsprobleme Überblick Autocommit Locking Savepoints Isolation levels Übungen RDB 4-1 Normalformen Problematik

Mehr

Serialisierbarkeit von Historien: Minimalanforderung bzgl. "akzeptabler" Synchronisation

Serialisierbarkeit von Historien: Minimalanforderung bzgl. akzeptabler Synchronisation Rücksetzbarkeit Serialisierbarkeit von Historien: Minimalanforderung bzgl. "akzeptabler" Synchronisation von Transaktionen zusätzliche Forderung: lokale Rücksetzbarkeit von Historien, d.h. Jede Transaktion

Mehr

Datenbanken und Informationssysteme

Datenbanken und Informationssysteme Datenbanken und Informationssysteme Serialisierbarkeit Burkhardt Renz Fachbereich MNI TH Mittelhessen Wintersemester 2015/16 Übersicht Serialisierbarkeit 2-Phasen-Sperrprotokoll (2PL) Verklemmungen Modell

Mehr

Transaktionsverwaltung

Transaktionsverwaltung Transaktionsverwaltung Commit Eigenschaften von Transaktionen (ACID) Transaktionen in SQL Kapitel 9 1 Transaktionsverwaltung Beispiel einer typischen Transaktion in einer Bankanwendung: 1. Lese den Kontostand

Mehr

Transaktionsverarbeitung und Nebenläufigkeitskontrolle. Jim Gray ( )

Transaktionsverarbeitung und Nebenläufigkeitskontrolle. Jim Gray ( ) Transaktionsverarbeitung und Nebenläufigkeitskontrolle Jim Gray (1944-2007) Transaktionsverwaltung Beispiel einer typischen Transaktion in einer Bankanwendung: 1. Lese den Kontostand von A in die Variable

Mehr

Konflikte. Konflikt-Äquivalenz von Read/Write-Plänen, Konflikt-Serialisierbarkeit

Konflikte. Konflikt-Äquivalenz von Read/Write-Plänen, Konflikt-Serialisierbarkeit Konflikte Zwei Transaktionen liegen im Konflikt, wenn sie ein Objekt o gemeinsam nutzen, wobei mindestens eine der Transaktionen in o schreibt. Für eine Menge von Transaktionen T kann man nun alle Konflikte

Mehr

Replikation und Synchronisation. in mobilen Datenbanksystemen

Replikation und Synchronisation. in mobilen Datenbanksystemen in mobilen Datenbanksystemen 6. Juni 2002 Von Thomas Hoffmann und Sebastian Seidler E-Mail: {hothomas,bastl14w}@minet.uni-jena.de 1 Inhalt Einleitung Was ist Replikation? Was ist Synchronisation? Replikationsverfahren

Mehr

Datenbanksysteme Technische Grundlagen Transaktions-Konzept, Mehrbenutzer-Synchronisation, Fehlerbehandlung

Datenbanksysteme Technische Grundlagen Transaktions-Konzept, Mehrbenutzer-Synchronisation, Fehlerbehandlung Datenbanksysteme Technische Grundlagen Transaktions-Konzept, Mehrbenutzer-Synchronisation, Fehlerbehandlung Prof. Dr. Manfred Gruber FH München Transaktions-Konzept (1) Beispiel: op 1 BOT op 2 read(k 1

Mehr

Scheduler. vereinfachende Annahmen: alle Transaktionen werden wirksam nur Konflikt-Serialisierbarkeit keine Versionen

Scheduler. vereinfachende Annahmen: alle Transaktionen werden wirksam nur Konflikt-Serialisierbarkeit keine Versionen Scheduler Der Scheduler des Informationssystems hat zunächst die Aufgabe, die Anweisungen von parallel auszuführenden Transaktionen in einer geeigneten Reihenfolge anzuordnen. Darüber hinaus muß er auch

Mehr

Datenbanksysteme I Transaktionsmanagement. 20.6.2011 Felix Naumann

Datenbanksysteme I Transaktionsmanagement. 20.6.2011 Felix Naumann Datenbanksysteme I Transaktionsmanagement 20.6.2011 Felix Naumann Motivation - Transaktionsmanagement 2 Annahmen bisher Isolation Nur ein Nutzer greift auf die Datenbank zu Lesend Schreibend In Wahrheit:

Mehr

Verteilte Systeme. Replikation & Konsistenz I. Prof. Dr. Oliver Haase

Verteilte Systeme. Replikation & Konsistenz I. Prof. Dr. Oliver Haase Verteilte Systeme Replikation & Konsistenz I Prof. Dr. Oliver Haase 1 Überblick Replikation & Konsistenz I Ziele von Replikation Replikationsmodelle datenzentriert Client-zentriert Replikation & Konsistenz

Mehr

9 Transaktionskonzept

9 Transaktionskonzept 9 Transaktionskonzept Transaktionskonzept 9.1 Das Transaktionskonzept 9.2 Concurrency & Locking 9.3 Recovery 9.4 JDBC Teil II 9.4.1 Transaktionsmanagement 9.4.2 Objektrelationale Konzepte Schestag Datenbanken

Mehr

Mehrbenutzersynchronisation

Mehrbenutzersynchronisation Mehrbenutzersynchronisation Ausführung der drei Transaktionen T 1, T 2 und T 3 : (a) im Einzelbetrieb und Zeitachse T 1 T2 T 3 (b) im (verzahnten) Mehrbenutzerbetrieb (gestrichelte Linien repräsentieren

Mehr

Transaktionsverwaltung

Transaktionsverwaltung Transaktionsverwaltung VU Datenbanksysteme vom 21.10. 2015 Reinhard Pichler Arbeitsbereich Datenbanken und Artificial Intelligence Institut für Informationssysteme Technische Universität Wien Transaktionsverwaltung

Mehr

Pessimistische Sperrverfahren für Transaktionen. Pessimistische Sperrverfahren für Transaktionen - Implementierung - von Oliver Lemm

Pessimistische Sperrverfahren für Transaktionen. Pessimistische Sperrverfahren für Transaktionen - Implementierung - von Oliver Lemm Pessimistische Sperrverfahren für Transaktionen - Implementierung - von Oliver Lemm Oliver Lemm Seite 1/24 I. Übersicht der Theorie I. Zusammenfassung der Theorie 2 Phasen Sperre in der Theorie & Deadlocks

Mehr

Tag 4 Inhaltsverzeichnis

Tag 4 Inhaltsverzeichnis Tag 4 Inhaltsverzeichnis Normalformen Problem Formen (1-4) Weitere Formen Transaktionen Synchronisationsprobleme Überblick Autocommit Locking Savepoints Isolation levels Übungen RDB 4-1 Normalformen Problematik

Mehr

Mehrbenutzer-Synchronisation

Mehrbenutzer-Synchronisation MehrbenutzerSynchronisation KonfliktKategorien Serialisierung Historien Sperrungen Verklemmungen Optimistische Synchronisation Synchronisation in SQL Mehrbenutzersynchronisation Ausführung der drei Transaktionen,

Mehr

... T n T 1 T 2 T 3. Transaktions-Manager. Daten-Manager. Recovery-Manager Puffer-Manager. Datenbank

... T n T 1 T 2 T 3. Transaktions-Manager. Daten-Manager. Recovery-Manager Puffer-Manager. Datenbank Techniken der Schedule-Realisierung T 1 T 2 T 3.... T n Isolations-Eigenschaft wird durch den Scheduler sichergestellt. Aufgabe: : Koordination des Ablaufs konkurrierender Transaktionen so, dass deren

Mehr

Datenintegrität. Daten. Dateneingabe. Datenverwendung. Datenkonsistenz? logisch. Datenschutz? juristisch. Transaktionen. Datensicherheit?

Datenintegrität. Daten. Dateneingabe. Datenverwendung. Datenkonsistenz? logisch. Datenschutz? juristisch. Transaktionen. Datensicherheit? Datenintegrität Dateneingabe Datenkonsistenz? logisch Daten Datenverwendung Transaktionen Datenschutz? juristisch sc Datensicherheit? physisch 1 Datenintegrität: Begriffsbildung Datenkonsistenz "Widerspruchsfreiheit";

Mehr

Isolationslevel in SQL

Isolationslevel in SQL Isolationslevel in SQL Zu den ACID-Eigenschaften von Transaktionen gehört auch das I, also Isolation. Streng genommen versteht man unter Isolation, dass eine Transaktion unbeeinflusst durch andere Transaktionen

Mehr

10 Transaktionen Änderungen verwalten

10 Transaktionen Änderungen verwalten Eindruck eines Einnutzer- Systems Datenbanken werden meist von vielen Nutzern fast gleichzeitig genutzt. Dieses Kapitel zeigt Ihnen die möglichen Gefahren und Lösungsansätze. In den bisherigen Kapiteln

Mehr

Transaktionen: Wiederholung und Vertiefung

Transaktionen: Wiederholung und Vertiefung Wirtschaftsinformatik II Datenorganisation Datenbanken - Kommunikation Transaktionen: Wiederholung und Vertiefung 7. Datenbankorganisation 7.1. Architektur und Klassifizierung von Datenbanksystemen 7.2

Mehr

10. Übungsblatt. Für die Übung am Donnerstag, 15. Januar 2009, von 15:30 bis 17:00 Uhr in 13/222.

10. Übungsblatt. Für die Übung am Donnerstag, 15. Januar 2009, von 15:30 bis 17:00 Uhr in 13/222. AG Datenbanken und Informationssysteme Wintersemester 2008 / 2009 Prof. Dr.-Ing. Dr. h. c. Theo Härder Fachbereich Informatik Technische Universität Kaiserslautern http://wwwlgis.informatik.uni-kl.de/cms

Mehr

Prüfungsprotokoll Datenbanken Datum: Note: 1,3

Prüfungsprotokoll Datenbanken Datum: Note: 1,3 Thema: Prüfungsprotokoll Datenbanken Datum: 13.01.2014 Prüfer: Prof. Dr. Güting Beisitzer: Valdez Note: 1,3 Kurs 1664 (Implementierungskonzepte für Datenbanken): Aufbau einer Datenbank (große Grafik) und

Mehr

Kapitel 9 Paralleler Zugriff auf DB

Kapitel 9 Paralleler Zugriff auf DB Seite 1 von 8 www.jurijs-skripte.de.vu DBMS - Kapitel 9 Kapitel 9 Paralleler Zugriff auf DB FEHLERFÄLLE BEI UNKONTROLLIERTER ARBEIT Verloren gegangene Änderung - Da beide Anwendungen abwechselnd lesen

Mehr

6. Serialisierbarkeit

6. Serialisierbarkeit 6. Serialisierbarkeit Nothing is as practical as a good theory Albert Einstein Anomalien im Mehrbenutzerbetrieb Synchronisation von Transaktionen - Ablaufpläne, Modellannahmen - Korrektheitskriterium:

Mehr

Teil I Einführung & Grundlagen. 1.1 Was ist eine Transaktion?

Teil I Einführung & Grundlagen. 1.1 Was ist eine Transaktion? Teil I Einführung & Grundlagen Kapitel 1: Einführung in das Transaktionskonzept 1.1 Was ist eine Transaktion? 1.2 Transaktionseigenschaften 1.3 Beispiele Datenbanktransaktionen: Banküberweisung Moderne

Mehr

Dieser Foliensatz darf frei verwendet werden unter der Bedingung, dass diese Titelfolie nicht entfernt wird.

Dieser Foliensatz darf frei verwendet werden unter der Bedingung, dass diese Titelfolie nicht entfernt wird. Thomas Studer Relationale Datenbanken: Von den theoretischen Grundlagen zu Anwendungen mit PostgreSQL Springer, 2016 ISBN 978-3-662-46570-7 Dieser Foliensatz darf frei verwendet werden unter der Bedingung,

Mehr

Gliederung Datenbanksysteme

Gliederung Datenbanksysteme Gliederung Datenbanksysteme 5. Datenbanksprachen 1. Datendefinitionsbefehle 2. Datenmanipulationsbefehle 3. Grundlagen zu SQL 6. Metadatenverwaltung 7. DB-Architekturen 1. 3-Schema-Modell 2. Verteilte

Mehr

Daten- und Transaktionskontrolle mit SQL DCL, TCL

Daten- und Transaktionskontrolle mit SQL DCL, TCL Daten- und Transaktionskontrolle mit SQL DCL, TCL 1 Zugriffsrechte für Datenbankobjekte Zugriff zu einer Relation (inkl. Daten) mit allen Rechten hat zunächst nur der Benutzer, der sie erzeugt hat Situation

Mehr

Mehrbenutzer-Synchronisation

Mehrbenutzer-Synchronisation Mehrbenutzer-Synchronisation Konflikt-Kategorien Serialisierung Historien Sperrungen Verklemmungen Optimistische Synchronisation Synchronisation in SQL Kapitel 11 1 Mehrbenutzersynchronisation Ausführung

Mehr

9.3 Fehlerbehandlung

9.3 Fehlerbehandlung 9.3 Fehlerbehandlung Schutz vor Beeinträchtigungen durch Fehler des Systems oder eines Benutzers nach Systemzusammensturz innerhalb einer TA inkonsistenter Zustand der DB physische und logische Inkonsistenz

Mehr

Kapitel 8: Transaktionen

Kapitel 8: Transaktionen Ludwig Maximilians Universität München Institut für Informatik Lehr- und Forschungseinheit für Datenbanksysteme Skript zur Vorlesung Wintersemester 2006/2007 Vorlesung: Dr. Peer Kröger Übungen: Karsten

Mehr

Kommunikation und Datenhaltung

Kommunikation und Datenhaltung Kommunikation und Datenhaltung 4. Übung zur Datenhaltung Anfrageoptimierung & Transaktionsverwaltung Agenda Institut für Programmstrukturen und Datenorganisation (IPD) Informationen zu Lehrveranstaltungen

Mehr

Transaktionen in Praxis. Dr. Karsten Tolle Vorl

Transaktionen in Praxis. Dr. Karsten Tolle Vorl Transaktionen in Praxis Dr. Karsten Tolle Vorl. 13.06.2017 Probleme bei Transaktionen Lost Update und Inconsistent Retrieval Sichtweise vom Benutzer Auszug aus SQL 92 1) P1 ("Dirty read"): SQL-transaction

Mehr

TAV Übung 3. Übung 3: Verteilte Datenhaltung

TAV Übung 3. Übung 3: Verteilte Datenhaltung Übung 3: Verteilte Datenhaltung 1. Serialisierung Konstruieren Sie Historien aus drei Transaktionen T1, T2 und T3, die folgende Merkmale aufweisen: 1. Die serielle Reihenfolge ist T1 vor T2 vor T3. 2.

Mehr

Datenbanken: Datenintegrität. www.informatikzentrale.de

Datenbanken: Datenintegrität. www.informatikzentrale.de Datenbanken: Datenintegrität Definition "Datenkonsistenz" "in der Datenbankorganisation (...) die Korrektheit der gespeicherten Daten im Sinn einer widerspruchsfreien und vollständigen Abbildung der relevanten

Mehr

Multicore Programming: Transactional Memory

Multicore Programming: Transactional Memory Software (STM) 07 Mai 2009 Software (STM) 1 Das Problem 2 Probleme mit 3 Definitionen Datenspeicherung Konflikterkennung Granularität Optimierungsmöglichkeiten Software (STM) 4 Software (STM) Beispielimplementation

Mehr

Holger Schwarz Universität Stuttgart, IPVS

Holger Schwarz Universität Stuttgart, IPVS DATENBANKANWENDUNG Wintersemester 2013/2014 Holger Schwarz Universität Stuttgart, IPVS holger.schwarz@ipvs.uni-stuttgart.de Beginn: 23.10.2013 Mittwochs: 11.45 15.15 Uhr, Raum 46-268 (Pause 13.00 13.30)

Mehr

Isolationsstufen für Transaktionen. Dr. Karsten Tolle

Isolationsstufen für Transaktionen. Dr. Karsten Tolle Isolationsstufen für Transaktionen Dr. Karsten Tolle Probleme bei Transaktionen Gewährleistung der Isolation Sperren kein Lost Update Read 1 (Accounts[13]) Read 2 (Accounts[13]) Write 2 (Accounts[13],101.000)

Mehr

Mehrbenutzersynchronisation

Mehrbenutzersynchronisation Mehrbenutzer Synchronisation KonfliktKategorien Serialisierung Historien Sperrungen Verklemmungen Optimistische Synchronisation Synchronisation in SQL Mehrbenutzersynchronisation Ausführung der drei Transaktionen,

Mehr

Datenbanksysteme II SS 2010. Übungsblatt 9: Wiederholung

Datenbanksysteme II SS 2010. Übungsblatt 9: Wiederholung Ludwig-Maximilians-Universität München München, 02.07.2010 Department Institut für Informatik PD Dr. Peer Kröger Andreas Züfle Datenbanksysteme II SS 2010 Übungsblatt 9: Wiederholung Besprechung: 20.07.2010

Mehr

Prüfungsprotokoll Datenbanken Datum: Note: 1,3

Prüfungsprotokoll Datenbanken Datum: Note: 1,3 Thema: Prüfungsprotokoll Datenbanken Datum: 13.01.2014 Prüfer: Prof. Dr. Güting Beisitzer: Valdez Note: 1,3 Kurs 1664 (Implementierungskonzepte für Datenbanken): Aufbau einer Datenbank (große Grafik) und

Mehr

Die Grundbegriffe Die Daten Die Informationen

Die Grundbegriffe Die Daten Die Informationen Die Grundbegriffe Die Daten sind diejenigen Elemente, die vom Computer verarbeitet werden. Die Informationen sind Wissenselemente, welche durch die Analyse von Daten erhalten werden können. Die Daten haben

Mehr

P.A. Bernstein, V. Hadzilacos, N. Goodman

P.A. Bernstein, V. Hadzilacos, N. Goodman TRANSAKTIONEN UND DATENINTEGRITÄT Concurrency Control and Recovery in Database Systems P.A. Bernstein, V. Hadzilacos, N. Goodman Addison Wesley, 1987. Kapitel 1. und 6. Grundlagen der Datenbanksysteme

Mehr

Kapitel 2: Synchronisation

Kapitel 2: Synchronisation Ludwig Maximilians Universität München Institut für Informatik Lehr und Forschungseinheit für Datenbanksysteme Skript zur Vorlesung Sommersemester 2005 Vorlesung: Christian Böhm Übungen: Elke Achtert,

Mehr

2. Synchronisation in DBS: Grundlagen, Sperrverfahren

2. Synchronisation in DBS: Grundlagen, Sperrverfahren 2. Synchronisation in DBS: Grundlagen, Sperrverfahren Anomalien im Mehrbenutzerbetrieb Serialisierbarkeit Zweiphasen-Sperrprotokolle Konsistenzstufen von Transaktionen Hierarchische Sperrverfahren Deadlock-Behandlung

Mehr

Transaktionen. Michael Löwe 04/15/16. FHDW Hannover, Freundallee 15, Hannover address:

Transaktionen. Michael Löwe 04/15/16. FHDW Hannover, Freundallee 15, Hannover  address: Transaktionen Michael Löwe 04/15/16 FHDW Hannover, Freundallee 15, 30173 Hannover E-mail address: michael.loewe@fhdw.de KAPITEL 1 Isolation 1.1. Formales Modell für Transaktionen und Ablaufpläne Zustand.

Mehr

Kapitel 7: Referentielle Integrität

Kapitel 7: Referentielle Integrität Kapitel 7: Referentielle Integrität Im Allgemeinen sind nur solche Instanzen einer Datenbank erlaubt, deren Relationen die der Datenbank bekannten Integritätsbedingungen (IB) erfüllen. Integritätsbedingungen

Mehr

Datenbank- Implementierungstechniken

Datenbank- Implementierungstechniken Vorlesung Datenbank- Implementierungstechniken Universität Magdeburg, WS 02/03 Kai-Uwe Sattler kus@iti.cs.uni-magdeburg.de VL Datenbank-Implementierungstechniken 0 1 Überblick 1. Aufgaben und Prinzipien

Mehr

Mehrbenutzersynchronisation

Mehrbenutzersynchronisation Mehrbenutzersynchronisation VU Datenbanksysteme vom 4.11. 2015 Reinhard Pichler Arbeitsbereich Datenbanken und Artificial Intelligence Institut für Informationssysteme Technische Universität Wien Nebenläufigkeit

Mehr

Recovery- und Buffermanager

Recovery- und Buffermanager Recovery- und Buffermanager Gesamtübersicht der Komponenten beim Zusammenspiel des lokalen Recovery Manager und des Datenbank Buffer Manager: persistenter Log Main memory Lokaler Recovery Manager (LRM)

Mehr

Unzulänglichkeiten der ANSI-SQL-Isolationslevel [1] Intelligente Datenbanken

Unzulänglichkeiten der ANSI-SQL-Isolationslevel [1] Intelligente Datenbanken Unzulänglichkeiten der ANSI-SQL-Isolationslevel [1] Ausarbeitung zum Seminar Intelligente Datenbanken im Sommersemester 2005 Fabian Klingbeil Universität Bonn Institut für Informatik III am 19.7.2005 Seminar

Mehr

PostgreSQL im praktischen Einsatz. Stefan Schumacher

PostgreSQL im praktischen Einsatz. Stefan Schumacher PostgreSQL im praktischen Einsatz 2. Brandenburger Linux Infotag 2005 Stefan Schumacher , PGP Key http:/// $Header: /home/daten/cvs/postgresql/folien.tex,v 1.11 2005/04/25

Mehr