Home

Impressum

kreissl.info[rmation science]

best practices

Scheduler und Recovery

Kapitel 9 - Scheduler und Recovery

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.

Schedule-Prinzip

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.

Schedule-Prinzip

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)

Schedule-Prinzip

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.

Inhalt

Anfang

zurück

EOT

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...