Modul 8 - Mehrbenutzerbetrieb Flashcards
Warum gibt es Mehrbenutzersynchronisation? Hat Mehrbenutzersynchronisation einen Preis?
Verlangsamung des Gesamtsystems, da in Wartezeiten CPU
Resourcen verschenkt werden
➔ Wesentlich höherer Durchsatz, da Resourcen besser ausgeschöpft werden
➔ Aber: Transaktionskontrolle nötig um Daten nicht gegenseitig zu korrumpieren
Warum ist eine Transaktionskontrolle bei der Mehrbenutzersynchronisation notwendig?
- Lost Update Problem: eine zweite TA überschreibt den Wert des Updates einer
ersten TA. Andere TAs sollen Wert der ersten TA lesen können - Dirty Read Problem: eine TA liest den Wert einer laufenden Transaktion, die
später mit einem Rollback abbricht - Incorrect Summary Problem: Während eine TA eine Summe über mehrere
Zeilen ausrechnet schreibt eine andere Transaktion Werte um
Wie wird Transaktionskontrolle sichergestellt?
durch die ACID Regeln, denen alle Transaktionen gehorchen
müssen
Atomizität – TA erscheint anderen TAs unsichtbar (atomar) , Abbrüche haben
keinerlei Effekt
Konsistenz - Jede TA hinterläßt die Datenbank in einem konsistenten Zustand
Isolation - TAs dürfen sich nicht gegenseitig beeinflussen, sondern müssen
isoliert ablaufen
Dauerhaftigkeit – Auch bei einem Programmabbruch oder Systemabsturz müssen
die Daten einer abgeschlossenen Transaktion erhalten bleiben.
Sperren (Locking) in DBMS
• Verschiedene Transaktionen fordern parallel Tupel an
• Je nach Zugriffsobjekt und Zugriffsart werden die Transaktionen
unterschiedlich abgehand
Was sind Zugriffsobjekte?
- Ganze Tabelle oder Index
- Mehrere Pages
- Eine Page
- Datensatz
Definition Locking Scheduler
• Überwacht Transaktionen
• Stellt sicher dass keine Dateninkonsistenzen entstehen
• Erhöht oder reduziert Lock Granularität
• Nutzt spezielle Locking Tabellen, die gelockte Objekte und Lockarten
enthalten
• Hält Transaktionen an bzw. gibt sie frei
• Wählt zwischen optimistischer und pessimistischer Transaktionskontrolle
(Concurrency Control)
o Optimistisch: Transaktion wird immer ausgeführt, erst bei Commit wird entschieden ob sie durchgeht oder
zurückgerollt wird
→ schnell, aber anfällig
→ wird nur bei wenigen Locks genutzt
o Pessimistisch: Erst wird geprüft ob Locks bestehen, nur bei Konfliktfreiheit startet Transaktion
→ langsamer aber sicherer
→ wird genutzt wenn häufige Konkurrenzsituationen entstehen
o Semi-optimistisch: abhängig von historischem Zugriff
Mehrbenutzersynchronisation durch 2 Phasen Sperrprotokoll
Zwei-Phasen-Sperrprotokoll in zentralisierten
Datenbanksystemen:
1. Jedes Objekt das benutzt werden soll, wird vorher gesperrt
2. Eine Sperre darf nicht zweimal angefordert werden
3. Eine Transaktion muss die Sperren anderer Transaktionen auf ein Objekt
beachten (siehe Verträglichkeitstabelle)
4. Jede Transaktion durchläuft zwei Phasen:
o Eine Wachstumsphase, in der sie Sperren anfordern, aber keine freigeben kann
o Eine Schrumpfungsphase, in der sie ihre bisher erworbenen Sperren freigibt, aber
keine weiteren anfordern darf
5. Bei Transaktionsende muss eine Transaktion alle ihre Sperren
zurückgeben
Problem bei 2PL?
Wenn T1 nach Schritt 10 ROLLBACK ausführt, hat T2 „Dirty
gelesen“!
➔ Gefahr „kaskadierender Rollback“!
➔Abhilfe: Strenges 2 PL
o alle Sperren werden auf einen Schlag erst zum Ende der Transaktion freigegeben
o Es gibt also keine Schrumpfungsphase mehr
o Ansonsten gelten die Bedingungen (1) bis (5) von 2PL
Was ist ein Deadlock?
Ein Deadlock beschreibt einen Zustand in einer Datenbanktransaktion bei der mindest eine Transaktionen von 2 parallel verlaufenden Transaktionen auf das gleiche Objekt schreibend zugreifen und beide der 2 parallel verlaufenden Transaktionen noch nicht abgeschlossen sind.
Wie wird ein Deadlock in VDBMS aufgelöst?
Drei Methoden für die Erkennung von Deadlocks in VDBMS:
- Timeout
- Zentrale Deadlock-Erkennung mit Wartegraphen
- Dezentrale (verteilte) Deadlock-Erkennung
Deadlock Erkennung durch Timeout Methode
- Timeout:
• Methode, die oft verwendet wird in VDBMS
• Nach Verstreichen eines festgelegten Zeitintervalls, in dem die Bearbeitung
einer Transaktion keinen Fortschritt gemacht hat, wird ein Deadlock
angenommen
• Eine betroffene Transaktion (siehe nächste Seite) wird zurückgesetzt und
später erneut gestartet
• Große Bedeutung: richtige Wahl des Timeout-Intervalls:
o Zu lange: schlechte Ausnutzung der Systemressourcen
o Zu kurz: Deadlock-Erkennung und Transaktionen werden zurückgesetzt, obwohl gar kein Deadlock vorlag
Entscheidung welche Transaktion zurückgesetzt wird
1. „Wound-Wait“: T1 älter als T2 → T2 wird zurück gerollt 2. „Wait-Die“: T1 älter als T2 → T1 wird zurück gerollt Wound-Wait: ältere Transaktionen bahnen sich ihren Weg durch das System Wait-Die: ältere Transaktionen verbringen mit zunehmendem Lebensalter immer mehr Zeit in Warteschlangen
Zentralisierte Deadlock-Erkennung
Zentralisierte Deadlock-Erkennung:
• Die Stationen melden lokal vorliegende Wartebeziehungen an einen
neutralen Knoten
• Der baut daraus einen globalen Wartegraphen auf
• Zyklus im Graphen -> Deadlock
• Nachteile:
o Hoher Aufwand (viele Nachrichten)
o Entstehung von Phantom-Deadlocks (=nicht-existierende Deadlocks) durch „Überholen“ von Nachrichten im
Kommunikationssystem:
• Z.B. Meldung zur Entfernung einer Wartebeziehung wird überholt von einer Meldung zum Neueintrag
einer Wartebeziehung
(verteilte) Deadlock-Erkennung
Dezentrale (verteilte) Deadlock-Erkennung:
• An den einzelnen Stationen werden lokale Wartegraphen geführt
• Damit lassen sich lokale Deadlocks aufdecken
• Zur Erkennung globaler Deadlocks:
o Jeder lokale Wartegraph hat einen Knoten External, der Stationen übergreifenden Wartebeziehungen zu
externen Subtransaktionen modelliert
o Jeder Transaktion wird ein Heimatknoten zugeordnet:
• Von wo aus sogenannte externe Subtransaktionen auf anderen Stationen initiiert werden
Fazit
• Transaktionen müssen den ACID Regeln folgen
• Sperren können DBMS lahmlegen
• Programmierer sollte darauf achten daß
o Transaktionen möglichst kurz laufen
o Langlaufende Lesezugriffe und einzelne Schreibzugriffe möglichst nicht in einer TA
o Vorsicht bei Aggregaten (können ganze Tabellen locken)
• OCC, PCC oder SCC hängen von der Transaktionsintensität auf „Hot Data“
ab
