Mehrbenutzersynchronisation
|
|
- Jakob Kramer
- vor 7 Jahren
- Abrufe
Transkript
1 Mehrbenutzer Synchronisation KonfliktKategorien Serialisierung Historien Sperrungen Verklemmungen Optimistische Synchronisation Synchronisation in SQL Mehrbenutzersynchronisation Ausführung der drei Transaktionen, und : (a) im Einzelbetrieb und Zeitachse (b) im (verzahnten) Mehrbenutzerbetrieb (gestrichelte Linien repräsentieren Wartezeiten) Kapitel Fehler bei unkontrolliertem Mehrbenutzerbetrieb I Verlorengegangene Änderungen (lost update) Fehler bei unkontrolliertem Mehrbenutzerbetrieb II Abhängigkeit von nicht freigegebenen Änderungen read(a,a 1 ) read(a,a 1 ) a 1 := a a 1 := a read(a,a 2 ) write(a,a 1 ) a 2 := a 2 * 03 read(a,a 2 ) write(a,a 2 ) a 2 := a 2 * 03 write(a,a 1 ) write(a,a 2 ) read(b,b 1 ) read(b,b 1 ) b 1 := b write(b,b 1 ) abort 3 4
2 Fehler bei unkontrolliertem Mehrbenutzerbetrieb III Phantomproblem Serialisierbarkeit Historie ist äquivalent zu einer seriellen Historie dennoch parallele (verzahnte) Ausführung möglich Serialisierbare Historie von und insert into Konten values (C,1000,) select sum(kontostand) from Konten select sum(kontostand) from Konten read(c) write(c) 6 Serielle Ausführung von vor, also Nicht serialisierbare Historie 1 1 read(c) write(c)
3 Zwei verzahnte ÜberweisungsTransaktionen Eine Überweisung ( ) und eine Zinsgutschrift ( ) read(a,a 1 ) a 1 := a 1 50 write(a,a 1 ) read(b,b 1 ) b 1 := b write(b,b 1 ) read(a,a 2 ) a 2 := a write(a,a 2 ) read(b,b 2 ) b 2 := b write(b,b 2 ) Ist nicht serialisierbar, obwohl dies im konkreten Fall nicht zum Konflikt führt. Letzteres kann die DB aber nicht beurteilen read(a,a 1 ) a 1 := a 1 50 write(a,a 1 ) read(b,b 1 ) b 1 := b write(b,b 1 ) read(a,a 2 ) a 2 := a 2 * 03 write(a,a 2 ) read(b,b 2 ) b 2 := b 2 * 03 write(b,b 2 ) Dieselbe r/wkonstellation, diesmal zum Konflikt führend. Die DB greift zur Kontrolle nur auf die r/w Struktur zu, nicht auf die Semantik der Anwendung! 10 Motivation: Zusammenhang ACID Scheduler Theorie der Serialisierbarkeit Formale Definition einer Transaktion Um die Isolation (I in ACID) einer Transaktion zu gewährleisten, darf die Datenbank nur serialisierbare Historien zulassen. Operationen einer Transaktion T i r i (A) zum Lesen des Datenobjekts A, Der Scheduler stellt dies sicher, nicht indem er (im Nachhinein) schaut, ob die Historie serialisierbar war, sondern indem er nichtserialisierbare Historien gar nicht erst zulässt. w i (A) zum Schreiben des Datenobjekts A, a i zur Durchführung eines aborts, c i zur Durchführung des
4 Theorie der Serialisierbarkeit Konsistenzanforderung einer Transaktion T i entweder abort oder aber nicht beides! Falls T i ein abort durchführt, müssen alle anderen Operationen p i (A) vor a i ausgeführt werden, also p i (A) < i a i. Analoges gilt für das, d.h. p i (A) < i c i falls T i ted. Wenn T i ein Datum A liest und auch schreibt, muss die Reihenfolge festgelegt werden, also entweder r i (A) < i w i (A) oder w i (A) < i r i (A). Theorie der Serialisierbarkeit II Historie r i (A) und r j (A): In diesem Fall ist die Reihenfolge der Ausführungen irrelevant, da beide TAs in jedem Fall denselben Zustand lesen. Diese beiden Operationen stehen also nicht in Konflikt zueinander, so dass in der Historie ihre Reihenfolge zueinander irrelevant ist. r i (A) und w j (A): Hierbei handelt es sich um einen Konflikt, da T i entweder den alten oder den neuen Wert von A liest. Es muss also entweder r i (A) vor w j (A) oder w j (A) vor r i (A) spezifiziert werden. w i (A) und r j (A): analog w i (A) und w j (A): Auch in diesem Fall ist die Reihenfolge der Ausführung entscheidend für den Zustand der Datenbasis; also handelt es sich um Konfliktoperationen, für die die Reihenfolge festzulegen ist Formale Definition einer Historie Eine Historie ist eine partiell geordnete Menge (H, < H ) mit BeispielHistorie mit vollständig geordneter Zeit H = U i=1n T i < H ist verträglich mit allen < i Ordnungen, d.h.: r 2 (A) w 2 (B) w 2 (C) c 2 i: x< Hi y x < H y Die Ordnung muss nicht total sein, z.b. bei Mehrprozessorbetrieb. H = r 3 (B) w 3 (A) w 3 (B) w 3 (C) c 3 Für zwei Konfliktoperationen p,q H gilt entweder r 1 (A) w 1 (A) c 1 p < H q oder q < H p. 15 t 16
5 Historie für drei Transaktionen BeispielHistorie für 3 TAs Äquivalenz zweier Historien H H wenn sie die Konfliktoperationen der nicht abgebrochenen Transaktionen in derselben Reihenfolge ausführen. r 2 (A) w 2 (B) w 2 (C) c 2 H = r 3 (B) w 3 (A) w 3 (B) w 3 (C) c 3 read(c) write(c) r 1 (A) w 1 (A) c 1 read(c) write(c) (s. Folie 6) (s. Folie 7) Serialisierbare Historie read(c) Eine Historie ist serialisierbar, wenn sie äquivalent zu einer seriellen Historie Hs ist. write(c) Historie read(c) write(c) r 1 (A) w 1 (A) w 1 (B) c (s. Folie 6) (s. Folie 7) H = r 2 (A) w 2 (B) c 2 r 1 (A) r 2 (C) w 1 (A) w 2 (C) r 1 (B) w 1 (B) c 1 r 2 (A) w 2 (A) c 2 r 1 (A) w 1 (A) r 2 (C) w 2 (C) r 1 (B) w 1 (B) c 1 r 2 (A) w 2 (A) c 2 r 1 (A) w 1 (A) r 1 (B) r 2 (C) w 2 (C) w 1 (B) c 1 r 2 (A) w 2 (A) c 2 r 3 (A) w 3 (A) c 3 r 1 (A) w 1 (A) r 1 (B) w 1 (B) c 1 r 2 (C) w 2 (C) r 2 (A) w 2 (A) c
6 Serialisierbarkeitsgraph und zugehöriger Serialisierbarkeitsgraph SG(H )= Serialisierbarkeitstheorem Satz: Eine Historie H ist genau dann serialisierbar, wenn der zugehörige Serialisierbarkeitsgraph SG(H) azyklisch ist. Historie H = w 1 (A) w 1 (B) c 1 r 2 (A) r 3 (B) w 2 (A) c 2 w 3 (B) c 3 w 1 (A) r 3 (A) der Historie H führt zur Kante des SG weitere Kanten analog Verdichtung der Historie 21 Serialisierbarkeitsgraph Topologische Ordnung(en) H 1 s SG(H )= H s 2 H H s 1 H s 2 22 Eigenschaften von Historien bezüglich der Recovery Terminologie Wir sagen, dass in der Historie H T i von T j liest, wenn folgendes gilt: Eigenschaften von Historien bezüglich der Recovery Rücksetzbare Historien T j schreibt mindestens ein Datum A, das T i nachfolgend liest, also: w j (A) < H r i (A) T j wird (zumindest) nicht vor dem Lesevorgang von T i zurückgesetzt, also: a j < H r i (A) Alle anderen zwischenzeitlichen Schreibvorgänge auf A durch andere Transaktionen T k werden vor dem Lesen durch T i zurückgesetzt. Falls also ein w k (A) mit w j (A) < w k (A) < r i (A) Eine Historie heißt rücksetzbar, falls immer die schreibende Transaktion (in unserer Notation T ) j vor der lesenden Transaktion (T i genannt) ihr durchführt, also: c j < H c i. Anders ausgedrückt: Eine Transaktion darf erst dann ihr durchführen, wenn alle Transaktionen, von denen sie gelesen hat, beendet sind. existiert, so muss es auch ein a k < r i (A) geben
7 Eigenschaften von Historien bezüglich der Recovery BeispielHistorie mit kaskadierendem Rücksetzen: 0. w 1 (A) a 1 (abort) r 2 (A) w 2 (B) r 3 (B) w 3 (C) T 4 r 4 (C) w 4 (D) Historien ohne kaskadierendes Rücksetzen T 5 r 5 (D) Eine Historie vermeidet kaskadierendes Rücksetzen, wenn für je zwei TAs T i und T j gilt: c j < H r i (A) gilt, wann immer T i ein Datum A von T j liest. 25 Strikte Historien Eine Historie ist strikt, wenn für je zwei TAs T i und T j gilt: Wenn w j (A) < H o i (A) (mit o i = w i oder o i = r i ), dann muss entweder a j < H o i (A) oder c j < H o i (A) gelten. 26 Beziehungen zwischen den Klassen von Historien Der DatenbankScheduler alle Historien SR T n RC ACA ST serielle Historien TransaktionsManager TM Scheduler DatenManager RecoveryManager PufferManager SR: RC: ACA: ST: serialisierbare Historien rücksetzbare Historien Historien ohne kaskadierendes Rücksetzen strikte Historien 27 Datenbank 28
8 Aufgabe des Schedulers Reihung der Operationen verschiedener Transaktionen, so dass die Historie mindestens serialisierbar und meistens auch ohne kaskadierendes Rollback rücksetzbar ist. Die entstehenden Historien sollten also aus dem Bereich ACA SR stammen. Verschiedene Ansätze möglich: sperrbasierte Synchronisation (wird am häufigsten verwandt) Zeitstempelbasierte Synchronisation optimistische Synchronisation (eignet sich bei vorwiegend lesenden Zugriffen) Sperrbasierte Synchronisation Zwei Sperrmodi S (shared, read lock, Lesesperre): X (exclusive, write lock, Schreibsperre): Verträglichkeitsmatrix (auch Kompatibilitätsmatrix genannt) NL S X S X ZweiPhasenSperrprotokoll: Definition Jedes Objekt, das von einer Transaktion benutzt werden soll, muss vorher entsprechend gesperrt werden. Eine Transaktion fordert eine Sperre, die sie schon besitzt, nicht erneut an. Eine Transaktion muss die Sperren anderer Transaktionen auf dem von ihr benötigten Objekt gemäß der Verträglichkeitstabelle beachten. Wenn die Sperre nicht gewährt werden kann, wird die Transaktion in eine entsprechende Warteschlange eingereiht bis die Sperre gewährt werden kann. Jede Transaktion durchläuft zwei Phasen: Eine Wachstumsphase, in der sie Sperren anfordern, aber keine freigeben darf und eine Schrumpfphase, in der sie ihre bisher erworbenen Sperren freigibt, aber keine weiteren anfordern darf. Bei EOT (Transaktionsende) muss eine Transaktion alle ihre Sperren zurückgeben. ZweiPhasen Sperrprotokoll: Grafik #Sperren Wachstum Schrumpfung Zeit 31 32
9 Verzahnung zweier TAs gemäß 2PL modifiziert nacheinander die Datenobjekte A und B (z.b. eine Überweisung) liest nacheinander dieselben Datenobjekte A und B (z.b. zur Aufsummierung der beiden Kontostände). 33 Verzahnung zweier TAs gemäß 2PL Bemerkung lockx(a) locks(a) muss warten lockx(b) unlockx(a) wecken 1 locks(b) muss warten 1 1 unlockx(b) wecken unlocks(a) 1 unlocks(b) 1 34 Strenges ZweiPhasen Sperrprotokoll 2PL schließt kaskadierendes Rücksetzen nicht aus Erweiterung zum strengen 2PL: alle Sperren werden bis EOT gehalten damit ist kaskadierendes Rücksetzen ausgeschlossen #Sperren Wachstumsphase EOT Zeit 35 Verklemmungen (Deadlocks) Ein verklemmter Schedule Bemerkung lockx(a) locks(b) lockx(b) muss warten auf locks(a) muss warten auf Deadlock 36
10 Verklemmungen Erkennen von Verklemmungen können entdeckt und dann aufgelöst oder gleich vermieden werden. Beides ist teuer. Mögliche Techniken: Ad a: TimeOut Zyklenerkennung Ad b: BruteForceMethode: TimeOut Nach gewisser Wartezeit (z.b. 1 sec) wird Transaktion zurückgesetzt Nachteil: Falls Zeit zu kurz, werden zu viele Transaktionen zurückgesetzt, die nur auf Resourcen (CPU etc.) warten. Falls Zeit zu lang, werden zu viele Verklemmungen geduldet. Preclaiming Zeitstempel Erkennen von Verklemmungen Zyklenerkennung durch Tiefensuche im Wartegraph ist aufwendiger, aber präziser Vermeiden von Verklemmungen Preclaiming in Verbindung mit dem strengen 2 PL Protokoll Bsp.: Wartegraph mit zwei Zyklen: #Sperren T 4 T 5 T 5 T 4 Beide Zyklen können durch Rücksetzen von gelöst werden. EOT Zeit 39 40
11 Preclaiming ist in der Praxis häufig nicht einzusetzen: Man weiss i.a. apriori nicht genau, welche Sperren benötigt werden, z.b. bei ifthenelse im Anwendungsprogramm. Daher müssen normalerweise mehr Sperren als nötig auf Verdacht reserviert werden, was zu übermäßiger Resourcenbelegung und Einschränkung der Parallelität führt. Vermeiden von Verklemmungen Verklemmungsvermeidung durch Zeitstempel Jeder Transaktion wird ein eindeutiger Zeitstempel (TS) zugeordnet ältere TAs haben einen kleineren Zeitstempel als jüngere TAs TAs dürfen nicht mehr bedingungslos auf eine Sperre warten. Zwei Varianten: woundwait Strategie will Sperre erwerben, die von gehalten wird. Wenn älter als ist, wird abgebrochen und zurückgesetzt, so dass weiterlaufen kann. Sonst wartet auf die Freigabe der Sperre durch. 41 waitdie Strategie will Sperre erwerben, die von gehalten wird. Wenn älter als ist, wartet auf die Freigabe der Sperre. Sonst wird abgebrochen und zurückgesetzt. 42 MGL: MultiGranularity Locking Hierarchische Anordnung möglicher Sperrgranulate Datenbasis MGL: MultiGranularity Locking Bisher haben wir Sperrungen auf derselben Granularitätsebene betrachtet. Nachteil bei kleiner Granularität: Bei TAs mit Zugriff auf viele Tupel muss viel Sperraufwand betrieben werden. Nachteil bei großer Granularität: unnötige Sperrung von Datensätzen Segmente Lösungsansatz: Sperrung auf verschiedenen Hierarchieebenen erlaubt. Sätze Seiten Bei Anforderung einer Sperre muss man überprüfen, ob weiter oben oder unten bereits Sperren gesetzt sind. zu hoher Suchaufwand! Lösungsansatz: Einführung zusätzlicher Sperrmodi MGL 43 44
12 Erweiterte Sperrmodi NL: keine Sperrung (no lock), S: Sperrung durch Leser, MultiGranularity Locking (MGL) Kompatibilitätsmatrix X: Sperrung durch Schreiber, NL S X IS IX IS (intention share): Weiter unten in der Hierarchie ist eine Lesesperre (S) beabsichtigt, IX (intention exclusive): Weiter unten in der Hierarchie ist eine Schreibsperre (X) beabsichtigt. S X IS IX MultiGranularity Locking (MGL) Sperrprotokoll des MGL Bevor ein Knoten mit S oder IS gesperrt wird, müssen alle Vorgänger in der Hierarchie vom Sperrer (also der Transaktion, die die Sperre anfordert) im IX oder ISModus gehalten werden. Bevor ein Knoten mit X oder IX gesperrt wird, müssen alle Vorgänger vom Sperrer im IXModus gehalten werden. Die Sperren werden von unten nach oben (bottom up) freigegeben, so dass bei keinem Knoten die Sperre freigegeben wird, wenn die betreffende Transaktion noch Nachfolger dieses Knotens gesperrt hat. DatenbasisHierarchie mit Sperren Datenbasis Segmente (areas) Seiten Sätze (,X) s 1 (,IX) a 1 (,IS) a 1 (,X) p 1 s 2 (T2,IS) (,IX) D (,IX) s 3 p 2 (,S) s 4 s 5 p 3 s
13 DatenbasisHierarchie mit Sperren (T4 will s3 ändern, T5 will s5 lesen, was passiert?) (T2,IS) (,IX) Datenbasis D (,IX) Datenbasis DatenbasisHierarchie mit blockierten Transaktionen (,IX) (T 4,IX) D (,IS) (,IX) Segmente (areas) (,IX) a 1 (,IS) a 2 (,X) Segmente (areas) (,IX) (,IS) a 1 (T 4,IX) a 1 (,X) Seiten (,X) p 1 p 2 (,S) p 3 Seiten (,X) p 1 p 2 (,S) (T 4,IX) p 3 Sätze s 1 s 2 s 3 s 4 s 5 s 6 49 Sätze s 1 s 2 s 3 (T 4,X) s 4 s 5 s 6 50 Datenbasis DatenbasisHierarchie mit blockierten Transaktionen (,IX) (T 4,IX) (T 5,IS) D (,IS) (,IX) DatenbasisHierarchie mit blockierten Transaktionen Segmente (areas) (,IX) (,IS) a 1 (T 4,IX) a 1 (,X) (T 5,IS) die TAs T 4 und T 5 sind blockiert (warten auf Freigabe von Sperren) es gibt aber in diesem Beispiel (noch) keine Verklemmung Seiten (,X) p 1 p 2 (,S) (T 4,IX) p 3 (T 5,IS) Verklemmungen sind aber auch bei MGL möglich Sätze s 1 s 2 s 3 s 4 s 5 s 6 (T 4,X) (T 5,S) 51 52
14 Einfüge und Löschoperationen, Phantome Vor dem Löschen eines Objekts muss die Transaktion eine X Sperre für dieses Objekt erwerben. (Man beachte aber, dass eine andere TA, die für dieses Objekt ebenfalls eine Sperre erwerben will, diese nicht mehr erhalten kann, falls die Löschtransaktion erfolgreich (mit ) abschließt.) Beim Einfügen eines neuen Objekts erwirbt die einfügende Transaktion eine XSperre. select count(*) from prüfen where Note between 1 and 2; select count(*) from prüfen where Note between 1 and 2 Phantomprobleme insert into prüfen values(19555, 5001, 2137, 1); Phantomprobleme können immer noch auftreten, hier z.b. wenn die Sperren auf SatzEbene gesetzt werden Phantomprobleme Das Problem lässt sich dadurch lösen, dass man zusätzlich zu den Tupeln auch den Zugriffsweg, auf dem man zu den Objekten gelangt ist, sperrt Wenn also ein Index für das Attribut Note existiert, würde der Indexbereich [1,2] für mit einer SSperre belegt Wenn jetzt also Transaktion versucht, das Tupel [29555, 5001, 2137, 1] in prüfen einzufügen, wird die TA blockiert Zeitstempelbasierende Synchronisation Jedem Datum A in der Datenbasis werden bei diesem Synchronisationsverfahren zwei Marken zugeordnet: readts(a): writets(a): Synchronisationsverfahren T i will A lesen, also r i (A) Falls TS(T i ) < writets(a) gilt, haben wir ein Problem: Die Transaktion T i ist älter als eine andere Transaktion, die A schon geschrieben hat. Also muss T i zurückgesetzt werden. Anderenfalls, wenn also TS(T i ) writets(a) gilt, kann T i ihre Leseoperation durchführen und die Marke readts(a) wird auf max(ts(t i ), readts(a)) gesetzt
15 Zeitstempelbasierende Synchronisation Synchronisationsverfahren T i will A schreiben, also w i (A) Falls TS(T i ) < readts(a) gilt, gab es eine jüngere Lesetransaktion, die den neuen Wert von A, den T i gerade beabsichtigt zu schreiben, hätte lesen müssen. Also muss T i zurückgesetzt werden. Falls TS(T i ) < writets(a) gilt, gab es eine jüngere Schreibtransaktion. D.h. T i beabsichtigt einen Wert einer jüngeren Transaktion zu überschreiben. Das muss natürlich verhindert werden, so dass T i auch in diesem Fall zurückgesetzt werden muss. Lesephase: Optimistische Synchronisation In dieser Phase werden alle Operationen der Transaktion ausgeführt also auch die Änderungsoperationen. Die Transaktion liest (zunächst) nur, und führt alle Schreiboperationen auf lokalen Variablen aus. Validierungsphase: In dieser Phase wird entschieden, ob die Transaktion möglicherweise in Konflikt mit anderen Transaktionen geraten ist. Dies wird anhand von Zeitstempeln entschieden, die den Transaktionen in der Reihenfolge zugewiesen werden, in der sie in die Validierungsphase eintreten. Anderenfalls darf T i das Datum A schreiben und die Marke writets(a) wird auf TS(T i ) gesetzt. Schreibphase: In dieser Fassung sind alle Historien serialisierbar, schließen aber kaskadierendes Rücksetzen nicht aus. Protokoll muss geeignet erweitert werden. 57 Die Änderungen der Transaktionen, bei denen die Validierung positiv verlaufen ist, werden in dieser Phase in die Datenbank eingebracht. 58 Validierung bei der optimistischen Synchronisation Vereinfachende Annahme: Es ist immer nur eine TA in der Validierungsphase! Wir wollen eine Transaktion T j validieren. Die Validierung ist erfolgreich, falls für alle älteren Transaktionen T a also solche, die früher ihre Validierung abgeschlossen haben eine der beiden folgenden Bedingungen gilt: T a war zum Beginn der Transaktion T j schon abgeschlossen einschließlich der Schreibphase. Die Menge der von T a geschriebenen Datenelemente, genannt WriteSet(T a ), enthält keine Elemente der Menge der gelesenen Datenelemente von T, j genannt ReadSet(T j ). Es muss also gelten: WriteSet(T a ) ReadSet(T j ) = Synchronisation von Indexstrukturen Indexe enthalten redundante Informationen, deswegen kann man weniger aufwendige Recoverytechniken einsetzen. Für Indexe ist das ZweiphasenSperrprotokoll zu aufwändig. Bsp.: Das strenge 2PL würde bei Lesezugriff auf B + Baum 1 jeden Knoten des Baumes mit Lesesperre versehen, weite Bereiche sind dann für Einfügeoperationen gesperrt. Lösung: kurze Lesesperre nur auf Wurzel, bis Eintrag gefunden. Dann Freigabe und Zugriff auf Daten. Wenn Datum dort nicht mehr gefunden wird (wegen Einfügeoperation), muss es weiter rechts liegen
16 Synchronisation von Indexstrukturen B + Baum mit rechtsverweisen zur Synchronisation Synchronisation von Indexstrukturen B + Baum mit rechtsverweisen nach Einfügen von D 2 D 3 D D 7 D 9 D D D 2 D 3 D D 7 D 9 D D 14 D Transaktionsverwaltung in SQL92 set transaction [read only, read write,] [isolation level read unted, read ted, repeatable read, serializable,] [diagnostic size,] Transaktionsverwaltung in SQL92 read unted: Dies ist die schwächste Konsistentstufe. Sie darf auch nur für read onlytransaktionen spezifiziert werden. Eine derartige Transaktion hat Zugriff auf noch nicht festgeschriebene Daten. Zum Beispiel ist folgender Schedule möglich: Macht nur Sinn zum Browsen der Datenbank. Hindert andere Transaktionen nicht, da keine Sperren gesetzt werden. rollback 63 64
17 Transaktionsverwaltung in SQL92 read ted: Diese Transaktionen lesen nur festgeschriebene Werte. Allerdings können sie unterschiedliche Zustände der DatenbasisObjekte zu sehen bekommen: Transaktionsverwaltung in SQL92 repeatable read: Das oben aufgeführte Problem des non repeatable read wird durch diese Konsistenzstufe ausgeschlossen. Allerdings kann es hierbei noch zum Phantomproblem kommen. Dies kann z.b. dann passieren, wenn eine parallele Änderungstransaktion dazu führt, dass Tupel ein Selektionsprädikat erfüllen, das sie zuvor nicht erfüllten. serializable: Diese Konsistenzstufe fordert die Serialisierbarkeit. Dies ist der Default (in den meisten DBMS)
Mehrbenutzer-Synchronisation
MehrbenutzerSynchronisation KonfliktKategorien Serialisierung Historien Sperrungen Verklemmungen Optimistische Synchronisation Synchronisation in SQL Mehrbenutzersynchronisation Ausführung der drei Transaktionen,
MehrMehrbenutzer-Synchronisation
Mehrbenutzer-Synchronisation Konflikt-Kategorien Serialisierung Historien Sperrungen Verklemmungen Optimistische Synchronisation Synchronisation in SQL Kapitel 11 1 Mehrbenutzersynchronisation Ausführung
MehrMehrbenutzersynchronisation
Mehrbenutzersynchronisation VU Datenbanksysteme vom 4.11. 2015 Reinhard Pichler Arbeitsbereich Datenbanken und Artificial Intelligence Institut für Informationssysteme Technische Universität Wien Nebenläufigkeit
MehrMehrbenutzersynchronisation
Kapitel 10 Mehrbenutzersynchronisation 381 / 520 Mehrbenutzersynchronisation Alle TAs strikt seriell (also nacheinander) auszuführen ist sicher, aber langsam Oft werden Systemressourcen nicht voll ausgenutzt,
MehrSerialisierbarkeit 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... 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
MehrSynchronisation 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.
MehrKoordination 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
MehrSoftware-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.
MehrDatenintegritä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
MehrTransaktionen und Synchronisation konkurrierender Zugriffe
Transaktionen und Synchronisation konkurrierender Zugriffe Fragestellungen Aufgaben des Transaktionsmanagers Aktivieren von Transaktionen entsprechend den Anforderungen von Anwendungsprogrammen. Dabei
MehrDatenbanken: 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
MehrKapitel 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
MehrDatenbanksysteme 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
Mehr1 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
MehrDarunter 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
MehrVorlesung 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
MehrDatenbankadministration
Datenbankadministration 11. Synchronisation AG DBIS University of Kaiserslautern, Germany Karsten Schmidt kschmidt@informatik.uni-kl.de (Vorlage TU-Dresden) Wintersemester 2008/2009 Transaktion Transaktion
MehrKapitel 15. Transaktionen, Fehlerbehandlung, Multi-User. Prof. Dr. Wolfgang Weber Vorlesung Datenbanken
Kapitel 15 Transaktionen, Fehlerbehandlung, Multi-User 1 Transaktionen, Fehlerbehandlung, Multi-User Transaktionskonzept Fehlerbehandlung Mehrbenutzersynchronisation 2 Transaktionen Warum? Beispiel 1 Was
MehrDatenbanksysteme 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:
MehrScheduler. 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
MehrTag 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
MehrDieser 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,
MehrDer Scheduler. 9. Transaktionsverwaltung. Zustände einer Transaktion. Transaktionsoperationen
9. Transaktionsverwaltung Der Scheduler Architektur der Transaktionsverwaltung Sperrende und nicht-sperrende Verfahren Transaktionen in SQL-Systemen Transaktionsmonitore T 1 T T 2 n Transaktions- Manager
MehrDatenbanken und Informationssysteme
Datenbanken und Informationssysteme Serialisierbarkeit Burkhardt Renz Fachbereich MNI TH Mittelhessen Wintersemester 2015/16 Übersicht Serialisierbarkeit 2-Phasen-Sperrprotokoll (2PL) Verklemmungen Modell
Mehr9 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Ü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:
Mehr8. Synchronisations-Verfahren
8. Synchronisations-Verfahren Die verschiedenen Synchronisationsverfahren unterscheiden sich i.w. dadurch, wie sie die Einhaltung des Serialisierbarkeitsprinzips gewährleisten wann die Prüfung auf Serialisierbarkeit
MehrTransaktionsverwaltung
Transaktionsverwaltung VU Datenbanksysteme vom 21.10. 2015 Reinhard Pichler Arbeitsbereich Datenbanken und Artificial Intelligence Institut für Informationssysteme Technische Universität Wien Transaktionsverwaltung
MehrTag 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
MehrEinführung - Anomalien beim ungeschützten und konkurrierenden Zugriff von Lesern und Schreibern auf gemeinsame Daten
Synchronisation 0 Einführung - Anomalien beim ungeschützten und konkurrierenden Zugriff von Lesern und Schreibern auf gemeinsame Daten - Synchronisation von Transaktionen: Grundbegriffe und Modellannahmen
MehrLiteratur 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:
MehrUnzulä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
MehrIT-Kompaktkurs. Datenbanken Skript zur Folge 4. Prof. Dr. Manfred Gruber Fachhochschule München
Fachhochschule München Munich University of Applied Sciences IT-Kompaktkurs Skript zur Folge 4 Prof. Dr. Manfred Gruber Fachhochschule München manfred.gruber@informatik.fh-muenchen.de Nov 1, 2000 Transaktions-Konzept,
MehrDatenbanken 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!
MehrTransaktionsverwaltung
Transaktionsverwaltung Commit Eigenschaften von Transaktionen (ACID) Transaktionen in SQL Kapitel 9 1 Transaktionsverwaltung Beispiel einer typischen Transaktion in einer Bankanwendung: 1. Lese den Kontostand
MehrUntersuchung der Skalierbarkeit verschiedener Datenbankmanagementsysteme unter hohen Nutzerzahlen
Universität Zürich Institut für Informatik Database Technology Research Group Prof. Dr. Carl-Christian Kanne Untersuchung der Skalierbarkeit verschiedener Datenbankmanagementsysteme unter hohen Nutzerzahlen
Mehr8. März: Klausurvorbereitung (Durchgehen Klausurähnlicher Aufgaben, Fragestunde)
Organisatorisches Termine 2. März: letzte Vorlesung 8. März: Klausurvorbereitung (Durchgehen Klausurähnlicher Aufgaben, Fragestunde) 9. März: Besprechungstermin Übungsblatt 6 (Punkte bisher: siehe Aushang)
MehrKapitel 12: Transaktionen für XML
Kapitel 12: Transaktionen für XML Transaktionelle Garantien für Zugriff auf XMLDatenbestände. Stoßrichtung insbesondere: XMLDaten, die relational gespeichert sind. Verwendung der Transaktionsmechanismen
Mehr7. Synchronisation Algorithmen 1
7. Synchronisation Algorithmen 1 Scheduling-Algorithmen Entwurf von Scheduling-Algorithmen Klassifikation von Synchronisationsalgorithmen Sperrprotokolle - Zweiphasige Sperrprotokolle - Deadlocks und ihr
MehrTransaktionen 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
MehrTAV Ü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.
MehrSynchronisierung 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
MehrKapitel 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
MehrKapitel 8: Transaktionen und ihre Realisierung
Vorlesung " WS 98/99 Kapitel 8: Transaktionen und ihre Realisierung Lernziele und Überblick: Transaktionen als Kooperationsmodell, Eigenschaften von Transaktionen Isolation von Transaktionen: Terminologie
MehrDatenbanken 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,
MehrKapitel 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
MehrKapitel 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
MehrKapitel 10: Transaktionsverwaltung
10. Transaktionsverwaltung Seite 1 Kapitel 10: Transaktionsverwaltung Umfasst diejenigen Komponenten eines Datenbankmanagementsystems, deren Aufgabe die Gewährleistung der Atomizität, Isolation und Dauerhaftigkeit
MehrÜ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,
MehrPRÜFUNG AUS DATENBANKSYSTEME VU 184.686 26. 6. 2014 Kennnr. Matrikelnr. Familienname Vorname
Gruppe A Bitte tragen Sie sofort und leserlich Namen, Studienkennzahl und Matrikelnummer ein und legen Sie Ihren Studentenausweis bereit. PRÜFUNG AUS DATENBANKSYSTEME VU 184.686 26. 6. 2014 Kennnr. Matrikelnr.
Mehr10. Updates in SQL 10-1 Teil 10: Updates in SQL. Literatur:
10. Updates in SQL 10-1 Teil 10: Updates in SQL Literatur: Elmasri/Navathe:Fundamentals of Database Systems, 3rd Edition, 1999. Chap. 8, SQL The Relational Database Standard Kemper/Eickler: Datenbanksysteme
MehrVerteilte Datenbanken. Kapitel 11 455 / 520
Kapitel 11 Verteilte Datenbanken 455 / 520 Überblick Terminologie Eine verteilte Datenbank (VDBMS) ist eine Sammlung von Informationseinheiten die auf verschiedene Rechner verteilt ist, die durch Kommunikationsnetze
MehrWas ist eine Transaktion?
Frühjahrsemester 2013 CS243 Datenbanken Kapitel 8: Transaktionsverwaltung H. Schuldt Was ist eine Transaktion? Eine Transaktion ist eine Menge von logisch zusammengehörenden Operationen (zumeist in ein
MehrGliederung Datenbanksysteme
Gliederung Datenbanksysteme 5. Datenbanksprachen 1. Datendefinitionsbefehle 2. Datenmanipulationsbefehle 3. Grundlagen zu SQL 6. Metadatenverwaltung 7. DB-Architekturen 1. 3-Schema-Modell 2. Verteilte
MehrMengenvergleiche: Alle Konten außer das, mit dem größten Saldo.
Mengenvergleiche: Mehr Möglichkeiten als der in-operator bietet der θany und der θall-operator, also der Vergleich mit irgendeinem oder jedem Tupel der Unteranfrage. Alle Konten außer das, mit dem größten
Mehr4 Concurrency Control: Algorithmen. Ziel: Entwicklung von Schedulern (Scheduling Algorithmen, Scheduling Protokollen), die konfliktserialisierbare
4 Concurrency Control: Algorithmen 4.1 Vorüberlegungen Ziel: Entwicklung von Schedulern (Scheduling Algorithmen, Scheduling Protokollen), die konfliktserialisierbare Schedules erzeugen. Wie im vorherigen
MehrWiederanlauf (Recovery)
DEVO 8.1 Wiederanlauf (Recovery) DEVO 8.2 Ziele Wiederherstellung eines konsistenten Datenbankzustandes nach einem Fehler. Fehler: Transaktionsabbruch: eine Transaktion muß nach einem logischen Fehler
MehrReplikation 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
MehrTeil 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
MehrDatenbanken und SQL. Kapitel 8. Concurreny und Recovery. Edwin Schicker: Datenbanken und SQL
Datenbanken und SQL Kapitel 8 Concurreny und Recovery Concurrency und Recovery Transaktionen Recovery Einführung in die Recovery Logdateien Checkpoints Conncurrency Sperrmechanismen Deadlocks SQL-Norm
MehrGrundlagen verteilter Systeme
Universität Augsburg Insitut für Informatik Prof. Dr. Bernhard Bauer Wolf Fischer Christian Saad Wintersemester 08/09 Übungsblatt 3 12.11.08 Grundlagen verteilter Systeme Lösungsvorschlag Aufgabe 1: a)
MehrModerne Betriebssysteme. Kapitel 8. Kapitel 8. Folie: 1. Multiprozessorsysteme. Autor: Andrew S. Tanenbaum
Moderne Betriebssysteme Kapitel 8 Multiprozessorsysteme Kapitel 8 Folie: 1 Multiprozessorsysteme Autor: Andrew S. Tanenbaum Pearson Studium 2009 2 3 4 5 6 7 Betriebssystemarten für Multiprozessoren Jede
MehrView. 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.
MehrTransaction Validation for XML Documents based on XPath
Transaction Validation for XML Documents based on XPath @ Informatik 2002, m-dbis Stefan Böttcher Adelhard Türling Universität Paderborn Überblick Transaktionen für XML - Daten & mobile Clients Motivation
MehrProzessor (CPU, Central Processing Unit)
G Verklemmungen G Verklemmungen Einordnung: Prozessor (CPU, Central Processing Unit) Hauptspeicher (Memory) Ein-, Ausgabegeräte/ Periphere Geräte (I/O Devices) externe Schnittstellen (Interfaces) Hintergrundspeicher
MehrIsolationslevel 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
MehrUnterabfragen (Subqueries)
Unterabfragen (Subqueries) Die kürzeste Formulierung ist folgende: SELECT Felderliste FROM Tabelle1 WHERE Tabelle1.Feldname Operator (SELECT Feldname FROM Tabelle2 WHERE Bedingung); wobei Tabelle1 und
Mehr7. Datenkontrolle. Klassifikation von Integritästbedingungen Integritätsbedingungen in SQL. Zugriffskontrolle/Autorisierung in SQL 7-1
7. Datenkontrolle ACID und Datenkontrolle Synchronisation i Anomalien Isolation Level Integritätskontrolle Klassifikation von Integritästbedingungen Integritätsbedingungen in SQL Integritätsregeln / Trigger
MehrVorlesung "Verteilte Systeme" Sommersemester 1999. Verteilte Systeme. Adreßraum. Rechner. Verteilte Systeme, Sommersemester 1999 Folie 19.
Verteilte Systeme 19. Distributed Shared Memory Sharing!! No Sharing! Sharing? Evolution der Berechnungsmodelle Vergangenheit Gemeinsamer Speicher Einzelrechner Gegenwart Nachrichtenkommunikation Verteilte
MehrAK-Automatisierungs und Kommunikationstechnik TI Technische Informatik. NWT Netzwerktechnik www.munz-udo.de
Einführung Dieser Artikel behandelt das Sperren von Dateien in PHP, Perl, Python und Java. Das Sperren von Datenbanken folgt danach. Excell Sheets kann man im Netzwerk explizit sperren. Es werden hier
MehrTransaktionen in der Praxis. Dr. Karsten Tolle
Transaktionen in der Praxis Dr. Karsten Tolle Praxisbeispiel in Java Connection con = null; try { con = DriverManager.getConnection("jdbc:db2:sample"); } catch (Exception e) { e.printstacktrace(); } con.setautocommit(false);
MehrDatenbanken - Wiederholung. Norbert Fuhr
Datenbanken - Wiederholung Norbert Fuhr Einführung Welches sind typische Probleme bei der Informationsverarbeitung ohne DBMS? Welche Abstraktionsebenen unterscheidet man bei einem DBMS? Was sind die Vorteile
MehrProbeklausur Grundlagen der Datenbanksysteme II
Prof. Dott.-Ing. Roberto V. Zicari Datenbanken und Informationssysteme Institut für Informatik Fachbereich Informatik und Mathematik Probeklausur Grundlagen der Datenbanksysteme II Frau: Herr: Vorname:
MehrDr. H. Schuldt. Das Ziel dieser Ubung ist die Untersuchung, wie die in der Vorlesung vorgestellten
Dr. H. Schuldt Eidgenossische Technische Hochschule Zurich Swiss Federal Institute of Technology Zurich Transaktionsverwaltung in modernen IS Praktische Ubung 1 Beispiellosung Einleitung Das Ziel dieser
MehrVorlesung Informationssysteme
Saarbrücken, 25.06.2015 Information Systems Group Vorlesung Informationssysteme Vertiefung Kapitel 8: Transaktionen und wann sie gebraucht werden Erik Buchmann (buchmann@cs.uni-saarland.de) Foto: M. Strauch
MehrRecovery- 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)
MehrMulticore 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
Mehr9 Verteilte Verklemmungserkennung
9 Verteilte Verklemmungserkennung 9.1 Grundlagen Für die Existenz einer Verklemmung notwendige Bedingungen Exklusive Betriebsmittelbelegung Betriebsmittel können nachgefordert werden Betriebsmittel können
MehrKapitel 4: Synchronisation: Scheduler
Kapitel 4: Synchronisation: Scheduler Ziel und Überblick Entwurf von Schedulern Sperrende Scheduler Nicht-sperrende Scheduler Hybride Scheduler 29.11.2005 TAV WS 2005 283 Kapitel 4: Synchronisation: Scheduler
Mehrfbi 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
MehrTeil VIII Transaktionen, Integrität und Trigger
page.1 Teil VIII Transaktionen, Integrität und Trigger page.2 Transaktionen, Integrität und Trigger Transaktionen, Integrität und Trigger 1 Grundbegriffe 2 Transaktionsbegriff 3 Transaktionen in SQL 4
MehrSQL: statische Integrität
SQL: statische Integrität.1 SQL: statische Integrität Im allgemeinen sind nur solche Instanzen einer Datenbank erlaubt, deren Relationen die der Datenbank bekannten Integritätsbedingungen erfüllen. Integritätsbedingungen
MehrImplementierung und Analyse von Synchronisationsverfahren für das CbDBC
Technische Universität Kaiserslautern Diplomarbeit Implementierung und Analyse von Synchronisationsverfahren für das CbDBC Susanne Margot Maria Braun September 2008 Fachbereich Informatik AG Datenbanken
MehrBeispiel: Bankensoftware. 6 Transaktionen. 6.1 Grundlagen 6.1.1 Einführung und Begriffe. Transaktionen. Beispiel (Fortsetzung 1): Verzahnte Ausführung
6 Transaktionen Beispiel: Bankensoftware 6.1 Grundlagen 6.1.1 Einführung und Begriffe Kritische Abschnitte elementares Mittel zur Konsistenzwahrung bei nebenläufigen Zugriffen Programmierer selbst für
MehrUniversität Karlsruhe (TH)
Universität Karlsruhe (TH) Forschungsuniversität gegründet 1825 Cluster-Praktikum Sommersemester 2007 Transparent Replizierte Objekte in JavaParty Institut für Programmstrukturen und Datenorganisation
MehrVerteilte Systeme SS 2015. Universität Siegen rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404. Stand: 7.
Verteilte Systeme SS 2015 Universität Siegen rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404 Stand: 7. Juli 2015 Betriebssysteme / verteilte Systeme Verteilte Systeme (1/13) i
Mehr1. Transaktionskonzept
1. Transaktionskonzept Ein wesentliches Charakteristikum für (relationale) Datenbanksysteme stellt die Unterstützung des Transaktions-Konzepts dar. Transaktionen sind Verarbeitungseinheiten, die vom DBMS
MehrKapitel 10: Transaktionen und Datenintegrität
1 Kapitel 10: Transaktionen und Datenintegrität Ein DBMS hat die Korrektheit des Datenbankzustandes unter realen Benutzungsbedingungen zu wahren. Dazu gehören die folgenden Punkte: Datensicherheit (Recovery)
MehrAufgabe der Recovery-Komponente des Datenbanksystems ist es, nach einem Fehler den jüngsten konsistenten Datenbankzustand wiederherzustellen.
Kapitel 14 Recovery Aufgabe der Recovery-Komponente des Datenbanksystems ist es, nach einem Fehler den jüngsten konsistenten Datenbankzustand wiederherzustellen. 14.1 Fehlerklassen Wir unterscheiden drei
MehrKurs. Teil 7 UNDO-Management. Universität Hannover. Agenda. Einführung. Nutzung RBS Oracle 9i Einführung Performance Tuning.
Kurs Oracle 9i Performance Tuning Teil 7 UNDO-Management Timo Meyer Wintersemester 2005 / 2006 Seite 1 von 23 Seite 1 von 23 1. 2. Nutzung des Rollback Segments 3. 4. 5. Größe von UNDO- TBS berechnen 6.
MehrIsolationsstufen für. Dr. Karsten Tolle Dienstag 31. Januar 2012
Isolationsstufen für Transaktionen / Sicherheit Dr. Karsten Tolle Dienstag 31. Januar 2012 Praxisbeispiel in Java Connection con = null; try { con = DriverManager.getConnection("jdbc:db2:sample"); } catch
MehrDeadlocks. System hat nur begrenzte Ressourcen (Ressourcentypen) Hauptspeicher Externer Speicher Drucker File
Kapitel V Deadlocks (Verklemmungen) 1 Deadlocks System hat nur begrenzte Ressourcen (Ressourcentypen) Hauptspeicher Externer Speicher Drucker File Prozesse benötigen Genehmigung vor der Benutzung von Ressourcen.
MehrDatenbanken: Backup und Recovery
Der Prozess der Wiederherstellung der Daten einer Datenbank nach einem Fehler im laufenden Betrieb in einen konsistenten, möglichst verlustfreien Zustand heißt Recovery. Beteiligt an diesem Recovery sind
MehrDatenadminstrator, Datenbankdesigner, Systemanalytiker (für die logische Sicht zuständig)
1 Grundlagen Begriffe Daten bekannte zutreffende Tatsachen über die Domäne/Miniwelt DBS Einsatz eines DBMS für eine Datenbank, DBS besteht aus folgenden Komponenten: 1. DBMS 2. Datenbank DBMS Software
MehrGoogle Spanner. Proseminar Ein-/Ausgabe Stand der Wissenschaft. Hanno Harte. Betreuer: Julian Kunkel 24.6.13
Google Spanner Proseminar Ein-/Ausgabe Stand der Wissenschaft Hanno Harte Betreuer: Julian Kunkel 24.6.13 1 /31 Gliederung - Überblick - Funktionsweise - True Time - Konsistenzsemantik - Benchmarks - Zusammenfassung
MehrInhalt: Anforderungen an DBS,
Kapitel 1. Anforderungen an DBMS und Transaktionskonzept Inhalt: Wiederholung, Anforderungen an DBS, Transaktionsbegriff Dateien und DBS (1) Es gibt verschiedene Datenmodelle und sie realisierende DBS
Mehr3.1 Schedules und Histories
3 Concurrency Control: Korrektheit Wir betrachten zunächst nur das Seitenmodell (read/write)! 3.1 Schedules und Histories Bislang: Transaktionen = (partiell) geordnete Folgen von (Daten-) Operationen...
MehrFazit: Ich kann die Prüfung empfehlen. Prof. Schlageter nimmt einem die Nervosität und ist berechenbar.
Prüfung: Datenbanken 1665 Prüfer: Prof. Schlageter Dauer: ca. 20min Note: 1,3 Termin: 25.08.2011 Die Prüfung fing etwas später an da mein Vorgänger Verspätung hatte. Zum Warmwerden sprachen wir etwas über
MehrAufbau Datenbanksysteme
Aufbau Datenbanksysteme Lehrveranstaltung Datenbanktechnologien Prof. Dr. Ingo Claßen Prof. Dr. Martin Kempa Hochschule für Technik und Wirtschaft Berlin Speichersystem c Ingo Claßen, Martin Kempa Softwarearchitektur
Mehr