02 Concurrency und Recovery Flashcards
Was bedeutet ACID und was versteht man darunter?
• Atomarity (Atomarität)
Jede Transaktion - bestehend aus ihren Teilaktionen - wird als logische Einheit ”atomar“ ausgeführt. Dass bedeutet, dass entweder alle ihre Teilaktionen komplett ausgeführt werden oder überhaupt keine Teilaktion ausgeführt wird.
• Consistency (Konsistenz)
Die Daten der Datenbank befinden sich jederzeit in einem konsistenten Zustand. Dazu gehören
das Einhalten des zu Beginn festgelegten Datenbankschemas sowie die Berucksichtigung von
Primär- und Fremdschlusseln. Eine Transaktion überführt eine Datenbank von einem konsistenten Zustand in einen neuen konsistenten Zustand.
• Isolation (Isolation)
Parallel laufende Transaktionen beeinflussen sich (während ihrer Ausfuhrung) nicht gegenseitig.
• Durability (Dauerhaftigkeit)
Der Stand der Daten nach Ende einer Transaktion wird dauerhaft gespeichert (bis zu einer
eventuell nächsten Transaktion, die die Daten erneut verändert).
Wie verhalten sich relationale Datenbankmanagementsysteme bezuglich der ACID Eigenschaften?
Relationale Datenbankmanagementsysteme erfüllen die vier ACID-Eigenschaften
Was versteht man unter einer Transaktion?
Eine Transaktion fasst einen oder mehrere Datenbankbefehle zu einer logischen Einheit zusammen. Man möchte gemäß ”A-Eigenschaft“ (Atomarity - Atomarität) erreichen, dass entweder alle
Teilaktionen der Transaktion ausgeführt werden oder überhaupt keine Teilaktion.
Auf welche beiden Arten kann eine Transaktion beendet werden?
- COMMIT: erfolgreicher Abschluss der Transaktion ⇒ neuer konsistenter Zustand
- ROLLBACK: Abbruch der Transaktion ⇒ bisheriger konsistenter Zustand soll weiter gelten
Nennen Sie ein Beispiel fur ein Szenario, in dem der Einsatz von Transaktionen erforderlich ist!
- Überweisung von A nach B: Abbuchung von einem Konto und Gutschrift auf anderes Konto
- Reservierung mehrerer Kinositze für Gruppe: jeweils Reservierung der einzelnen Sitze
- Buchung Anschlussfluge: jeweils Buchung der einzelnen Teilstrecken
Skizzieren Sie die wichtigsten Bestandteile eines Datenbankmanagementsystems und die dort im Hintergrund ausgeführten Schritte beim Lesen aus bzw. Schreiben in eine Datenbank!
Lesen von Daten
- Falls die gewünschten Daten schon im Datenbank-Puffer vorhanden sind, werden sie von dort ¨
gelesen. (L1) - Andernfalls werden sie aus dem dauerhaften Speicher gelesen und in den Datenbank-Puffer
geschrieben. (L2)
Schreiben von Daten
- Die Daten werden im Datenbank-Puffer geändert. (S1)
- Die Änderungen werden in den Log-Dateien vermerkt. (S2) ¨
- Zu einem späteren Zeitpunkt werden die Änderungen in den dauerhaften Speicher zurückgeschrieben. (S3)
Was passiert im Detail beim Ändern von Daten?
- Der vorherige Stand der Daten (Before-Image) wird im Undo-Log (Teil der Log-Dateien)
gespeichert. - Die Änderungen der Daten werden im Datenbank-Puffer durchgeführt.
- Der neue Stand der Daten (After-Image) wird im Redo-Log (Teil der Log-Dateien) gespeichert.
- Zu einem späteren Zeitpunkt (spätestens beim nächsten Checkpoint) werden die Änderungen
auf den dauerhaften Speicher zurückgeschrieben. - beim Transaktionsende:
• Transaktionsende mit Commit:
(a) Das Before-Image der Transaktion wird aus dem Undo-Log gelöscht.
(b) Das After-Image der Transaktion wird im Redo-Log als ”dauerhaft“ markiert.
• Transaktionsende mit Rollback:
(a) Das Before-Image der Transaktion wird im Datenbank-Puffer aus dem Undo-Log wiederhergestellt.
(b) Falls Änderungen bereits auf den dauerhaften Speicher zurückgeschrieben wurden,
wird auch hier das Before-Image aus dem Undo-Log wiederhergestellt.
(c) Das Before-Image der Transaktion wird aus dem Undo-Log gelöscht.
(d) Das After-Image der Transaktion wird aus dem Redo-Log gelöscht.
Wie kann der letzte (konsistente) Stand der Daten nach einem Ausfall des Datenbankmanagementsystems wieder hergestellt werden?
- Stand des aktuellsten Backups einspielen
- alle Eintrage aus
dem Redo-Log, die als “dauerhaft“ markiert sind, Schritt für Schritt erneut ausführen
Was ist die Idee von Sperren in Datenbankmanagementsystemen? Erläutern Sie deren Funktionsweise!
Der Zugriff auf eine Ressource wird jeweils durch eine Sperre (”Zugriffsrecht“) geregelt. Vor Benutzung einer Ressource benötigt eine Transaktion die entsprechende Sperre (und damit das
zugehörige ”Zugriffsrecht“). Beim Anfragen einer Sperre durch eine Transaktion kann es zu folgenden
zwei Fällen kommen:
• Falls die Sperre noch frei ist, bekommt die anfragende Transaktion die Sperre zugeteilt und
kann die entsprechende Ressource nun nutzen.
• Falls die Sperre schon an eine andere Transaktion vergeben ist, kommt die anfragende Transaktion in die Warteschlange der Sperre und kann so lange nicht fortfahren, bis sie die Sperre
zugeteilt bekommt.
Bei ihrem Transaktionsende gibt eine Transaktion alle von ihr gehaltenen Sperren wieder frei. Falls
sich Transaktionen in den zugehörigen Warteschlangen der freigegebenen Sperren befinden, bekommt
pro Warteschlange die jeweils ”
erste“ (d. h. die am längsten in der Warteschlange befindliche) Transaktion die entsprechende Sperre als nächstes zugeteilt.
Was versteht man unter der Granularität von Sperren in Datenbankmanagementsystemen?
Warum ist die verwendete Granularität für den praktischen Einsatz von Bedeutung?
Unter Granularität einer Sperre versteht man, was man als eine Ressource versteht, die jeweils
durch eine Sperre
“geschützt“ wird.
Beispiele:
• komplette Datenbank
• je Datenbanktabelle
• je Datenbank Tupel (”
Zeile“ einer Datenbanktabelle)
• je Attribut eines Datenbank Tupels (”
Zelle“ einer Datenbanktabelle)
Je weniger Sperren (niedrige Granularität) existieren, desto weniger zusätzlicher Verwaltungsaufwand
für die Sperren ist notwendig. ¨
Je mehr Sperren (hohe Granularität) existieren, desto weniger Transaktionen ”
behindern“ sich gegenseitig bei der Ausführung, da sie dieselbe Sperre benötigen.
Somit gibt es mehr Parallelität bei der Ausführung der Transaktionen und diese sind tendenziell schneller ausgeführt.
In der heutigen Praxis werden meist Sperren auf der Ebene der einzelnen Datenbank Tupel verwendet.
Was ist die zusätzliche Idee von Share-Locks und Exclusiv-Locks? Erläutern Sie deren Funktionsweise
Vorbemerkung: Das parallele Lesen einer Ressource durch zwei Transaktionen verursacht keine
Probleme.
Ziel: möglichst hohe Parallelität
Konsequenz: Es werden zwei Arten von Sperren pro Ressource verwendet:
• Share-Locks fürs Lesen und ¨
• Exclusiv-Locks fürs Schreiben. ¨
Funktionsweise:
• Lesen einer Ressource:
1. Für das Lesen einer Ressource wird ihr Share-Lock (oder Exclusiv-Lock) benötigt.
2. Hält eine Transaktion bereits die benötigte Sperre, kann sie mit dem Lesen fortfahren.
3. Andernfalls muss die Transaktion den Share-Lock für die Ressource anfragen. ¨
– Falls keine andere Transaktion den Exclusiv-Lock der Ressource hält, bekommt die
anfragende Transaktion den Share-Lock zugeteilt.
– Falls eine andere Transaktion den Exclusiv-Lock der Ressource hält, kommt die
anfragende Transaktion in die Warteschlange des Share-Locks und kann so lange
nicht fortfahren, bis sie den Share-Lock zugeteilt bekommt.
• Schreiben einer Ressource:
1. Für das Lesen einer Ressource wird ihr Exclusiv-Lock benötigt.
2. Hält eine Transaktion bereits die benötigte Sperre, kann sie mit dem Schreiben fortfahren.
3. Andernfalls muss die Transaktion den Exclusiv-Lock für die Ressource anfragen.
– Falls keine andere Transaktion den Share-Lock oder Exclusiv-Lock der Ressource
h¨alt, bekommt die anfragende Transaktion den Exclusiv-Lock zugeteilt.
– Falls eine andere Transaktion den Share-Lock oder Exclusiv-Lock der Ressource hält,
kommt die anfragende Transaktion in die Warteschlange des Exclusiv-Locks und kann
so lange nicht fortfahren, bis sie den Exclusiv-Lock zugeteilt bekommt.
• Freigabe der Sperren beim Transaktionsende:
Bei ihrem Transaktionsende gibt eine Transaktion alle von ihr gehaltenen Sperren (Share-Locks
und Exclusiv-Locks) wieder frei. Falls sich Transaktionen in den zugehörigen Warteschlangen
der freigegebenen Sperren befinden, bekommt pro Warteschlange die jeweils ”
erste“ (d. h.
die am längsten in der Warteschlange befindliche) Transaktion die entsprechende Sperre als
nächstes zugeteilt.
Was versteht man unter einem Deadlock (im Zusammenhang mit einem Datenbankmanagementsystem)?
Mindestens zwei Transaktionen warten auf die Freigabe einer Sperre, die aktuell jeweils die andere Transaktion hält. Da alle beteiligten Transaktionen warten müssen, kann auch keine ihre Sperre, ¨
an der eine andere Transaktion Bedarf hat, freigeben. Die Konsequenz ist dauerhafter Stillstand der
am Deadlock beteiligten Transaktionen.
Auf Deutsch spricht man auch von einer Verklemmung.
Wie kann ein Deadlock mit Hilfe eines Wartegraphen erkannt werden?
Ein Wartegraph besteht aus Knoten und gerichteten Kanten. Die Knoten repräsentieren Transaktionen. Eine gerichtete Kante (=Pfeil) von Knoten 1 zu Knoten 2 bedeutet, dass die von Knoten 1
repräsentierte Transaktion 1 auf die Freigabe einer Sperre wartet, die aktuell die von Knoten 2 repräsentierte Transaktion 2 hält.
Skizze: TA1 zeigt auf TA2
Das DBMS hält den Wartegraphen im Hintergrund immer aktuell.
Falls ein Wartegraph einen Zyklus (d. h. einen Pfad beginnend bei einem Knoten, sodass man am
Schluss wieder bei diesem Knoten ankommt) enthält, dann existiert ein Deadlock.
Skizze: TA1 zeigt auf TA2 und umgekehrt
Was kann man bei einem erkannten Deadlock unternehmen, um diesen
“aufzulösen”?
Eine am Deadlock (d. h. am Zyklus) beteiligte Transaktion wird mit ROLLBACK abgebrochen.
Dadurch ist diese Verklemmung aufgel¨ost und die restlichen Transaktionen k¨onnen nun fortfahren.
Die abgebrochene Transaktion kann zu einem sp¨ateren Zeitpunkt ggf. neu gestartet werden
