Recovery
This commit is contained in:
Marco Ammon
parent
613cb7da22
commit
bed7ea1ccc
Binary file not shown.
|
|
@ -251,24 +251,7 @@
|
|||
\section{Transaktionen}
|
||||
\begin{itemize}
|
||||
\item sinnvoll für \wichtig{nebenläufigen} Zugriff
|
||||
\item erleichtern Umgang mit \begriff{Fehlern} und Ausfällen
|
||||
\item \begriff{Programmfehler}: Absturz des Datenbank-Anwendungsprogramms $\Rightarrow$ Daten im Puffer und auf Festplatte in undefiniertem Zustand
|
||||
\item \begriff{Systemfehler}: DBVS oder BS fällt aus, Hardware-Fehler, \textellipsis $\Rightarrow$ Daten im Puffer verloren, auf Festplatte in undefiniertem Zustand
|
||||
\item \begriff{Gerätefehler}: Festplattenausfall $\Rightarrow$ Daten auf Festplatte sind verloren
|
||||
\item \begriff{physische Konsistenz}: \begin{itemize}
|
||||
\item Korrektheit der Speicherungsstrukturen, Verweise und Adressen
|
||||
\item alle Indizes sind vollständig und stimmen mit Primärdaten überein
|
||||
\end{itemize}
|
||||
\item \begriff{logische Konsistenz}: \begin{itemize}
|
||||
\item Korrektheit der Inhalte
|
||||
\item Referentielle Integrität, Primärschlüsseleigenschaft und eigene Assertions sind erfüllt
|
||||
\item erfordert physische Konsistenz
|
||||
\end{itemize}
|
||||
\item Nach Fehler soll ein logisch konsistenter Zustand erreicht werden: \begin{itemize}
|
||||
\item der Zustand vor Beginn der unvollständigen Änderungen durch \begriff{Rückgängigmachen} dieser (\begriff{undo})
|
||||
\item der Zustand nach Abschluss aller Änderungen durch \begriff{Vervollständigung} bzw. \begriff{Wiederholung} der unvollständigen Änderungen (\begriff{redo})
|
||||
\end{itemize}
|
||||
\item \begriff{Sicherung} und \begriff{Protokollierung} \wichtig{immer} notwendig
|
||||
\item erleichtern Umgang mit \begriff{Fehlern} und Ausfällen (siehe \textbf{TODO}: Link Recovery)
|
||||
\item \begriff{Transaktion} als \begriff{logische Einheit} einer Folge von DB-Operationen (von einem logisch konsistenten Zustand zum nächsten): \begin{itemize}
|
||||
\item bei Fehler vor Ende: Rückgängigmachen der bisher durchgeführten Änderungen
|
||||
\item bei Fehler nach Ende: kein Problem
|
||||
|
|
@ -396,4 +379,65 @@
|
|||
\item je nach System/Anwendung Optimierung auf niedrige CPU-/IO-Last
|
||||
\item \begriff{Statistiken} für Wahl des Planoperators sinnvoll (Verteilung der Tupel, Selektivität, \dots)
|
||||
\end{itemize}
|
||||
|
||||
\section{Recovery}
|
||||
\begin{itemize}
|
||||
\item \begriff{Programmfehler}: Absturz des Datenbank-Anwendungsprogramms $\Rightarrow$ Daten im Puffer und auf Festplatte in undefiniertem Zustand
|
||||
\item \begriff{Systemfehler}: DBVS oder BS fällt aus, Hardware-Fehler, \textellipsis $\Rightarrow$ Daten im Puffer verloren, auf Festplatte in undefiniertem Zustand
|
||||
\item \begriff{Gerätefehler}: Festplattenausfall $\Rightarrow$ Daten auf Festplatte sind verloren
|
||||
\item \begriff{Transaktionsfehler}: z.B. \begriff{Deadlock}, falsche Operationen, Aufruf von \texttt{rollback} bzw. \texttt{abort}
|
||||
\item \begriff{physische Konsistenz}: \begin{itemize}
|
||||
\item Korrektheit der Speicherungsstrukturen, Verweise und Adressen
|
||||
\item alle Indizes sind vollständig und stimmen mit Primärdaten überein
|
||||
\end{itemize}
|
||||
\item \begriff{logische Konsistenz}: \begin{itemize}
|
||||
\item Korrektheit der Inhalte
|
||||
\item Referentielle Integrität, Primärschlüsseleigenschaft und eigene Assertions sind erfüllt
|
||||
\item erfordert physische Konsistenz
|
||||
\end{itemize}
|
||||
\item Nach Fehler soll ein logisch konsistenter Zustand erreicht werden: \begin{itemize}
|
||||
\item der Zustand vor Beginn der unvollständigen Änderungen durch \begriff{Rückgängigmachen} dieser (\begriff{undo}) \begin{itemize}
|
||||
\item \begriff{partial}: nach Transaktionsfehler Zurücksetzen der fehlgeschlagenen Transaktion
|
||||
\item \begriff{global}: nach Systemfehler mit Verlust des Hauptspeicherinhalts Zurücksetzen aller unvollständigen Transaktion
|
||||
\item Logging-Informationen müssen \wichtig{vor} dem Einbringen gespeichert werden (\begriff{write-ahead log}, WAL)
|
||||
\end{itemize}
|
||||
\item der Zustand nach Abschluss aller Änderungen durch \begriff{Vervollständigung} bzw. \begriff{Wiederholung} der unvollständigen Änderungen (\begriff{redo}) \begin{itemize}
|
||||
\item \begriff{partial}: nach Systemfehler mit Verlust des Hauptspeicherinhalts Wiederholen aller verlorengegangen Änderungen von abgeschlossenen Transaktionen
|
||||
\item \begriff{global}: nach Gerätefehler Einspielen des Backups und Nachvollziehen aller danach erfolgreichen Transaktionen
|
||||
\item Logging-Informationen müssen \wichtig{vor} dem Melden des erfolgreichen Abschlusses geschrieben werden
|
||||
\end{itemize}
|
||||
\end{itemize}
|
||||
\item \begriff{Sicherung} und \begriff{Protokollierung} (\begriff{Logging}) \wichtig{immer} notwendig
|
||||
\item auch Einbringstrategie von Bedeutung: \begin{itemize}
|
||||
\item \enquote{Wann \wichtig{darf} geänderte Seite auf die Festplatte geschrieben werden?} \begin{itemize}
|
||||
\item \begriff{Steal}: auch schon vor Ende der Transaktion bei Verdrängung aus dem Puffer
|
||||
\item \begriff{NoSteal}: erst am Ende der erfolgreichen Transaktion
|
||||
\end{itemize}
|
||||
\item \enquote{Wann \wichtig{muss} geänderte Seite auf die Festplatte geschrieben werden?} \begin{itemize}
|
||||
\item \begriff{NoForce}: erst bei Verdrängung aus dem Puffer (also auch nach Ende einer Transaktion)
|
||||
\item \begriff{Force}: spätestens am Ende der erfolgreichen Transaktion
|
||||
\end{itemize}
|
||||
\item \enquote{Wie werden geänderte Seiten auf die Festplatte geschrieben?} \begin{itemize}
|
||||
\item \begriff{NotAtomic}: direktes Einbringen, in-place
|
||||
\item \begriff{Atomic}: indirektes Einbringen, \enquote{Umschalten} von altem auf neuen Zustand
|
||||
\end{itemize}
|
||||
\end{itemize}
|
||||
\item Protokollverfahren: \begin{itemize}
|
||||
\item \begriff{physisch}: \begin{itemize}
|
||||
\item \begriff{Zustandprotokollierung}: \begriff{before-image} für undo, \begriff{after-image} für redo, auf Ebene von Seiten oder Sätzen
|
||||
\item \begriff{Seitenprotokollierung}: für jede geänderte Seite before-image und after-image sichern
|
||||
\item \begriff{Eintragsprotokollierung}:nur geänderte Teile einer Seite
|
||||
\end{itemize}
|
||||
\end{itemize}
|
||||
\item Begrenzung des Recovery-Aufwands durch \begriff{Sicherungspunkte} (\begriff{checkpoints}): \begin{itemize}
|
||||
\item \begriff{transaction-oriented checkpoint}: Einbringung mittels Force
|
||||
\item \begriff{transaction-consistent checkpoint}: Beginn neuer Transaktionen verhindern, auf Abschluss der laufenden warten, dann sichern
|
||||
\item \begriff{action-consistent checkpoint}: keine Änderungs\wichtig{operation} darf aktiv sein, dann sichern; da aber Transaktionen laufen nur Begrenzung von Redo-Recovery
|
||||
\end{itemize}
|
||||
\item \begriff{Wiederherstellungsprozedur}: \begin{itemize}
|
||||
\item Analyse von letztem Checkpoint bis zum Log-Ende
|
||||
\item erfolgreiche Transaktionen gegebenenfalls wiederholen
|
||||
\item fehlgeschlagene Transaktionen von \enquote{neu nach alt} rückgängig machen
|
||||
\end{itemize}
|
||||
\end{itemize}
|
||||
\end{document}
|
||||
Loading…
Reference in New Issue