Kapitel 9 - Scheduler und Recovery
|
Inhalt
|
- Was sind Sperrprotokolle und wie funktionieren sie?
- Wie arbeiten sperrende Scheduler?
- Was sind Deadlocks und warum und wie können diese entstehen?
- Welche Varianten des Zwei-Phasen-Sperren gibt es?
- Worin unterscheiden sich pessimistische und optimistische Scheduler?
- Wie funktioniert Recovery?
|
Wie funktioniert das Sperren bei Datenbanken?
Verwaltet werden Sperren durch den Lock-Manager.
Lock a=Objekt wird angefordert und unlock a=Objekt wird freigegeben.
Alle Locks werden in einer Sperrtabelle eingetragen.
Sperrprotokoll: Wie müssen Sperren gesetzt und freigegeben werden, damit serialisierbare Schedules entstehen? (Zwei-Phasen-Sperrprotokoll)
Welche Sperrmodi gibt es?
Welche Arten von Sperren benötigt man?
- Shared-Lock
- Exclusive-Lock
- Intendierter Lock (Intention Lock - alles "darunter" ist in Speicherhierarchie auch gesperrt)
- 'kurze Sperre'
Welches sind die sperrbaren Einheiten in einer Datenbank?
- Databaselock
- Tablelock
- Datasetlock
- darüber hinaus noch Arealock um Teile einer Datenbank zu Sperren
Sperrhierarchie: Datenbank - Area - Tabelle - Tupel/Seite (Lock-Escalation)
Deadlock-Behandlung (tritt bei exklusiven Sperren auf) wobei Schedules wechselweise auf Freigabe einer Sperreinheit warten
Livelock: durch wiederholt ungünstige Zuteilung von Sperren kann eine Transaktion permanent blockiert werden.
Was sind sperrende Scheduler?
Bei Sperrenden Schedulern werden so genannte Locks verwendet, um den Zugriff auf gemeinsam genutzte Daten zu synchronisieren.
Eine gesetzte Sperre bedeutet, daß das Objekt für andere nicht verfügbar ist.
Ein sperrender Scheduler unterscheidet zwischen:
- Read lock
- Write lock
- Read unlock
- Write unlock
Welche Regeln gelten bei sperrenden Schedulern?
- falls im Schedule irgendwo ein Read (oder Write) auftritt, so gibt es vor diesem im Schedule ein Lock und irgendwo nach diesem ein Unlock
- Für jedes Read (oder Write) gibt es genau ein Lock und ein Unlock und nicht mehr
- read unlocks und write unlocks sind nicht redundant
Durch das exlkusive Sperren von Ojekten entsteht die Gefahr von Deadlocks. Desweiteren ist das Permanente Blockieren
von Objekten möglich, wenn die Sperren ungünstig zugeteilt werden.
Wie arbeitet das 2-Phasen-Sperren?
Ein Scheduler ist ein 2PL Scheduler, wenn
- er die oben erwähnten drei Regeln einhält
- ist x durch zwei verschiedene Transaktionen gesperrt, so stehen diese nicht in Konflikt
- ein Sperrprotokoll hat zwei Phasen, wenn nach dem ersten Unlock-Schritt, keine weiteren Locks folgen können
Somit ist genau nach den ersten Unlock Phase 1 (das Sperren) beendet und Phase 2 begonnen.
Falls ein Objekt mit einer Lese-Sperre versehen wurde, so ist es nicht exklusiv gesperrt, sondern im shared mode.
Somit können andere Objekte auch Lese-Sperren auf das Objekt referenzieren.
Falls das Objekt mit einer Schreib-Sperre versehen wurde, so ist es im exclusive mode, d.h. exklusiv gesperrt.
Somit können keine anderen Transaktionen Lese- oder Schreib-Sperren auf das Ojekt referenzieren.
Varianten des 2PL
Conservative two-phase-locking C2PL (statisches 2PL) = Was ist Preclaiming?
Jede Transaktion setzt zu Begin ihrer Ausführung (BOT) alle Sprerren gleichzeitig. Nachteil dieses Verfahren ist es,
daß alle Read- und Write-Sets vorher bekannt sein müssen. Dazukommt, daß falls ein Konflikt mit einer Sprerre Auftritt, die
gesamte Transaktion warten muß, bis diese durch das Unlock der anderen Transaktion aufgelöst wird.
Da dies selten der Fall ist, wird es wenig benutzt. Der Vorteil ist hier aber, daß Deadlocks umgangen werden, da diese nicht auftreten
können.
Das Preclaiming wird kaum implementiert.
Strict two-phase-locking S2PL (dynamisches 2PL/Sperren bis EOT)
Alle gehaltenen Sperren einer Transaktion werden erst nach ihrem letzten Schritt aufgelöst. Dieses Verfahren ist von
großer Bedeutung, da es ein isoliertes Rücksetzen von Transaktionen garantiert. D.h. im weiteren, daß eine Transaktion
isoliert rückgesetzt werden kann, um danach wieder neu gestartet zu werden, ohne das andere Transaktionen beeinflußt werden.
(ACID)
Warum wird in der Praxis fast immer das strenge 2PL verwendet?
Man stelle sich zwei Transaktionen T1 und T2 vor. Das normale 2PL hätte bei folgendem Ablauf einige Probleme:
- T1 sperrt das Objekt A (lock(T1,A))
- T1 gibt A wieder freu
- nun sperrt T2 das Objekt A
- Die Transaktion T2 wird beendet (commit(T1))
- Das Beenden (commit) von T1 schlägt fehl
- Somit muss T1 zurückgesetzt werden
- T2 muss aber auch zurückgesetzt werden, da es das Objekt A auch verwendet hat (Dominoeffekt)
- T2 wird zurückgesetzt obwohl es bereits commited war! (wiederspricht ACID Prinzip: Dauerhaftigkeit)
Deshalb wird das strenge 2PL verwendet, weil hier dieser Ablauf gar nicht erst stattfinden kann. T1 würde die Sperre
auf das Objekt A bis zum Schluss halten, bevor T1 commited wird. Erst dann kann T2 das Objekt A sperren. Ein eventuelles
Rücksetzen von T1 durch das Recovery hätte somit keine weiteren Folgen (kein Dominoeffekt möglich).
Wie können sperrende Scheduler getuned werden?
- Entfernen unnötiger Sperren
- Zerlegen langer Transaktionen in mehrere kurze
- spezielle Techniken für lange Reads (Read Only keine Sperren weil Backup dieser)
- sinnvolle Granularität = Feinheitsgrad (Record-Level, Page oder Table Locking)
- Schema Updates bei geringer Aktivität durchführen (System Katalog wird zum Flaschenhals)
- Deadlock Intervall bei 2PL (Zylisch Wartegraphen auf Zyklen untersuchen)
Wie arbeiten Zeitstempel-Verfahren?
Dieses Verfahren soll von vornherein verhindern,
dass Deadlocks entstehen können. Anstelle von Sperren, wird eine Transaktion mit einer drohenden Verletzung der
Serialisierbarkeitskriterien abgebrochen und neu gestartet. Es gelten folgende Regeln:
- Eine Leseoperation kann nur ausgeführt werden, wenn ihre Zeitmarke jünger ist als die des letztes Schreibers.
- Eine Schreiboperation darf nur ausgeführt werden, wenn kein jüngerer Leser und kein jüngerer Schreiber auf das
Objekt zugegriffen haben.
Wie arbeiten optimistische Verfahren?
Die Transaktionen arbeiten völlig ohne Synchronistation.
Erst bei einem Commit wird der Abhängigkeitsgraph auf Serialisierbarkeit (=Zyklusfreiheit) geprüft.
Falls Zyklen auftreten, wird die Transaktion abgebrochen.
Implementation:
- Aufteilung der Transaktion in drei Phasen (Lese-, Validierungs- und Schreibphase)
- In Validierungsphase wird Serialisierbarkeit geprüft
- Transaktionen müssen kostengünstig Rücksetzbar sein
- Verhindern von Livelocks (setes Wiederstarten nicht serialisierbarer Transaktionen)
Vorteile
- keine Deadlocks möglich da kein exklusives Sperren
- der Aufwand für das Führen von Sperrtabellen (Lock-Manager) entfällt völlig
- reine Lesetransaktionen können niemals behindert werden
Beschreiben Sie die drei Phasen der optimisitischen Verfahren!
1.Phase: Lesen & Verarbeiten
Aus Anwendungssicht ist dies die "eigentliche" Transaktion. Es werden alle benötigten Objekte gelesen und in einem
gesicherten (isolierten!) Buffer hinterlegt. Die Verarbeitung der Objekte findet nun ausschließlich
in diesem Bereich statt. So bleiben die Transaktionen für andere Prozesse vorerst unsichtbar.
2.Phase: Validierung der Ergebnisse
Nach dem Ende der Lesephase wird nun geprüft, ob die beteiligten Transaktionen mit Transaktionen parallel laufender
Prozesse in Konflikt geraten ist. Ist dies der Fall wird die Transaktion einfach abgebrochen. Da alle Transaktionen
in einem gesicherten Bereich liegen, brauch dieser also nur wieder zur "Wiederverwendung" freigegeben zu werden.
3.Phase: Rückschreiben auf Datenbank
War die Validierung erfolgreich werden alle Transaktionen aus dem Buffer in die Datenbank zurückgeschrieben. Die Transaktion
ist hiermit beendet. (commited)
Wie funktioniert das Validieren genau?
Schritt 1:
Allen Transaktionen wird beim Eintritt in die Validierungsphase
eine Serialisierungsnummer zugewiesen.
Es wird für jede beteiligte Transaktion geloggt, welche anderen Transaktionen in der Lesephase beendet werden. Über die
von diesen Transaktionen geschriebenen Objekte wird Buch geführt.
Schritt 2:
Für alle Transaktionen die während der Lesephase dieser Transaktion beendet wurden, wird geprüft ob die Lesemenge geich
der Schreibmenge ist. Sind die Mengen ungleich, so wird abgebrochen.
Können bei optimistischen Verfahren Deadlocks entstehen?
Nein, denn ohne Sperren (exlusiver Betriebsmittelentzug) können keine Deadlocks entstehen!
Was ist mit Deadlocks bei Schedules?
Das 2-PL ist nicht Deadlock frei. Erklärung dafür ist, daß Locks sich gegenseitig blockieren können, aufgrund der Vorbedingung,
daß ein exklusiv gesperrtes Objekt, nicht mehrfach reserviert werden kann. Einmal im Deadlock, kann man ihn nicht einfach durch
ein Unlock auflösen, da dann ja die nicht aufgerufenen Locks nicht mehr in Kraft treten könnten.
Eine weitere Situation, wo Deadlocks entstehen können, sind Lock-Konvertions. Updaten 2 Transaktionen gleichzeitig ihr
Lesesperren auf ein Objekt X zu Schreib-Sperren, kann dadurch auch ein Deadlock provoziert werden.
Deadlocks können mit Hilfe von Timeouts oder Wartegraphen (Zyklus bedeutet Deadlock) erkannt werden.
Bei welchen Synchronisationsverfahren können Deadlocks auftreten?
Bei Sperrverfahren, wenn man 2-Phasen-Sperrprotokoll oder Sperren bis EOT verwendet.
Wie kann man das Deadlock-Problem bei Transaktionen behandeln?
Verhinderung: Preclaiming, Zeitmarken auf Transaktionen (Abbruch im Falle der Deadlockgefahr durch Sortierung nach BOT)
Erkennung: Timeout und Prüfung des Wartegraphen auf Schlingenfreiheit oder Kombination beider Verfahren (Aufbau des Wartegraphen bei Timeout)
Erläutern sie die Deadlock-Problematik!
Deadlock: Ist zyklisches Warten durch exklusive Zugriffs-Anforderung (exklusive Locks) mehrerer Schedules auf die gleichen Objekte (Betriebsmittel).
Was ist denn ein Livelock?
Livelocks entstehen, wenn nicht-serialisierbare Transaktionen immer wieder neu gestartet werden und
somit eine ungewollte Iteration hervorufen wird.
Wie erkennt man Deadlocks und löst sie auf?
Die Prüfung auf Zyklen geschieht im Warte-Graph. Gerichtete Kante von Ti nach Tj, wenn Ti auf Tj wartet.
Die Auflösung erfolgt indem die billigste Transaktion zurückgesetzt wird.
Wann prüft man auf Deadlocks?
Die Prüfung auf Zyklen erfolgt im Wartegraphen nach Einfügen einer Kante, in bestimmten Intervallen, wenn eine Transaktion über
eine gewisse Zeit gewartet hat (Timeout).
Was ist der Unterschied zwischen Deadlock und Timeout?
Timeout: eine bestimmte Transaktion wartet auf ein Objekt länger als eine bestimmte Maximalzeit, trotzdem kann eine
korrekte Fortsetzung möglich sein.
Deadlock: mindestens zwei Transaktionen warten jeweils auf die andere => unendliches Warten. Auflösung ist nur durch Abbruch
einer der beiden Transaktionen möglich.
Weitere Fragen und Antworten
Warum benutzt man bei Datenbanken keine Semaphore?
Semaphore stellen bei Betriebssystemen den exklusiven Zugriff auf Betriebsmittel durch Prozesse sicher,
dies garantiert im Falle der DB-Transaktionen aber keine Serialisierbarkeit!
Exklusive Sperren machen Deadlocks erst möglich (siehe Deadlockvoraussetzungen bei Betriebssystemen)!
Wann ist eine Transaktion rücksetzbar?
Rücksetzbarkeitsbedingung für Lesen: Transaktion T kann erst dann abgeschlossen werden, wenn alle Transaktionen, von denen T Daten gelesen hat, abgeschlossen sind.
Rücksetzbarkeitsbedingung für Schreiben: Eine Transaktion darf ein Objekt erst schreiben, wenn alle Transaktionen, die x zuvor geschrieben haben, abgeschlossen oder abgebrochen sind.
strikte Ausführung: Transaktion T darf ein Objekt x erst schreiben oder lesen wenn alle Transaktionen, die x geschrieben haben, abgeschlossen oder abgebrochen sind.
Wie kann man Deadlocks erkennen und behandeln?
Die Erkennung erfolgt durch Prüfung des Wartegraphen auf Schlingenfreiheit-
Die Behandlung kann durch Abbrechen der billigsten Transaktion bzw. durch den Einsatz von präventiven Synchronisationsverfahren erfolgen.
Warum ist Deadlockvermeidung unrealistisch?
Bei Produktionsdatenbanken hat man es mit einer großen Zahl sich fortlaufend ändernder Objekte zu tun.
Zwischen diesen Objekten bestehen nahezu beliebig komplexe Querbezüge. Die Anzahl der benötigten Sperren ist
in der Regel unbekannt. Beim Preclaiming wird zudem die Parallelität der Transaktionen und damit die
Gesamtperformanz eingeschränkt.
Was ist der Unterschied zwischen pessimistischen und optimistischen Verfahren
Pessimistische Verfahren garantieren die Serialisierbarkeit von Transaktionen,
optimistische Verfahren stellen die Parallelisierung in den Vordergrund und brechen beim Eintreten
eines Deadlocks eine der beteiligten Transaktionen ab.
Wozu ist die Recovery notwendig?
Das Recovery System eines DBMS ist für die Fehlerverarbeitung zuständig. Dabei werden die Fragen geklärt,
wie es Transaktionen bei Fehlererkennung abbrechen kann, ohne andere aktive Transaktionen zu beeinflussen
oder wie sich das System nach einem Totalausfall wieder in einen stabilen konsistenten Zustand zurückversetzen kann.
Welche Fehlerklassen müssen erkannt werden?
- Transaktionsfehler, wenn eine Transaktion den Commit-Status nicht erreicht ( abort ). Der Zustand der DB vor Ausführung der Transaktion muß wieder hergestellt werden. Somit müssen eventuell ausgeführte Transaktionen wieder rückgängig gemacht werden.
- Systemfehler, wie Fehler im DBMS Code, BS oder in der Hardware selbst. Des weiteren zählen Stromausfälle mit dem Verlust des instabilen Speichers (Puffers) zu Systemfehlern.
- Mediafehler, wie Head Crashes von Platten, wo Teile des stabilen Speichers verlorengehen.
Wie funktioniert das Recovery-Protokoll?
Es gibt zwei Klassen von Transaktionen, welche beim Recovery unterschieden werden müssen.
- Transaktionen, welche vor dem Crash commited waren.
- Transaktionen, welche zum Zeitpunkt des Fehlers noch aktiv waren.
Der Rücksetzmechanismus muß nun sicherstellen, daß alle Änderungen der DB einer not-commited transactions mit einer
UNDO-Operation rückgängig gemacht werden und alle freigegebenen Operationen mit einer REDO-Operation erneut
durchlaufen und permanent auf die DB übertragen werden.
Es gibt zwei Arten von Datamanagern. In-Place-Updateing bedeutet, daß immer eine Kopie der aktuellen Daten sich
im Puffer befindet. Ein zweites Konzept hält immer eine weitere Sicherheitskopie im Buffer - die Schattenkopie.
Das Konzept heißt Schattenkopiekonzept oder Defeered Updating.
Der Puffer enthält je Seite ein Dirty-Bit, falls die Seite mit der Originalseite auf dem Sekundärspeicher inkonsistent ist.
Recovery-Manager
Er stellt sicher,daß alle Operationen atomar ausgeführt werden und konkurrierende Zugriffe synchronisiert werden. Aber der Scheduler ist es, welcher die Ausführungsreihe bestimmt.
Um nach einem Systemfehler erfolgreich ein restart durchführen zu können, ist ein Logbuch notwendig. Es gibt zwei grundlegende Log-Konzepte.
|
Physischer Log
|
Logischer log
|
|
Enthält alle Informationen über die von Transaktionen geschriebenen Werte.
(Transaktion, Before- und Afterimage)
Die Einträge werden sortiert Log gespeichert.
|
Enthält eine Beschreibung der Operationen in deklarativer Art und Weise.
Macht das wiederherstellen aufwendiger.
|
Zusätzlich zur vollen wiederherstellung (Rollbacks), ist es notwendig, alle Listen (active, commit, abort) und auch die
Zeiten BOT(t) und EOT(t) im Log zu sichern. So kann aufgeklärt werden, welche Operationen mit Undo- und welche mit
Redo-Operationen zu bearbeiten sind.
Was ist Rollback?
Rollback ist das rückgängigmachen von Änderungen einer oder mehrerer Transaktionen in einer Datenbank. Dazu
sind Informationen über den Datenbankzustand vor der Transaktion notwendig (siehe Before Images).
Welche zwei grundlegenden Techniken gibt es für die Umsetzung des Rollbacks?
Wie werden die Logfiles benutzt?
Vor jeder Veränderung eines Objektes wird dessen alter Zustand (eine Kopie des Originalobjektes) in eine Logfile
geschrieben. Bei einem Rollback wird diese Logfile rückwärts gelesen und abgearbeitet. Während dieser Abarbeitung
wird jedes beteiligte Objekt mit dem Altwert aus der Logfile wieder überschrieben (bzw. rückgesetzt).
Updates auf Kopien
Änderungen einer Transaktion werden erst in die Datenbank geschrieben, wenn die Transaktion beendet ist. (siehe
optimistische Verdfahren der Serialisierbarkeit)
Rollback heißt hier, daß die Kopien einfach fallen gelassen werden. Diese Technik wird auch deferred update.
("verzögert", da alle Änderungen erst nach EOT in die DB geschrieben werden)
Was sind Checkpoints?
Bei einem System-Neustart muss das System alle zum Zeitpunkt des Zusammenbruchs aktiv gewesenen Transaktionen rücksetzen. Das
sind die Transaktionen, welche keinen EOT Eintrag im Log stehen haben. Das Problem ist nun folgendes. Im Worst Case muss
das Recovery alle Transaktionen bis zum Begin des Logfiles zurückverfolgen, um sicher zu sein, daß keine Transaktion
vergessen wurde.
Abhilfe schaffen hier sogenannte Checkpoints:
- DBMS schreibt alle X Minuten eine Liste der aktiven Transaktionen in die Logfile
- Checkpoint gibt also an, welche Transaktionen zu diesem Zeitpunkt aktiv waren
- Nun müssen nur die Transaktionen nach dem Checkpoint rückgesetzt werden
Um das Korrekte arbeiten der Checkpoints gewährleisten zu können, muss sicher gestellt werden, daß bei EOT alle Objekte einer
Transaktion auch wirklich auf die Platte geschrieben wurden, da sonst das EOT des Logfiles nicht als Beweis gültig wäre...
Welche Arten von Checkpoints gibt es?
Bei laufendem Betrieb
Hier werden alle laufenden Operationen (nicht Transaktionen) kurzzeitig beendet, um dann die Logfile mit einer Liste
der aktiven Transaktionen in das Logfile zu schreiben. Da nur Operationen und nicht Transaktionen beendet werden, wird
mit diesem Verfahren der Systemdurchsatz kaum beeinflusst.
Bei Stillstand des Systems
Der Checkpoint wird erst gesetzt, wenn das DBMS stillsteht, d.h. alle Transaktionen in einem beendeten Zustand sind. Der
Vorteil daran ist, dass das Recovery nie "hinter" einem Checkpoint notwendig werden würde. Nachteil ist aber zeitaufwendig.
Bei Transaktionsende
Nach Abschluss einer jeden Transaktion wird ein Checkpoint geschrieben. Somit ist diese Variante ein Sonderfall der Ersten.
Wie geht das Rücksetzen einer Transaktion vonstatten?
Rücksetzen (Undo): Ist das Schreiben der before-Images in umgekehrter Reihenfolge.
Bei optimistischen Verfahren ist dies nicht nötig, da hier das Schreiben erst nach der Validationsphase erfolgt.
Im Log befindet sich ein Mitschnitt der Aktivitäten der Transaktionen.
Im physischen Log werden die Werte von Datenbankobjekten vor und nach Änderungen durch Transaktionen gespeichert
(before-/after Image). Im Log wird eine Marke für BOT sowie EOT gesetzt. Für ein etwaiges Rollback vor EOT wird ein before Image
im Log gesichert. Ebenso wird unmittelbar vor EOT noch ein after-Image der Transaktion ins Log geschrieben.
Dies dient zum Recovery nach Speicherfehlern und zum Wiederholen von nach dem
letzten Checkpoint beendeten Transaktionen z.B. nach Systemzusammenbrüchen.
Im logischen Log werden die durchgeführten Operationen gespeichert.
Welche Transaktion wird bei einem Deadlock zurückgesetzt?
Die billigste Transaktion wird zurückgesetzt.
Kosten stellen hierbei die Anzahl der erforderlichen DB-Zugriffe, die CPU-Zeit und die Anzahl der abzubrechenden
Transaktionen (Rollbacks) dar.
Also sollte diejenige Transaktion mit der geringsten Anzahl an Datenänderungen/-selektionen und mit der
geringsten CPU-Intensität zurückgesetzt werden!
Was passiert bei einem Undo?
Bisherige Änderungen durch die Transaktion werden dadurch rückgängig gemacht, daß aus dem Logfile das before-Image
in die Datenbank zurückgeschrieben wird. Beim Undo wird das Log-File rückwärts durchlaufen (bei einem Redo dagegen vorwärts).
Ggf. wird ein fortgepflanzter Rollback angestoßen, da durch das Rücksetzen einer Transaktion alle von ihr
abhängigen Transaktionen auch zurückgesetzt werden müssen.
Erläuterung des Recovery bei einem Systemstart (nach einem Absturz)
Sei TC die Menge der zum Zeitpunkt eines Systemabsturzes aktiven Transaktionen.
Undo/Redo: Durchsuche das Log vom Abbruch bis zum letzten Checkpoint, führe ein Undo aus für die in dieser Zeit nicht abgeschlossenen Transaktionen, für die übrigen Transaktionen aus TC ein Redo
Undo/No-Redo: physikalisches Schreiben vor dem Commit (schlecht bei Hot-Spots), für die seit dem letzten Checkpoint nicht abgeschlossenen Transaktionen wird ein Undo ausgeführt,
No-Undo/Redo: nur abgeschlossene Objekte werden in die Datenbank geschrieben, für die seit dem letzten Checkpoint nicht abgeschlossenen Transaktionen wird ein Redo durchgeführt.
No-Undo/No-Redo: Alle Änderungen werden vor Commit in einer einzigen atomaren Operation die Datenbank geschrieben. Damit dies performant machbar ist, wird Shadowing angewendet. Nachteil: Jeder Zugriff auf das DBS ist indirekt, durch das Anfertigen von Kopien (Shadow) werden die Daten in schwer zu kontrollierender Weise über die Hintergrundspeicher verteilt.
Wie lange muß man before und after-images aufheben?
Before-Images
werden für das Rollback von Transaktionen im Falle von Transaktionsfehlern oder Systemzusammenbrüchen benötigt.
Die Speicherung erfolgt von BOT bis EOT.
Before-Images enthalten für jedes veränderte Objekt die ObjektID, den alten Wert des Objektes und die TransaktionsID.
After-Images
werden für das Recovery nach Speicherfehlern und für das Wiederholen von nach dem letzten Checkpoint beendeten Transaktionen
im Falle eines System-Zusammenbruches benötigt. Die Speicherung erfolgt unmittelbar vor EOT bis zum nächsten Dump / Checkpoint.
Was wird zuerst geschrieben? Log oder Datenbank?
Natürlich zuerst in die Logfile. Anderfalls könnten nicht mit Sicherheit alle Operationen wieder rückgängig gemacht werden.
|
|
|
|
|
| Kapitel 1 | DBMS Konzept |
|
Eigenschaften, Bestandteile, Ebenen...
|
| Kapitel 2 | DB Entwurf |
|
Qualitätsmerkmale, funktionale Abhängigkeiten, ER...
|
| Kapitel 3 | Normalformen |
|
Übersicht Normalformen, Anomalien...
|
| Kapitel 4 | Relationalität |
|
Regeln und Vorgehensweisen...
|
| Kapitel 5 | Sprachen |
|
relationale Sprachen, SQL, Query...
|
| Kapitel 6 | Datenorganisation |
|
Tertiärspeicher, Adressierung, Indexe, ISAM...
|
| Kapitel 7 | Transaktionskonzept |
|
Datenintegrität, Serialisierbarkeit, ACID...
|
| Kapitel 8 | Concurrency Control |
|
Read-Write Modell, Schedules, Prinzip...
|
| Kapitel 9 | Scheduler & Recovery |
|
2-Phasen-Sperren,Deadlocks,Recovery...
|
|
|
|
|
|
|
|
|
Quellen:
|
Gottfried Vossen
Datenbankmanagementsysteme
|
Heuer und Saake
Konzepte und Sprachen
|
Prof. Benn
Skript und Vorlesung
|
Relationale Datenbanken
Andreas Kelz
|
Word Wide Web
Verschiedenste Seiten
|
|
|
|
|
|
|
Home 
Normalformen