Kapitel 10
Download
1 / 25

Kapitel 10 - PowerPoint PPT Presentation


  • 92 Views
  • Uploaded on

Kapitel 10. Transaktionsverwaltung. Lernziele. . Begriff und Eigenschaften von Transaktionen Mehrbenutzer-Synchronisation Theorie der Serialisierbarkeit Zwei-Phasen-Sperrprotokolle Deadlocks und deren Vermeidung. Transaktionsverwaltung. .

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Kapitel 10' - lucius-lancaster


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Kapitel 10

Kapitel 10

Transaktionsverwaltung


Lernziele
Lernziele

  • Begriff und Eigenschaften von Transaktionen

  • Mehrbenutzer-Synchronisation

    • Theorie der Serialisierbarkeit

    • Zwei-Phasen-Sperrprotokolle

    • Deadlocks und deren Vermeidung

Datenbanken, SS 12 Kapitel 10: Transaktionsverwaltung


Transaktionsverwaltung
Transaktionsverwaltung

Beispiel einer typischen Transaktion in einer Bankanwendung:

  • Lese den Kontostand von A in die Variable a : read(A,a);

  • Reduziere den Kontostand um 50 EUR: a:= a – 50;

  • Schreibe den neuen Kontostand in die Datenbasis: write(A,a);

  • Lese den Kontostand von B in die Variable b: read(B,b);

  • Erhöhe den Kontostand um 50 EUR: b := b + 50;

  • Schreibe den neuen Kontostand in die Datenbasis: write(B, b);

Datenbanken, SS 12 Kapitel 10: Transaktionsverwaltung


Fehler bei unkontrolliertem mehrbenutzerbetrieb
Fehler bei unkontrolliertem Mehrbenutzerbetrieb

Schritt

T1

T2

1.

read(A,a1)

2.

a1 := a1 – 300

3.

read(A,a2)

4.

a2:= a2 * 1.03

5.

write(A,a2)

6.

write(A,a1)

7.

read(B,b1)

8.

b1 := b1 + 300

9.

write(B,b1)

Verlorengegangene Änderungen (lost update)

Überweisung

Zinsen

Datenbanken, SS 12 Kapitel 10: Transaktionsverwaltung


Operationen auf transaktions ebene
Operationen auf Transaktions-Ebene

In den klassischen Transaktionssystemen:

  • beginoftransaction(BOT): Mit diesem Befehl wird der Beginn einer eine Transaktion darstellende Befehlsfolge gekennzeichnet.

  • commit: Hierdurch wird die Beendigung der Transaktion eingeleitet. Alle Änderungen der Datenbasis werden durch diesen Befehl festgeschrieben, d.h. sie werden dauerhaft in die Datenbank eingebaut.

  • abort: Dieser Befehl führt zu einem Selbstabbruch der Transaktion. Das Datenbanksystem muss sicherstellen, dass die Datenbasis wieder in den Zustand zurückgesetzt wird, der vor Beginn der Transaktionsausführung existierte.

Datenbanken, SS 12 Kapitel 10: Transaktionsverwaltung


Abschluss einer transaktion
Abschluss einer Transaktion

Für den Abschluss einer Transaktion gibt es zweiMöglichkeiten:

  • Den erfolgreichen Abschluss durch ein commit.

  • Den erfolglosen Abschluss durch ein abort.

Datenbanken, SS 12 Kapitel 10: Transaktionsverwaltung


Eigenschaften von transaktionen acid
Eigenschaften von Transaktionen: ACID

  • Atomicity (Atomarität)

    Alles oder nichts !

Consistency

Konsistenter DB-Zustand muss in konsistenten Zustand übergehen !

Isolation

Jede Transaktion hat die DB „für sich allein“

Durability (Dauerhaftigkeit)

Änderungen erfolgreicher Transaktionen dürfen nie verloren gehen

Datenbanken, SS 12 Kapitel 10: Transaktionsverwaltung


Transaktionsverwaltung in sql
Transaktionsverwaltung in SQL

  • commitwork

  • Die in der Transaktion vollzogenen Änderungen werden – falls keine Konsistenzverletzung oder andere Probleme aufgedeckt werden – festgeschrieben.

  • Schlüsselwort work ist optional

  • rollbackwork

  • Alle Änderungen sollen zurückgesetzt werden.

  • Anders als der commit-Befehl muss das DBMS die „erfolgreiche“ Ausführung eines rollback-Befehls immer garantieren können.

Datenbanken, SS 12 Kapitel 10: Transaktionsverwaltung


Transaktionsverwaltung in sql1
Transaktionsverwaltung in SQL

Beispielsequenz auf Basis des Universitätsschemas:

INSERTINTO Vorlesungen

values (5275, 'Kernphysik', 3, 2141);

INSERTINTO Professoren

values (2141, 'Meitner', 'C4', 205);

COMMIT

Datenbanken, SS 12 Kapitel 10: Transaktionsverwaltung


Fehler bei unkontrolliertem mehrbenutzerbetrieb1
Fehler bei unkontrolliertem Mehrbenutzerbetrieb

Schritt

T1

T2

1.

read(A,a1)

2.

a1 := a1 – 300

3.

read(A,a2)

4.

a2:= a2 * 1.03

5.

write(A,a2)

6.

write(A,a1)

7.

read(B,b1)

8.

b1 := b1 + 300

9.

write(B,b1)

Verlorengegangene Änderungen (lost update)

Überweisung

Zinsen

Datenbanken, SS 12 Kapitel 10: Transaktionsverwaltung


Fehler bei unkontrolliertem mehrbenutzerbetrieb ii
Fehler bei unkontrolliertem Mehrbenutzerbetrieb II

Schritt

T1

T2

1.

2.

a1 := a1 – 300

3.

write(A,a1)

4.

read(A,a2)

5.

a2 := a2 * 1.03

6.

write(A,a2)

7.

read(B,b1)

8.

. . .

9.

abort

Abhängigkeit von nicht freigegebenen Änderungen

read(A,a1)

Datenbanken, SS 12 Kapitel 10: Transaktionsverwaltung


Fehler bei unkontrolliertem mehrbenutzerbetrieb iii
Fehler bei unkontrolliertem Mehrbenutzerbetrieb III

Phantomproblem

Datenbanken, SS 12 Kapitel 10: Transaktionsverwaltung


Der datenbank scheduler
Der Datenbank-Scheduler

T1

T2

T3

......

Tn

Daten-Manager

Recovery-Manager

Puffer-Manager

Datenbank

Transaktions-Manager TM

Scheduler

Datenbanken, SS 12 Kapitel 10: Transaktionsverwaltung


Aufgabe des schedulers
Aufgabe des Schedulers

  • Reihung der Operationen verschiedener Transaktionen, so dass die einzelnen Transaktionen

    • Bis zuletzt ohne kaskadierendes Rollback rücksetzbar sind (Atomicity)

    • Keine ungültigen Datenzustände erzeugen können (Consistency)

    • Die Parallelität zu anderen Transaktionen nicht bemerken (Isolation)

    • Committete Änderungen dauerhaft vorliegen (Durability)

  • Verschiedene Ansätze möglich:

    • sperrbasierte Synchronisation (am meisten benutzt)

    • Zeitstempel-basierte Synchronisation

    • optimistische Synchronisation (bei vorwiegend lesenden Zugriffen)

Pessimistische Synchronisation

Datenbanken, SS 12 Kapitel 10: Transaktionsverwaltung


Sperrbasierte synchronisation
Sperrbasierte Synchronisation

  • Sichert Serialisierbarkeit zu

  • Zwei Sperrmodi

    • S (shared, read lock, Lesesperre):

    • X (exclusive, write lock, Schreibsperre):

    • Verträglichkeitsmatrix (auch Kompatibilitätsmatrix genannt)

Datenbanken, SS 12 Kapitel 10: Transaktionsverwaltung


Zwei phasen sperrprotokoll 2pl definition
Zwei-Phasen-Sperrprotokoll (2PL): 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.

Datenbanken, SS 12 Kapitel 10: Transaktionsverwaltung


Zwei phasen sperrprotokoll grafik
Zwei-Phasen Sperrprotokoll: Grafik

#Sperren

Wachstum

Schrumpfung

Zeit

Datenbanken, SS 12 Kapitel 10: Transaktionsverwaltung


Verzahnung zweier tas gem 2pl
Verzahnung zweier TAs gemäß 2PL

  • T1 modifiziert nacheinander die Datenobjekte A und B(z.B. eine Überweisung)

  • T2 liest nacheinander dieselben Datenobjekte A und B(z.B. zur Aufsummierung der beiden Kontostände).

Datenbanken, SS 12 Kapitel 10: Transaktionsverwaltung


Verzahnung zweier tas gem 2pl1
Verzahnung zweier TAs gemäß 2PL

Datenbanken, SS 12 Kapitel 10: Transaktionsverwaltung


Strenges zwei phasen sperrprotokoll
Strenges Zwei-Phasen 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

    • Verhindert allerdings keine Deadlocks

#Sperren

Wachstumsphase

Zeit

EOT

Datenbanken, SS 12 Kapitel 10: Transaktionsverwaltung


Verklemmungen deadlocks
Verklemmungen (Deadlocks)

Ein verklemmter Schedule

Datenbanken, SS 12 Kapitel 10: Transaktionsverwaltung


Verklemmungen
Verklemmungen

  • a: können entdeckt und dann aufgelöst

  • b: oder gleich vermieden werden.

    Beides ist u.U. teuer. Mögliche Techniken:

    Ad a:

    1. Time-Out (Transaktionen, die zu lange warten, werden abortet)

    2. Zyklenerkennung (Es wird parallel analysiert wer auf wen wartet und dann intelligent und gezielt abortet)

    Ad b:

    3. Preclaiming (Transaktion setzen alle Locks gleich Anfang)

    4. Zeitstempel (Man wartet nicht auf jüngere Transaktionen)

Datenbanken, SS 12 Kapitel 10: Transaktionsverwaltung


Deadlocks sind fatal f r die performance
Deadlocks sind fatal für die Performance

Umso mehr Transaktionen pro Zeit stattfinden umso höher ist die Wahrscheinlichkeit, dass zwei sich gegenseitig locken

Umso aufwändiger ist die Deadlockbehandlung

Umso langsamer wird das System -> bis zum Stillstand (ungraceful failure)

Ressourcen

#Transaktionen pro Zeit

Datenbanken, SS 12 Kapitel 10: Transaktionsverwaltung


Transaktionspuffer
Transaktionspuffer

Es werden nicht mehr Transaktionen gleichzeitig ausgeführt als das System verkraften kann.

Der Preis sind verschiedene Limitierungen:

  • Bei Überlast werden zunächst Transaktionen später begonnen,

  • dann werden Transaktionen direkt abgewiesen

  • Transaktionen, die zu lange dauern, werden abgebrochen

Ressourcen

#Transaktionen pro Zeit

Datenbanken, SS 12 Kapitel 10: Transaktionsverwaltung


Fazit
Fazit

  • Bei Mehrbenutzerbetrieb kann es zu Fehlern kommen

  • Um das zu vermeiden gibt es Transaktionen

  • Transaktionen gehorchen dem ACID Prinzip

  • Diese werden von der Datenbank mit Hilfe von Locks realisiert

  • Locks können zu Deadlocks führen

  • Diese müssen erst aufgelöst werden (z.B. mit Zeitstempeln)

  • Trotzdem ist das schlecht für die Performanz

  • -> die meisten Datenbanken sind daher sehr konservativ

Datenbanken, SS 12 Kapitel 10: Transaktionsverwaltung


ad