3.6 Transaktionsverwaltung
|
|
- Heidi Färber
- vor 6 Jahren
- Abrufe
Transkript
1 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 z.b. in Betriebssystemen eingesetzt Jim Gray hat 1998 u.a. für seine Beiträge zur Transaktionsverwaltung den A. M. Turing Award gewonnen Quelle: 225
2 3.6.1 Transaktionsbegriff Transaktion ist eine logisch zusammenhängende Folge von Operationen, die ohne Einflüsse anderer zeitgleich verarbeiteter Transaktionen und ohne Fehler ausgeführt werden soll 226
3 Banküberweisung als Beispiel Beispiel: Überweisung von 50 von Konto A nach Konto B 1 UPDATE Konten 2 SET KontoStand = KontoStand WHERE KontoName = A 4 5 UPDATE Konten 6 SET KontoStand = KontoStand WHERE KontoName = B 227
4 Banküberweisung als Beispiel Beispiel: Überweisung von 50 von Konto A nach Konto B 1) a = read(a) Lese Kontostand von Konto A in Variable a 2) a = a 50 Reduziere den Wert von a um 50 3) write(a,a) Schreibe neuen Kontostand von A 4) b = read(b) Lese Kontostand von Konto B in Variable b 5) b = b + 50 Erhöhe den Wert von b um 50 6) write(b,b) Schreibe neuen Kontostand von B Was passiert, wenn der Strom ausfällt? 228
5 Transaktionsanfang und Transaktionsende Wie können wir mehrere Operationen zusammenfassen? begin of transaction (bot) markiert den Anfang einer Transaktion commit markiert das Ende einer erfolgreichen Transaktion, deren Änderungen festgeschrieben werden sollen rollback markiert das Ende einer erfolglosen Transaktion, deren Änderungen rückgängig zu machen sind 229
6 Banküberweisung als Beispiel Beispiel: Überweisung von 50 von Konto A nach Konto B 1) begin of transaction 2) a = read(a) Lese Kontostand von Konto A in Variable a 3) a = a 50 Reduziere den Wert von a um 50 4) write(a,a) Schreibe neuen Kontostand von A 5) b = read(b) Lese Kontostand von Konto B in Variable b 6) b = b + 50 Erhöhe den Wert von b um 50 7) write(b,b) Schreibe neuen Kontostand von B 8) commit 230
7 Eigenschaften von Transaktionen Transaktionen sollen die folgenden Eigenschaften haben Atomicity (Atomarität) Consistency (Konsistenz/Integrität) Isolation (Isolation) Durability (Dauerhaftigkeit) Datenbanksysteme müssen so implementiert werden, dass diese sogenannten ACID-Eigenschaften sichergestellt werden 231
8 Eigenschaften von Transaktionen Atomicity (Atomarität): Entweder werden alle Änderungen der Transaktion in der Datenbank festgeschrieben oder gar keine ( ganz oder gar nicht ) Beispiel: Werden die 50 von Konto A abgebucht, so müssen sie auch Konto B gutgeschrieben werden; ein Verlust der 50 ist ausgeschlossen. Fällt bspw. der Strom zwischen den beiden Buchungsvorgängen aus, so muss bei Wiederanlauf des RDBMS die Abbuchung von Konto A automatisch rückgängig gemacht werden. 232
9 Eigenschaften von Transaktionen Consistency (Konsistenz): Die Transaktion hinterlässt die Datenbank in einem konsistenten Zustand gemäß der definierten Integritätsbedingungen; andernfalls muss die Transaktion zurückgesetzt werden Beispiel: Eine Integritätsbedingung könnte sein, dass kein Konto seinen Kreditrahmen überschreiten darf; wird diese Konsistenzbedingung für A verletzt, darf die Überweisung nicht durchgeführt werden 233
10 Eigenschaften von Transaktionen Isolation (Isolation): Die Transaktion muss so auf der Datenbank ausgeführt werden, als wäre sie die einzige Transaktion, d.h. es darf keine Wechselwirkungen mit anderen zeitgleich ausgeführten Transaktionen geben Beispiel: Kontostand von Konto A darf nicht geschrieben werden, wenn er zwischenzeitlich durch eine andere Transaktion verändert wurde 234
11 Eigenschaften von Transaktionen Durability (Dauerhaftigkeit): Wird eine Transaktion erfolgreich abgeschlossen, so müssen ihre Änderungen dauerhaft in der Datenbank festgeschrieben sein, d.h. auch nach einem Fehler noch vorhanden sein Beispiel: Fällt der Strom in der Bank aus, kurz nachdem unsere Überweisung durchgeführt wurde, müssen sich die 50 noch immer auf Konto B befinden 235
12 Fehlerarten Datenbanksystem muss ACID-Eigenschaften bei verschiedenen Arten von Fehlern sicherstellen Fehler ohne Primärspeicherverlust (z.b. durch Fehler in der Anwendung) Fehler mit Primärspeicherverlust (z.b. durch Stromausfall) Fehler mit Sekundärspeicherverlust (z.b. durch technischen Defekt der Festplatte) 236
13 Fehlerbehandlung T1 T2 Zeit Fehler Fehlerbehandlung muss sicherstellen, dass die Wirkungen der erfolgreich abgeschlossenen Transaktion T1 dauerhaft in übernommen sind der erfolglosen Transaktion T2 rückgängig gemacht werden 237
14 Fehlerbehandlung Fehlerbehandlung (recovery) stellt einen konsistenten Zustand der Datenbank nach einem Fehler wieder her Fehler ohne Primärspeicherverlust können relativ einfach behoben werden Fehler mit Primärspeicherverlust erfordern die Wiederherstellung eines konsistenten Zustands aus den gespeicherten Daten und dem Verlaufsprotokoll Fehler mit Hintergrundspeicherverlust erfordern die Wiederherstellung eines konsistenten Zustands aus Archivkopie der Daten und dem Verlaufsprotokoll 238
15 Mehrbenutzerbetrieb Datenbankoperationen greifen meist auf langsame Ressourcen (z.b. Sekundärspeicher) zu Parallele Ausführung mehrerer Transaktionen führt zu besserer Auslastung schneller Ressourcen (z.b. CPU) und insgesamt höherer Leistung des Datenbanksystems T1 T2 Zeit Zeit 239
16 Mehrbenutzerbetrieb Mehrbenutzerbetrieb, d.h. parallele Ausführung mehrerer Transaktionen, ist wünschenswert, um die Leistung zu steigern, führt aber zu Problemen: Abhängigkeit von nicht festgeschriebenen Änderungen z.b. von anderen nebenläufigen Transaktionen (dirty read) Verlust von Änderungen an den Daten (lost update) Gelesene Daten zwischenzeitlich verändert (non-repeatable read & phantom read) 240
17 Dirty Read Abhängigkeit von nicht festgeschriebenen Änderungen Überweisung von 30 von Konto A nach Konto B Verzinsung von Konto A mit 1% T 1 T 2 1 a 1 = read(a) 2 a 1 = a write(a, a 1 ) 4 a 2 = read(a) 5 a 2 = a 2 ú write(a, a 2 ) 7 b 1 = read(b) 8 rollback T 2 liest geänderten ( dreckigen ) Kontostand von A 241
18 Lost Update Verlust von Änderungen an den Daten Überweisung von 30 von Konto A nach Konto B Verzinsung von Konto A mit 1% T 1 T 2 1 a 1 = read(a) 2 a 1 = a a 2 = read(a) 4 a 2 = a 2 ú write(a, a 2 ) 6 write(a, a 1 ) 7 b 1 = read(b) 8 b 1 = b write(b,b 1 ) T 1 überschreibt zwischenzeitliche Änderung durch T 2 242
19 Non-Repeatable Read Nichtwiederholbares Lesen von Daten Liste der überzogenen Konten (soll Konto A beinhalten) Überweisung von Lottogewinn auf Konto A Liste der überzogenen Konten (enthält Konto A nicht mehr) T 1 T 2 1 SELECT * FROM Konten WHERE KontoStand < 0 2 UPDATE Konten SET KontoStand = KontoStand WHERE Konto = A 3 SELECT * FROM Konten WHERE KontoStand < 0 Konto A wurde zwischenzeitlich verändert und ist nun nicht mehr im Ergebnis enthalten 243
20 Phantom Read Nichtwiederholbares Ergebnis durch Phantomdaten Gesamtguthaben über alle Konten Konto C wird eröffnet und 1000 in bar werden eingezahlt Gesamtguthaben über alle Konten T 1 T 2 1 SELECT SUM(KontoStand) FROM Konten 2 INSERT INTO Konten ( C, 1000) 3 SELECT SUM(KontoStand) FROM Konten Ergebnis der Anfrage von T 1 ändert sich, da zwischenzeitlich andere Daten hinzugefügt wurden 244
21 Synchronisation Datenbanksysteme stellen Isolation von Transaktionen im Mehrbenutzerbetrieb durch Sperrmechanismen sicher Unterschiedliche Arten von Sperren (z.b. Lesesperre) und Sperrgranulaten (z.b. Datensatz oder Tabelle) Transaktionen werden derart verschachtelt, dass dies nicht von serieller Ausführung zu unterscheiden ist RDBMSs unterstützten verschiedene Isolationsstufen zur Auflockerung der Anforderungen bzgl. Isolation 245
22 3.6.2 Transaktionen in SQL Transaction Control Language (TCL) als Bestandteil von SQL stellt Kommandos für Transaktionen bereit BEGIN TRANSACTION <Name der Transaktion> markiert den Anfang einer benannten Transaktion (Benennung wird eher selten verwendet) COMMIT <Name der Transaktion> schreibt die Änderung der Transaktion fest ROLLBACK <Name der Transaktion> macht Änderungen der Transaktion rückgängig 246
23 Transaktionen in SQL Transaktionen in SQL enden entweder erfolgreich mit einem COMMIT oder erfolglos mit einem ROLLBACK Transaktionsanfang ist meist implizit, d.h. eine Transaktion beginnt mit dem ersten Kommando bzw. dem ersten Kommando nach einem COMMIT oder ROLLBACK RDBMSs unterstützen AUTOCOMMIT (ON/OFF), dann wird jedes Kommando als eigene Transaktion behandelt 247
24 Savepoints Einige RDBMSs (z.b. MS SQL Server) erlauben zusätzlich die Markierung sogenannter Savepoints innerhalb einer Transaktion mittels 1 SAVE TRANSACTION <Name des Savepoints> Transaktion kann dann bis zu einem definierten Savepoint mittels ROLLBACK zurückgefahren werden 248
25 3.6.3 Fehlerbehandlung Fehlerbehandlung (recovery) stellt die Atomarität, Integrität und Dauerhaftigkeit von Transaktionen sicher, wenn Fehler mit/ohne Primärspeicherverlust auftreten Verlaufsprotokoll (log) protokolliert Änderungen der Daten, bevor diese an Daten selbst vorgenommen werden Verlaufsprotokoll erlaubt Rekonstruktion eines konsistenten Zustands der Datenbank sowie Rücksetzen der Änderungen durch eine einzelne Transaktion (ROLLBACK) 249
26 Pufferverwaltung RDBMSs verwenden Seitenersetzungsstrategie, um bei vollem Puffer zu entscheiden, welche Seite verdrängt wird Seiten können von RDBMS im Puffer festgehalten werden (fix) und dürfen dann nicht verdrängt werden Seiten dürfen verdrängt werden, auch wenn sie durch nicht abgeschlossene Transaktion geändert wurden Seiten dürfen im Puffer bleiben, auch wenn sie durch eine abgeschlossene Transaktion geändert wurden 250
27 Wiederherstellen und Rückgängigmachen Bei Fehler mit Primärspeicherverlust (z.b. Stromausfall) muss das DBMS sicherstellen, dass Änderungen durch nicht abgeschlossene Transaktionen, die bereits im Sekundärspeicher materialisiert wurden, rückgängig gemacht werden (undo) Änderungen durch abgeschlossene Transaktionen, die noch nicht im Sekundärspeicher materialisiert sind, wiederholt werden (redo) 251
28 Verlaufsprotokoll RDBMSs verwenden ein Verlaufsprotokoll (log), um Datenänderungen zu protokollieren und diese bei Bedarf wiederholen oder rückgängig machen zu können Verlaufsprotokoll wird auf Sekundärspeicher und Tertiärspeicher geschrieben Jeder Eintrag im Verlaufsprotokoll entspricht genau einer Änderung der Daten einer Seite 252
29 Verlaufsprotokoll Einträge des Verlaufsprotokoll haben folgende Struktur LSN (log sequence number) durchlaufende Nummer TA - Transaktionskennung PID Seitennummer, auf der geänderte Daten stehen REDO-Information und UNDO-Information PrevLSN Verweis auf vorigen Eintrag des Verlaufsprotokolls, der zur gleichen Transaktion gehört Seiten vermerken zudem die LSN der letzten Änderung, an den darin enthaltenen Daten 25 P1 253
30 Verlaufsprotokoll Beispiel: Überweisung von 30 von Konto A nach B T 1 Verlaufsprotokoll (LSN, TA, PID, REDO, UNDO, PrevLSN) 1 bot (#1, T 1,, bot,, ) 2 a = read(a) 3 a = a 30 4 write(a, a 1 ) (#2, T 1, P A, A = 30, A+ =30, #1) 5 b = read(b) 6 b = b write(b,b) (#3, T 1, P B, B+ =30, B = 30, #2) 8 commit (#4, T 1,, commit,, #3) 254
31 WAL-Prinzip Verlaufsprotokoll wird mittels Ringpuffer implementiert, um Ausschreiben auf Sekundärspeicher effizienter zu machen Wiederherstellen und Rückgängigmachen funktionieren nur, wenn das Write-Ahead-Log-Prinzip verwendet wird bevor eine Transaktion festgeschrieben wird, müssen alle zu ihr gehörenden Log-Einträge ausgeschrieben werden bevor eine geänderte Seite aus dem Puffer verdrängt wird, müssen alle Log-Einträge, die sich auf sie beziehen, ausgeschrieben werden 255
32 Wiederanlauf nach einem Fehler Bei Fehler mit Primärspeicherverlust, lässt sich ein konsistenter Zustand aus Daten und Verlaufsprotokoll in drei Schritten wiederherstellen 1) Bestimme Gewinner (winner) und Verlierer (looser), deren Änderungen wiederholt bzw. rückgängig gemacht werden 2) Wiederherstellen aller Änderungen (REDO-Einträge) mittels chronologischem Durchlauf des Verlaufsprotokolls 3) Rückgängigmachen der Änderungen von Verlierern (UNDO-Einträge) mittels umgekehrt chronologischem Durchlauf des Verlaufsprotokolls 256
33 Gewinner und Verlierer Gewinner (winner) und Verlierer (looser) unter den Transaktionen werden durch Analyse des Verlaufsprotokolls ermittelt Eine Transaktion wird zum Gewinner, wenn das Verlaufsprotokoll sowohl einen bot-eintrag als auch einen commit-eintrag für sie enthält Eine Transaktion wird zum Verlierer, wenn das Verlaufsprotokoll nur einen bot-eintrag jedoch keinen commit-eintrag für sie enthält 257
34 Wiederherstellen aller Änderungen Verlaufsprotokoll wird in chronologischer Reihenfolge durchlaufen und für jeden Eintrag betroffene Seite vom Sekundärspeicher in den Puffer geholt, sofern sie noch nicht dort ist LSN des Log-Eintrags mit in der Seite gespeicherter LSN der letzten Änderung verglichen REDO-Operation auf die Seite angewandt, sofern LSN des Log-Eintrags größer (d.h. neuer) als LSN der letzten Änderung ist 258
35 Rückgängigmachen von Änderungen Verlaufsprotokoll wird in umgekehrt chronologischer Reihenfolge durchlaufen und für jeden Eintrag überprüft, ob er zu einer Verlierer-Transaktion gehört und sofern dies der Fall ist die Änderung mittels der UNDO-Operation rückgängig gemacht 259
36 Zurücksetzen einer Transaktion Verlaufsprotokoll unterstützt auch das Zurücksetzen einer Transaktion mittels ROLLBACK, indem die zur Transaktion gehörenden Log-Einträge rückwärts entlang ihrer PrevLSN-Einträge durchlaufen werden für jeden Log-Eintrag die darin vermerkte UNDO-Operation ausgeführt wird 260
37 3.6.4 Mehrbenutzerbetrieb Bei nebenläufiger Ausführung mehrerer Transaktionen muss deren Isolation sichergestellt werden Man kann mittels Serialisierbarkeitsgraph feststellen, ob eine verschachtelte Ausführung mehrerer Transaktionen zu einer seriellen Ausführung äquivalent ist RDBMSs erreichen Synchronisation durch Sperren, die einer Transaktion exklusiven Lese-/Schreibzugriff z.b. auf einer Seite sichern 261
38 Serialisierbarkeit Historie bezeichnet eine verschachtelte Ausführung von elementare Operationen mehrerer Transaktionen r i (A) Transaktion i liest den Wert von A w i (A) Transaktion i schreibt den Wert von A a i Transaktion i wird abgebrochen c i Transaktion i wird festgeschrieben Historie erfasst die Reihenfolge der elementaren Operationen innerhalb einer Transaktion r 1 (A) w 1 (A) c 1 262
39 Serialisierbarkeit Stehen elementare Operationen verschiedener Transaktionen in Konflikt, muss die Historie zusätzlich deren Reihenfolge festlegen, z.b. r i (A) und w j (A) da je nach Reihenfolge die Transaktion i den neuen oder alten Wert von A liest w i (A) und w j (A) da je nach Reihenfolge der von Transaktion i oder der von Transaktion j geänderte Wert von A bestehen bleibt 263
40 Serialisierbarkeit Beispiel: Verschachtelte Ausführung dreier Transaktionen r 3 (A) w 3 (C) c 3 r 2 (B) w 2 (B) w 2 (A) w 2 (D) c 2 r 1 (A) w 1 (A) c 1 Historie legt Reihenfolge w 1 (A) vor w 2 (A) vor r 3 (A) für die in Konflikt stehenden Operationen fest 264
41 Serialisierbarkeitsgraph Serialisierbarkeitsgraph lässt sich aus Historie ableiten je Transaktion T i gibt es einen Knoten die Kante (T i, T j ) ist vorhanden, wenn in der Historie eine Operation von T i vor einer Operation von T j liegt Beispiel: T 3 r 3 (A) w 3 (C) c 3 r 2 (B) w 2 (B) w 2 (A) w 2 (D) c 2 r 1 (A) w 1 (A) c 1 T 2 T 1 265
42 Serialisierbarkeitsgraph Historie ist genau dann serialisierbar (d.h. äquivalent zu einer seriellen Ausführung der Transaktionen), wenn der Serialisierbarkeitsgraph azyklisch ist Beispiel: Historie ist äquivalent zur seriellen Ausführung der Transaktionen T 1, T 2 und T 3 T 3 r 3 (A) w 3 (C) c 3 r 2 (B) w 2 (B) w 2 (A) w 2 (D) c 2 r 1 (A) w 1 (A) c 1 T 2 T 1 266
43 Sperrbasierte Synchronisation RDBMSs verwenden Sperren, um sicherzustellen, dass verschachtelte Ausführung von Transaktionen äquivalent zu einer seriellen Ausführung ist Lesesperre (shared lock, read lock) S auf A erlaubt Transaktion T i die Operation r i (A) auszuführen; mehrere Transaktionen können aufgrund einer Lesesperre lesend auf A zugreifen Schreibsperre (exclusive lock, write lock) X auf A erlaubt Transaktion T i die Operation w i (A) auszuführen; nur eine Transaktion kann bei einer Schreibsperre lesend oder schreibend auf A zugreifen 267
44 Verträglichkeit von Sperren Es gelten folgende Verträglichkeiten zwischen Sperren gesetzte Sperre keine S X Anforderung von S ja ja nein Anforderung von X ja nein nein Besteht z.b. bereits eine Lesesperre auf einem Objekt, kann eine weitere Lesesperre, jedoch keine Schreibsperre angefordert werden Die anfordernde Transaktion muss dann warten, bis die bestehenden Lesesperren freigegeben werden 268
45 2-Phasen Sperrprotokoll Serialisierbarkeit der Historie wird mittels des 2-Phasen- Sperrprotokolls (two phase locking, 2PL) sichergestellt jedes in einer Transaktion benutzte Objekt wird gesperrt jede Transaktion durchläuft zwei Phasen Wachstumsphase, in der zusätzliche Sperren angefordert, aber keine bereits erworbenen freigegeben werden Schrumpfungsphase, in der bereits erworbene Sperren freigegeben, aber keine neuen angefordert werden zum Transaktionsende müssen alle Sperren freigegeben sein 269
46 2-Phasen Sperrprotokoll Wachstumsphase und Schrumpfungsphase im 2PL # Sperren Wachstum Schrumpfung Zeit 270
47 2-Phasen Sperrprotokoll Beispiel: Verschachtelung gemäß 2-Phasen Sperrprotokoll T 1 T 2 Erläuterung 1 lockx(a) 2 a 1 = read(a) 3 write(a) 4 locks(a) T 2 muss warten 5 lockx(b) 6 read(b) 7 unlockx(a) 8 a 2 = read(a) T 2 wecken 9 locks(b) T 2 muss warten 10 write(b) 11 unlockx(b) T 2 wecken 12 b 1 = read(b) 13 commit 14 unlocks(a) 15 unlocks(b) 16 commit 271
48 Verklemmungen (deadlocks) Sperren können zu Verklemmungen (deadlocks) führen, d.h. Transaktionen warten gegenseitig aufeinander T 1 T 2 Erläuterung 1 lockx(a) 2 lockx(b) 3 b 2 = read(b) 4 a 1 = read(a) 5 write(a) 6 lockx(b) T 1 wartet auf T 2 7 locks(a) T 2 wartet auf T 1 RDBMS erkennt Verklemmungen (z.b. mittels Überwachung des Fortschritts) und löst sie auf, indem es eine der Transaktionen abbricht 272
49 Isolationsstufen SQL-92 definiert vier Isolationsstufen (isolation levels), die Lockerung der Anforderung Isolation ermöglichen Serializable Repeatable Read phantom read erlaubt Read Committed non-repeatable read und phantom read erlaubt Read Uncommitted dirty read, non-repeatable read und phantom read erlaubt 273
50 Isolationsstufen Niedrigere Isolationsstufe erlaubt eine stärkere Verschachtelung von Transaktionen reduziert die Anzahl benötigter Sperren verringert zur Ausführung der Transaktionen benötigte Zeit, was beim Mehrbenutzerbetrieb sehr wichtig sein kann nimmt hierzu Inkonsistenzen der Daten in Kauf Isolationsstufe für aktuelle und kommende Transaktionen lässt sich mittels folgenden SQL-Kommandos festlegen 1 SET TRANSACTION ISOLATION LEVEL <Isolationsstufe> 274
51 Zusammenfassung Transaktionen als logisch zusammenhängende Folge von Operationen, die ganz oder gar nicht ausgeführt wird ACID-Eigenschaften von Transaktionen Atomicity (Atomarität) Consistency (Integrität/Konsistenz) Isolation (Isolation) Durability (Dauerhaftigkeit) Fehlerbehandlung & Synchronisation zur Wahrung der ACID-Eigenschaften bei Fehlern und Mehrbenutzerbetrieb 275
52 Literatur [1] A. Kemper und A. Eickler: Datenbanksysteme Eine Einführung, De Gruyter Oldenbourg, 2013 (Kapitel 9) [2] G. Saake, K.-U. Sattler und A. Heuer: Datenbanken - Konzepte und Sprachen, mitp Professional, 2013 (Kapitel 12) 276
7. Transaktionsverwaltung
7. Transaktionsverwaltung Motivation Transaktionen erlauben Bündelung von Operationen und gelten als wichtigster Beitrag des Bereichs Datenbanken zur Informatik; sie werden heute auch außerhalb von Datenbanksystemen
MehrDatenbanksysteme 2009
Datenbanksysteme 2009 Vorlesung vom 30.06.09 Kapitel 14: Mehrbenutzersynchronisation Oliver Vornberger Institut für Informatik Universität Osnabrück Multiprogramming Zeitachse Einbenutzer betrieb T1 T2
MehrEigenschaften von TAs: ACID-Prinzip
Transaktionsparadigma Definition: Transaktion ununterbrechbare Folge von DML-/DDL-Befehlen begin transaction --- end transaction begin: meist implizit mit ersten Datenbankzugriff end: commit (work) oder
MehrMehrbenutzersynchronisation
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
MehrMehrbenutzersynchronisation
Kapitel 13 Mehrbenutzersynchronisation 13.1 Multiprogramming Unter M ultiprogramming versteht man die nebenläufige, verzahnte Ausführung mehrerer Programme. Abbildung 13.1 zeigt exemplarisch die dadurch
MehrMehrbenutzersynchronisation
Mehrbenutzersynchronisation Ausführung der drei Transaktionen T 1, T 2 und T 3 : (a) im Einzelbetrieb und Zeitachse T 1 T 2 T 3 (b) im (verzahnten) Mehrbenutzerbetrieb (gestrichelte Linien repräsentieren
MehrTransaktionsverarbeitung 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
MehrDatenbanksysteme. Transaktionen. Burkhardt Renz. Sommersemester Fachbereich MNI Technische Hochschule Mittelhessen
Datenbanksysteme Transaktionen Burkhardt Renz Fachbereich MNI Technische Hochschule Mittelhessen Sommersemester 2019 Übersicht Transaktionen Motivation ACID-Eigenschaften Recovery Ursachen für Recovery
MehrMehrbenutzer-Synchronisation
Mehrbenutzer-Synchronisation Konflikt-Kategorien Serialisierung Historien Sperrungen Verklemmungen Optimistische Synchronisation Synchronisation in SQL Kapitel 11 1 Mehrbenutzersynchronisation Ausführung
MehrTransaktionsverwaltung
Transaktionsverwaltung VL Datenbanksysteme Ingo Feinerer Arbeitsbereich Datenbanken und Artificial Intelligence Institut für Informationssysteme Technische Universität Wien Transaktionsverwaltung Transaktionen:
MehrTransaktionsmanagement - Einführung. Prof. Dr. T. Kudraß 1
Transaktionsmanagement - Einführung Prof. Dr. T. Kudraß 1 Einführung Nebenläufige Ausführung von Benutzerprogrammen wesentlich für gute Performance des DBMS Weil Plattenzugriffe häufig und relativ langsam
MehrBeispielszenarien. 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
MehrTransaktionsverwaltung
Kapitel l2 Transaktionsverwaltung Skript 2009 Matthias Schubert Dieses Skript basiert auf dem Skript zur Vorlesung Datenbanksysteme II von Prof. Dr. Christian Böhm gehalten im Sommersemester 2007 an der
MehrTU 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)
MehrDatenbank- Verwaltungssysteme
Datenbank- Verwaltungssysteme Diana Troancă Babeș-Bolyai Universität Fakultät Mathematik und Informatik Dozent: Diana Troancă E-mail: dianat [at] cs.ubbcluj.ro Website: www.cs.ubbcluj.ro/~dianat/ Feedback
MehrKapitel 2 Transaktionsverwaltung. Skript 2009 Matthias Schubert
Kapitel 2 Transaktionsverwaltung Skript 2009 Matthias Schubert Dieses Skript basiert auf dem Skript zur Vorlesung Datenbanksysteme II von Prof. Dr. Christian Böhm gehalten im Sommersemester 2007 an der
MehrFehlerbehandlung (Recov
Fehlerbehandlung (Recov Fehlerarten Auswirkung der Speicherhierarchie Protokollierung von Änderungen Wiederanlauf nach Fehler ( Sicherungspunkte) Media-Recovery Kapitel 10 1 Fehlerbehandlung (Recovery)
MehrTransaktionsverarbeitung 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
MehrTU 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)
MehrInhaltsverzeichnis. Inhaltsverzeichnis
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
MehrFehlerbehandlung (Recovery)
Fehlerbehandlung (Recovery) Fehlerklassifikation 1. Lokaler Fehler in einer noch nicht festgeschriebenen (committed) Transaktion Wirkung muss zurückgesetzt werden R1-Recovery 2. Fehler mit Hauptspeicherverlust
MehrKommunikation und Datenhaltung
Kommunikation und Datenhaltung Transaktionsverwaltung Überblick über den Datenhaltungsteil Motivation und Grundlagen Architektur von Datenbanksystemen Datenbankanfragen Relationenmodell und Relationenalgebra
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
MehrAnforderungen an die Transaktionsverwaltung gleichzeitig (nebenläug) ablaufende Transaktionen Synchronisation Datenbanken gegen Soft- und Hardwarefehl
Transaktionsverwaltung Beispiel-Transaktion 1. Lese den Kontostand von A in die Variable a: read(a,a); 2. Reduziere den Kontostand um 50, DM: a := a, 50; 3. Schreibe den neuen Kontostand in die Datenbasis:
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
Mehr6. Updates in SQL 6-1. Inhalt. 1. Update-Kommandos in SQL. 2. Transaktionen. 3. Gleichzeitige Zugriffe
6. Updates in SQL 6-1 Inhalt 1. Update-Kommandos in SQL 2. Transaktionen 3. Gleichzeitige Zugriffe 6. Updates in SQL 6-2 Updates in SQL: Übersicht SQL-Befehle zur Änderung des DB-Zustands: 1. INSERT: Einfügung
MehrTU 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/
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
MehrMehrbenutzer-Synchronisation
Mehrbenutzer-Synchronisation Konflikt-Kategorien Serialisierung Historien Sperrungen Verklemmungen Optimistische Synchronisation Synchronisation in SQL Kapitel 11 1 Mehrbenutzersynchronisation Ausführung
MehrFehlerklassifikation 1. Lokaler Fehler in einer noch nicht festgeschriebenen. Wirkung muss zurückgesetzt werden R1-Recovery
Fehlerbehandlung (Recovery) Fehlerklassifikation 1. Lokaler Fehler in einer noch nicht festgeschriebenen (committed) Transaktion Wirkung muss zurückgesetzt werden R1-Recovery Recovery 2. Fehler mit Hauptspeicherverlust
MehrÜbung 14. Tutorübung zu Grundlagen Datenbanken (Gruppen DO-T24 / DO-T31 WS 2016/2017)
Übung 14 Tutorübung zu Grundlagen Datenbanken (Gruppen DO-T24 / DO-T31 WS 2016/2017) Dennis Fischer dennis.fischer@tum.de http://home.in.tum.de/fischerd Technische Universität München Fakultät für Informatik
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
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.
Mehr9.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
MehrKapitel 9a Transaktionen - Synchronisation
LUDWIG- MAXIMILIANS- UNIVERSITY MUNICH DEPARTMENT INSTITUTE FOR INFORMATICS DATABASE Skript zur Vorlesung: Datenbanksysteme Wintersemester 2018/2019 Kapitel 9a Transaktionen - Synchronisation Vorlesung:
MehrÜ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)
MehrFehlerbehandlung (Recovery)
Fehlerbehandlung (Recovery) Fehlerbehandlung (Recovery) Fehlerklassifikation Fehlerarten Auswirkung der Speicherhierarchie Protokollierung von Änderungen Wiederanlauf nach Fehler ( Sicherungspunkte) Media-Recovery
MehrTransaktionen. Concurrency Management in MS SQL Server
Transaktionen Concurrency Management in MS SQL Server Transaktionen in SQL Server SQL Server bietet die Möglichkeit, eine Reihe von Datenbankoperationen (Änderungen) in einem logischen Vorgang zu gruppieren
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
MehrGrundlagen 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
MehrTransaktionsverwaltung read write read write
Transaktionsverwaltung Beispiel einer typischen Transaktion in einer Bankanwendung: 1. Lese den Kontostand von A in die Variable a: read(a,a); 2. Reduziere den Kontostand um 50.- Euro: a:= a 50; 3. Schreibe
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
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:
MehrMehrbenutzersynchronisation
Mehrbenutzer Synchronisation KonfliktKategorien Serialisierung Historien Sperrungen Verklemmungen Optimistische Synchronisation Synchronisation in SQL Mehrbenutzersynchronisation Ausführung der drei Transaktionen,
MehrFehlerbehandlung und Recovery
1 / 44 Fehlerbehandlung und Recovery VU Datenbanksysteme vom 24.10. 2016 Reinhard Pichler Arbeitsbereich Datenbanken und Artificial Intelligence Institut für Informationssysteme Technische Universität
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
MehrTransaktionsverwaltung
Transaktionsverwaltung VU Datenbanksysteme vom 21.10. 2015 Reinhard Pichler Arbeitsbereich Datenbanken und Artificial Intelligence Institut für Informationssysteme Technische Universität Wien Transaktionsverwaltung
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!
MehrTransaktionskonzept 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!
Mehr8. 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 -
MehrMehrbenutzer-Synchronisation
MehrbenutzerSynchronisation KonfliktKategorien Serialisierung Historien Sperrungen Verklemmungen Optimistische Synchronisation Synchronisation in SQL Mehrbenutzersynchronisation Ausführung der drei Transaktionen,
MehrIn 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
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
MehrFakultät für Informatik & Wirtschaftsinformatik DB & IS II SS Transaktionen & ACID. Dr. Christian Senger Transaktionen & ACID 1
Transaktionen & ACID Dr. Christian Senger Transaktionen & ACID 1 PC Architekturen Kein Mehrbenuzterbetrieb Recovery? Benutzerabbrüche? PC Lokale Datenbank PC PC PC PC PC PC-System DBMS PC PC PC PC Internet
MehrKapitel 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
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
MehrGruppe A Bitte tragen Sie SOFORT und LESERLICH Namen und Matrikelnr. ein, und legen Sie Ihren Studentenausweis bereit.
Gruppe A Bitte tragen Sie SOFORT und LESERLICH Namen und Matrikelnr. ein, und legen Sie Ihren Studentenausweis bereit. PRÜFUNG AUS 21.06.2018 DATENMODELLIERUNG 2 (184.790) DATENBANKSYSTEME (184.686) GRUPPE
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
MehrVorlesung "Systemsoftware II" Wintersemester 2002/03
(c) Peter Sturm, Universität Trier 1 Verteilte Systeme 16. Transaktionen Motivation Sicherung konsistenter Systemzustände Beispiele Amnesieproblematik bei zustandsbehafteten Servern Sicherung des Primaries
MehrVorlesung "Verteilte Systeme" Wintersemester 2000/2001. Verteilte Systeme. 14. Transaktionen
Verteilte Systeme 14. Transaktionen Motivation Sicherung konsistenter Systemzustände Beispiele Amnesieproblematik bei zustandsbehafteten Servern Sicherung des Primaries (Primary-Backup- Approach) Aktive
MehrConcurrency und Recovery
Concurrency und Recovery Concurrency Gleichzeitiger Zugriff auf Datenbankdaten im Mehrbenutzerbetrieb Recovery Wiederherstellen der Datenbank im Fehlerfall In der Praxis sind Concurrency und Recovery unverzichtbar.
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,
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.
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
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
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
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
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
MehrVerteiltes Sperren Verteilte Recovery
Verteiltes Sperren Verteilte Recovery Verteiltes Sperren (Distributed Locking) Wie werden Sperren für Objekte über mehrere Knoten hinweg verwaltet? Zentralisiert: Ein Knoten für Sperren verantwortlich
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,
MehrVorlesung Datenbanksysteme 2. Übung Recovery Checkpointing
Vorlesung Datenbanksysteme 2 Übung Recovery Checkpointing Aufgabe Checkpointing Das Datenbanksystem habe für folgenden Schedule zwei LRU-Cache- Slots reserviert. Der Recovery Manager unterstützt Undo/No
Mehr5. Transaktionsverarbeitung
5. Transaktionsverarbeitung 5.1. Einführung Viele Anwendungsprogramme / interaktive Benutzer arbeiten gleichzeitig (konkurrierend) auf gemeinsamer Datenbank (mit den gleichen Daten). Notwendigkeit: Abwicklung
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
MehrMächtigkeit von 2PL. Geben Sie einen Schedule S an, der. konfliktserialisierbar, jedoch nicht bei Anwendung von 2PL entstehbar. ist.
9. Transaktionsverwaltung 9.2. Mehrbenutzerkontrolle Rückblick Rückblick Geben Sie einen Schedule S an, der ist. konfliktserialisierbar, jedoch nicht bei Anwendung von 2PL entstehbar Mächtigkeit von 2PL
Mehr9.2.4 Phantomproblem. Mächtigkeit von 2PL. Lösung des Phantomproblems. bisherige implizite Annahme
Rückblick Rückblick Geben Sie einen Schedule S an, der konfliktserialisierbar, jedoch nicht bei Anwendung von 2PL entstehbar ist. Schedule mit Phantom Sei eine Transaktion T 1 eine Ausführung eines Programmes
MehrGruppe A Bitte tragen Sie SOFORT und LESERLICH Namen und Matrikelnr. ein, und legen Sie Ihren Studentenausweis bereit.
Gruppe A Bitte tragen Sie SOFORT und LESERLICH Namen und Matrikelnr. ein, und legen Sie Ihren Studentenausweis bereit. PRÜFUNG AUS 30.01.2018 DATENMODELLIERUNG 2 (184.790) DATENBANKSYSTEME (184.686) GRUPPE
Mehr9. 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
MehrIsolationsstufen 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)
MehrGruppe A Bitte tragen Sie SOFORT und LESERLICH Namen und Matrikelnr. ein, und legen Sie Ihren Studentenausweis bereit.
Gruppe A Bitte tragen Sie SOFORT und LESERLICH Namen und Matrikelnr. ein, und legen Sie Ihren Studentenausweis bereit. PRÜFUNG AUS MUSTERLÖSUNG 30.01.2018 DATENMODELLIERUNG 2 (184.790) DATENBANKSYSTEME
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
MehrTransaktionen 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
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:
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)
MehrTransaktionen und Synchronisation konkurrierender Zugriffe
Transaktionen und Synchronisation konkurrierender Zugriffe Fragestellungen Aufgaben des Transaktionsmanagers Aktivieren von Transaktionen entsprechend den Anforderungen von Anwendungsprogrammen. Dabei
MehrÜbung Datenbanksysteme I Transaktionen, Selektivität, XML
Übung Datenbanksysteme I G-3.1.09, Campus III Hasso Plattner Institut Übersicht Übungsthemen Transaktionen Selektivität XML Chart 2 Wiederholung Transaktionen Eine Transaktion ist eine Folge von Operationen
MehrKonfliktgraph. 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
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 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
Mehr1 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)
MehrDatenbanken 1. Kapitel 7: Transaktionsmanagement 7-1. Datenbanken 1 (Bachelor)
Datenbanken 1 Kapitel 7: Transaktionsmanagement 7-1 Transaktionsmanagement Inhalte des Kapitels Das Transaktionskonzept Konkurrierende Zugriffe und Sperren (Concurrency und Locking) JDBC Teil II: Transaktionsmanagement
Mehr