Concurrency Flashcards

1
Q

Definition Concurrency

A
  • beschäftigt sich mit dem Parallelbetrieb in Datenbanken

- Sicherstellen, dass eine Transaktion Ergebnisse liefert, die unabhängig von anderen Transaktionen sind

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Grundregel Concurrency

A

Jede Transaktion läuft so ab, als sei allein im System

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

3 Concurrency Probleme

A

1) Problem der verlorengegangen Änderung
2) Problem der Abhängigkeit von nicht abgeschlossenen Transaktionen
3) Problem der Inkonsistenz der Daten

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Problem der verlorengegangenen Änderung

A

Zwei Transaktionen ändern (fast) gleichzeitig. Eine Änderung geht verloren.

  • grundsätzlich nicht erlaubt
  • großes Problem in verteilten Systemen, sehr kritisch
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Problem der Abhängigkeit von nicht abgeschlossenen Transaktionen

A

Daten werden gelesen, die mittels Rollback zurückgesetzt werden

  • sieht harmlos aus
  • Problem bei konsequenter Ausnutzung dieser Lücke
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Problem der Inkonsistenz der Daten

A

Fehlerhafte Daten werden gelesen, wenn andere Transaktionen gleichzeitig ändern
- sieht harmlos aus, aber mit falschen Werten wird intern weiter gearbeitet

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Konsequenz der 3 Probleme

A
  • alle drei Probleme sind zu vermeiden
  • Problem verlorengegangene Änderung sehr kritisch
  • Probleme Abhängigkeit und Inkonsistenz bei “harmlosen” Transaktionen vorstellbar (z.B. Sammeln von einfachen Statistiken)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Concurrency Strategie: optimistisch

A
  • jede TA darf beliebig lesen und ändern (Problem werden in Kauf genommen)
  • bei TA-Ende wird auf parallele Zugriffe überprüft
  • bei parallelem Zugriff: Rücksetzen und Neustart der TA
  • Realisierung mit Zugriffszähler
  • nur für sehr niedrige Kollisionswahrscheinlichkeit
  • Gegenseitiges Aufschaukeln: Ständige Neustarts
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Concurrency Strategie: pessimistisch

A
  • alle Daten bei einer TA sind für alle anderen TAs gesperrt
  • Freigabe der Sperre bei TA-Ende (Sperrmechanismen / Locks)
  • Andere TAs müssen ggf. warten
  • Einschränkung der Parallelität
  • hoher Verwaltungsaufwand für Sperrmechanismen
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Sperrmechanismen

A
  • werden mit Locks realisiert
  • zu jeder Relation existiert ein Lock
  • TA holt vor jedem Zugriff automatisch den Lock der zuzugreifenden Relation
  • wenn Lock von anderer TA belegt: TA wartet in Warteschlange auf Freigabe des Locks (Serialisierung)
  • bei TA-Ende werden alle gehaltenen Locks freigegeben
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Sperrgranulate

A

1) Datenbanksperre (kein Parallelbetrieb, nur für Einzelbetrieb)
2) Tabellensperre (flexible, bei geringer Parallelität gut einsetzbar, aber: intensiver Zugriff auf einzelne Tabellen)
3) Eintragssperren (enorm aufwändig, daher kaum implementiert)
4) Tupelsperren (Standard in größeren Datenbanken, aber sehr viele Locks (Tabellen * Zeilen))

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Implementierung von Sperren

A
  • Lockpool mit Poolverwaltung

- Locks werden bei Bedarf eingerichtet

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Lesende Zugriffe und Concurrency

A
  • in Praxis: 80 - 90% Lesezugriffe (sollen sich nicht gegenseitig behindern)
  • Lesende dürfen Änderungen vor Commit der TA NICHT lesen
  • Schreibende dürfen Daten NICHT ändern, wenn vorher von anderen gelesen (Inkonsistenz der Daten)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Exklusiv-Lock

A

Exklusiv-Lock auf ein Objekt weist alle weiteren Exklusiv- und Share-Lockanforderungen auf dieses Objekt zurück

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Share-Lock

A

Ein Share-Lock auf ein Objekt gestattet weitere Share-Lockzugriffe auf dieses Objekt, weist aber exklusive Lockanforderungen zurück

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Sperren in Datenbanken: vor Lesezugriff

A
  • automatisches Anfordern eines Share-Locks

- TA erhält Share-Lock, wenn es keine anderen Exklusiv-Lock-Anforderungen anderer Transaktionen gibt

17
Q

Sperren in Datenbanken: vor Schreibzugriff

A
  • automatisches Anfordern eines Exklusiv-Locks
  • TA erhält Exklusiv-Lock, wenn es keine anderen Share- oder Exklusiv-Lock-Anforderungen gibt
  • hält die TA bereits Share-Lock, so wird dieser (sobald verfügbar) in Exklusiv-Lock umgewandelt
18
Q

Definition Deadlock

A

Verklemmung, bei der mindestens zwei Transaktionen gegenseitig auf die Freigabe eines oder mehrerer Locks warten

  • Lesende behindern Schreibende und umgekehrt
  • Deadlocks können auch zwischen Lesenden und Schreibenden auftreten
19
Q

Deadlockvermeidung

A
  • anfordern von Locks in vorgegebener Reihenfolge (z.B. Relationen und Tupel alphabetisch oder nach Primärschlüssel geordnet) –> Zugriff gemäß Ordnung
  • aber: zu Transaktionsbeginn nicht immer alle nötigen Tupel bekannt
20
Q

Deadlock-Erkennung

A
  • Wartezeiten-Prinzip hat Schwächen (Abbrechen “unschuldiger” TAs und verlängern der Antwortzeiten
  • besser: Erkennen mittels Wartegraphen (Pfeil bei wartenden Transaktionen
  • Wartegraph ist Standard moderner Datenbanken (geringer Implementierungsaufwand)
21
Q

Deadlockauflösung

A
  • SQL-Norm: Fehlermeldung SQLSTATE: 4000I

- Zurücksetzen und Neustarten der Transaktion, um durch Freigabe aller Locks die Verklemmung aufzulösen

22
Q

Endergebnis: Probleme der Concurrency

A
  • Problem lassen sich lösen durch Exklusiv- und Share-Locks, Lockerkennung, Rücksetzen und Neustarten der TA
  • bei Deadlockfehlermeldung: TA zurücksetzen und ggf. neu starten
  • Wiederholen eines DB-Zugriffs im Deadlockfall führt sofort wieder zum Deadlock