diff --git a/IDB.tex b/IDB.tex index 4da76ab..7072382 100644 --- a/IDB.tex +++ b/IDB.tex @@ -1,4 +1,5 @@ -\documentclass[12pt,a4paper]{article} +\listfiles +\documentclass[12pt,a4paper]{scrartcl} \usepackage[utf8]{inputenc} \usepackage[ngerman]{babel} \usepackage{graphicx} @@ -6,10 +7,13 @@ \usepackage{amssymb} \usepackage{amsfonts} \usepackage{lmodern} +\usepackage{a4wide} \usepackage{psfrag} \usepackage{colortbl} \usepackage{color} -\usepackage{hyperref} +\usepackage{textcomp} +\usepackage{cancel} +\usepackage[pdfborder={0 0 0}, colorlinks=true, filecolor=blue, linkcolor=blue, citecolor=blue, urlcolor=blue]{hyperref} \usepackage{float} \usepackage{listings} \usepackage{lstautogobble} @@ -57,346 +61,6 @@ \begin{document} \tableofcontents \newpage -\section{Transaktionen} -\subsection{Allgemein} -\subsubsection{Was sind Transaktionen?} -Transaktionen sind eine logische Arbeitseinheit, die mehrere -DB Schritte zusammenfassen.\\ -Z.B. einfügen eines neuen Mitarbeiters besteht aus vielen kleinen -DB Befehlen, bis Datenbank wieder konsistent ist - -\subsubsection{Wofür sind sie gut?} -Sie überleiten von einem konsistenten Zustand in den nächsten. -Im Fehlerfall muss die Möglichkeit gegeben werden, wieder in -einen konsistenten Zustand zu finden. -Im Mehrfachbetrieb muss gewährleistet werden, dass keine -Nebenläufigkeitsprobleme auftauchen. - -\subsubsection{ACID Eigenschaften von Transaktionen:} -\begin{itemize} - \item \textbf{Atomic:} Alle Änderungen von TA werden aktiv oder keine - \item \textbf{Consistency:} TA überführt DB von konsistent in konsistenten Zustand - \item \textbf{Isolation:} TA wird nicht von anderer TA beeinflusst - \item \textbf{Durability:} Änderungen sind Dauerhaft in DB übernommen -\end{itemize} - -\subsection{Konsistenzen:} -\subsubsection{Physische Konsistenz:} -Alle Speicheurngsstrukturen sind korrekt. Alle TID's stimmen etc. - -\subsubsection{Logische Konsistenz:} -Setzt Physische Konsistenz voraus.\\ -Korrektheit der Dateninhalte.\\ -Alle Bedingungen des Datenmodells und alle Benutzerdefinierten -Bedingungen sind erfüllt (Assertions). - -\subsection{Synchronisation} -\subsubsection{Zustandsdiagramm TA} -\begin{figure}[H] - \begin{center} - \includegraphics[scale=0.6]{TA_status.png} - \caption{Transaktionszustände} - \end{center} -\end{figure} - -\subsubsection{Anomalien ohne Synchronisation} -\begin{itemize} - \item \textbf{lost updates}\\ - $r_1(x) r_2(x) w_1(x) w_2(x)$ - \item Abhängigkeiten von nicht freigegeben Änderungen - \begin{itemize} - \item \textbf{dirty read}\\ - $w_1(x)r_2(x)a_1 c_2$\\ - Änderung wird noch nicht freigegeben (ggf abgebrochen) aber trotzdem gelesen - \item \textbf{dirty write}\\ - $w_1(x)r_2(x)w_2(x)a_1 c_2$\\ - Änderung wird noch nicht freigegeben (ggf abgebrochen) aber trotzdem geschrieben - \end{itemize} - \item \textbf{Non Repeatable Read}\\ - $r_1(x)w_2(x)r_1(x)$\\ - T1 sieht beim erneuten lesen einen anderen Wert als zuvor - \item \textbf{Phantom}\\ - $r_1(P)w_2(x in P)r_1(P)$\\ - Wie bei \textit{Non Repeatable Read} nur Prädikat statt einzelnes Element -\end{itemize} -\textit{Legende: c = commit, a = abort, w = write, r = read} -\subsubsection{Serialisierung} -Hintereinanderausführung aller TA's. Problem werden -sehr große Wartezeiten. Allgemein ist deine Datenbank für Mehrbenutzerbetrieb -ausgelegt, dies würde ab adsurdum geführt durch Serialisierung. -Was tun im Fehlerfall - -\subsubsection{Serialisierbarkeit} -Ziel:\\TA's laufen \textit{verzahnt} ab, aber ihr Ergebnis gleicht dem eines seriellen -Ablaufes.\\ -$\rightarrow$ Ein Schedule von TA's ist \textbf{serialisierbar}, wenn es einen äquivalten -\textbf{seriellen} Ablauf gibt. - -\subsubsection{Implementierung von Sperren} -\textbf{Wann sperren?}\\ -Statisch:\\ -Alles sperren was evtl gebraucht wir (preclaiming) - -Dynamisch:\\ -Zur Laufzeit von TA nach Bedarf sperren\\ -$\rightarrow$ Gefahr von Verklemmungen! - -Sperrgranulat:\\ -Warum nicht Tupel: -\begin{itemize} - \item Nicht immer effizient, bei großen Mengen - \item Phantom Tupel; es können nur bereits existente Tupel gesperrt werden. -\end{itemize} -Deshalb wird \textit{hierarchische Schachtelung} der Datenobjekte:\\ -\begin{figure}[H] - \begin{center} - \includegraphics[scale=0.8]{sperrgranulat.png} - \caption{Sperrgranulate} - \end{center} -\end{figure} - -Für jedes Objekt kann man nun einen Sperrmodus vergeben. -Andere TA können daran erkennen, ob sie ihre Aktion ausführen dürfen. -\begin{figure}[H] - \begin{center} - \includegraphics[scale=0.6]{komp_matrix.png} - \caption{Kompatibilitätsmatrix} - \end{center} -\end{figure} -Das Problem an dieser Art der Sperrung ist, dass -\begin{itemize} - \item Alle Nachfolgeknoten implizit mitgesperrt werden - \item Alle Vorgängerknoten auch gesperrt werden müssen -\end{itemize} -Daher werden sogenannte \textbf{(Intention) Anwartschaftssperren} eingeführt: -\begin{itemize} - \item {IS Sperre:\\ - falls auf untergeordnete Objekte lesend zugegriffen wird} - \item {IX Sperre:\\ - falls auf untergeordnete schreibend zugegriffen wird} -\end{itemize} -$\rightarrow$ Benutzung von Untersperre wird angezeigt, aber nochmal explizit weiter unten gesetzt! -\paragraph{TOP-DOWN bei Sperre} -\begin{itemize} - \item Bevor ein Knoten mit S oder IS gesperrt werden darf, müssen alle Vorgänger - in der Hierarchie im IX- oder im IS-Modus gesperrt worden sein. - \item - Bevor ein Knoten mit X oder IX gesperrt werden darf, müssen alle Vorgänger - in der Hierarchie im IX-Modus gesperrt worden sein. -\end{itemize} -\paragraph{BOTTOM-UP bei Freigabe} -\begin{itemize} - \item Freigabe von unten nach oben - \item kein Knoten darf entsperrt werden, wenn noch andere Nachfolger dieses Knotens - gesperrt sind -\end{itemize} -Als Optimierung gibt es noch die \textbf{SIX} Sperre. Alles wird lesend gesperrt -und eine Menge an Nachfolgern schreibend. Das lohnt sich z.B. wenn aus einer Relation -nur wenige Tupel verändert werden. - -\subsubsection{Probleme beim Sperren} -\begin{itemize} - \item Sperren muss sehr schnell gehen, da Anforderungen sehr hoch - \item halten von Sperren bis TA-ende führt zu langen Wartezeiten - \item Eigenschaften des Schemas können \glqq hotspots\grqq erzeugen - \item {Optimierungen: - \begin{itemize} - \item Nutzung mehrere Objektversionen - \item spezialisiertes Sperren - \item Änderungen auf privaten Objektkopien - \end{itemize} - } -\end{itemize} - -\subsubsection{Verklemmungen} -Lösungsmöglichkeiten: -\begin{itemize} - \item{\textbf{Timout:}\\ - Transaktion nach bestimmter Wartezeit zurücksetzen.\\ - $\rightarrow$ problematisch Länge des Timeouts zu bestimmen - } - \item{\textbf{Verhütung (Prevention)}\\ - Durch Preclaiming (s.o.) keine Deadlock Verhinderung zur Laufzeit notwenig.} - \item{\textbf{Vermeidung (Avoidance)}\\ - Potentielle Deadlocks im vorhinein erkennen und vermeiden\\ - $\rightarrow$ Laufzeitunterstützung notwendig - } - \item{\textbf{Erkennung (Detection)}\\ - Explizites führen eines Wartegraphen und darin Zyklensuche. Im Zyklus dann - eine oder mehrere (am besten billigste) TA zurücksetzen.} -\end{itemize} -\textbox{Deadlock - nicht serialisierbarer Schedule}{ - Nicht serialisierbare Schedules, beschreibt Abläufe die zu - keinem seriellen Ablauf äquivalent sind. Die somit zu Deadlocks führen. - Führt man diese mit \textit{dynamischen} Sperren aus, muss es aber nicht - zwangsläufig auch zu Deadlocks kommen! -} -\subsection{Recovery} -\textbf{Recovery Klassen:} -\begin{itemize} - \item {Partial Undo (R1-Recover) - \begin{itemize} - \item nach Transaktionsfehler - \item isoliertes und vollständiges Zurücksetzen der Daten - in Anfangszustand - \item beeinflusst andere TA nicht - \end{itemize} - } - \item {Partial Redo (R2-Recover) - \begin{itemize} - \item nach Systemfehler (mit Verlust von HS) - \item Wiederhlung aller verlorengegangenen Änderungen - (waren nur im Puffer) von abgeschlossenen TA - \end{itemize} - } - \item {Global Undo (R3-Recover) - \begin{itemize} - \item nach Systemfehler (mit Verlust von HS) - \item Zurücksetzen aller durch Ausfall unterbrochenen TA - \end{itemize} - } - \item {Global Redo (R4-Recover) - \begin{itemize} - \item nach Gerätefehler - \item Einspielen von Archivkopie und nachvollziehen - aller beendeten TA's - \end{itemize} - } -\end{itemize} -\subsubsection{Archivkopien} -Arten: -\begin{itemize} - \item \glqq cold backup\grqq: DBS muss au"ser Betrieb sein - \item \glqq hot backup\grqq: Beeinträchtigung des laufenden Betriebs -\end{itemize} -\subsubsection{Einbringstrategien} -Wann werden geänderte Daten aus dem Puffer auf die Platte geschrieben? -\begin{itemize} - \item {STEAL:\\ - Bei Verdrängung au dem Puffer, auch vor ende der Transaktion} - \item {NO STEAL:\\ - Frühestens am Ende der Transaktion $\rightarrow$ kein UNDO erfoderlich (aber großen Puffer)} - - \item {FORCE:\\ - Spätestens am Ende der Transaktion $\rightarrow$ kein Partial Redo erfoderlich} - - \item {NO FORCE:\\ - Erst bei Verdränung aus dem Puffer} -\end{itemize} -Wie werden geänderte Daten aus dem Puffer auf Platte geschrieben? -\begin{itemize} - \item{ATOMIC:\\ - Indirekte Einbringstrategie.\\ - Ununterbrechbares Umschalten} - \item{NOT ATOMIC: - Direkte Einbringstrategie.\\ - Ist nicht ununterbrechbar. - } -\end{itemize} -\subsubsection{Protokolldaten} -Als Protollinformation zählt was über die Einbringungsstrategie hinaus -benötigt wird, um nach einem Systemausfall den jüngsten konsisten Zustand -wiederherzustellen. -\begin{figure}[H] - \begin{center} - \includegraphics[scale=0.6]{protokoll2.png} - \caption{Protokollinformationen} - \end{center} -\end{figure} - -\paragraph{Wann wird in Protokolldatei geschrieben?} -\begin{itemize} - \item{UNDO-Information:\\ - \begin{itemize} - \item bevor die zugehörigen Änderungen in Datenbestand eingebracht werden - \item sonst rücksetzen unmöglich - \end{itemize} - } - \item{REDO-Information:\\ - \begin{itemize} - \item muss geschrieben sein (in tmp Log Datei und Archivdatei), bevor der Abschluss der TA - an Programm bzw Benutzer gemeldet wird - \item sonst Wiederherstellung nicht möglich - \end{itemize} - } -\end{itemize} -\subsubsection{Backward-/Forward Recovery} -\begin{enumerate} - \item{ Forward:\\ - Änderungen sind noch nicht in DB, aber schon in Log. Bevor - diese auf DB geschrieben werden, wird ein Commit-Record in - Log File geschrieben. Falls was schief geht und der Commit Record noch da ist, werden alle diese Änderungen wiedehrolt und ansonsten nichts getan, da alte Version noch in DB steht.} - \item{ Backward:\\ - Ins Log kommt immer \textbf{alte} Version eines Wertes. Bei - einem Commit wird gewartet bis alle neuen werte in DB stehen. - Danach erst wird CommitRecord erstellt und eine Bestätigung - signalisiert. - Bei Verlust werden entweder alte Daten hergestellt oder nichts getan.} -\end{enumerate} -\paragraph{Vergleich} -\begin{itemize} - \item{ Forward Recovery: Hoher Speicherplatzbedarf! Daten werden erst nach Beendigung der TA in DB geschrieben und deswegen solange in Puffer behalten} - \item{ Backward-Recovery: Hoher I/O Aufwand! Alle Änderungen müssen vor TA-Ende in Datenfiles stehen.} -\end{itemize} -\subsubsection{Undo-/Redo Logging} -Verbesserung zu Backward-/Forward Recovery. -\begin{figure}[H] - \begin{center} - \includegraphics[scale=0.8]{protokoll.png} - \caption{Physische Protokollierung} - \end{center} -\end{figure} -Zustände vor bzw nach einer Änderungen werden protokolliert: -\begin{itemize} - \item alter Zustand: Before Image (BI) für UNDO - \item neuer Zustand: After Image (AI) für REDO - \item für jede veränderte Seite (3) wird jeweils eine - vollständige Kopie vor (2) und nach (4) der Änderung in den Log - geschrieben.\\ - $+$ schnelle Recovery\\ - $-$ hoher E/A Aufwand -\end{itemize} -\paragraph{Optimierungen} -Um Log-Aufwand zu reduzieren nur geänderte \textbf{Teile einer Seite} -protokollieren.\\ -Sammlung und Pufferung im HS: -\begin{itemize} - \item $+$ reduzierter E/A Aufwand - \item $-$ komplexeres und zeitaufwändigeres Recovery\\ - Zurückspeichern gleicht eher dem Neu einfügen (freien Platz suchen, TID vergeben), da Stelle von wo Einträge stammen andersweitig genutzt werden können -\end{itemize} - -\subsubsection{Sicherungspunkte} -Ma"snahmen zur Begrenzung des REDO Aufwands nach Systemfehlern (alle -erfolgreichen Änderungen die im Puffer verloren gegangen sind müssen wiederholt werden $\rightarrow$ nicht praktikabel! -\paragraph*{Methoden} -\begin{itemize} - \item{ \textbf{Transaction-Oriented Checkpoint}\\ - Geänderte Seiten einer TA nach TA-ende sofort in DB bringen (siehe FORCE) $\rightarrow$ zu hohe Belastung} - \item{ \textbf{ Transaction-COnsisten Checkpoint} - \begin{itemize} - \item Einbringung aller Änderung erfolgreicher TA's - \item Lesesperee auf ganzer DB zum Zeitpunkt des Sicherungspunktes - \item Verzögerung von TA's - \item Sicherungspunkt begrenzt Undo und Redo Recovery - \end{itemize} - } - \item{ \textbf{Action-Consisten Checkpoint} - \begin{itemize} - \item Zum Zeitpunkt des Sicherungspunktes dürfen keine Änderunen aktiv sein - \item Begünstigt nur Recovery, dafür kürzere Totzeit von System - \end{itemize} - } -\end{itemize} -\subsubsection{Allgemeine Restart Prozedur} -\textbf{3-phasiger Ansatz} -\begin{enumerate} - \item Analyse Lauf - Vom letzten Checkpoint bis zum Log Ende. Bestimmung von Gewinner und Verlierer TA's, sowie Seiten, die von ihnen geändert wurden - \item Undo Lauf \\ - Rücksetzen der Verlierer TA's durch Rückwärtslesen des Logs bis zum BOT Satz der ältesten Verlierer TA - \item Redo Lauf \\ - Vorwärtslesen des Logs (Startpunkt abhängig von Checkpoint Typ) und Änderungen der Gewinner TA's wiederholen -\end{enumerate} - +\include{./Speicherung} +\include{./Transaktionen} \end{document} diff --git a/Speicherung.tex b/Speicherung.tex new file mode 100644 index 0000000..2c4e643 --- /dev/null +++ b/Speicherung.tex @@ -0,0 +1 @@ +\section{Speicherung} diff --git a/Transaktionen.tex b/Transaktionen.tex new file mode 100644 index 0000000..1c00f75 --- /dev/null +++ b/Transaktionen.tex @@ -0,0 +1,342 @@ +\section{Transaktionen} +\subsection{Allgemein} +\subsubsection{Was sind Transaktionen?} +Transaktionen sind eine logische Arbeitseinheit, die mehrere +DB Schritte zusammenfassen.\\ +Z.B. einfügen eines neuen Mitarbeiters besteht aus vielen kleinen +DB Befehlen, bis Datenbank wieder konsistent ist + +\subsubsection{Wofür sind sie gut?} +Sie überleiten von einem konsistenten Zustand in den nächsten. +Im Fehlerfall muss die Möglichkeit gegeben werden, wieder in +einen konsistenten Zustand zu finden. +Im Mehrfachbetrieb muss gewährleistet werden, dass keine +Nebenläufigkeitsprobleme auftauchen. + +\subsubsection{ACID Eigenschaften von Transaktionen:} +\begin{itemize} + \item \textbf{Atomic:} Alle Änderungen von TA werden aktiv oder keine + \item \textbf{Consistency:} TA überführt DB von konsistent in konsistenten Zustand + \item \textbf{Isolation:} TA wird nicht von anderer TA beeinflusst + \item \textbf{Durability:} Änderungen sind Dauerhaft in DB übernommen +\end{itemize} + +\subsection{Konsistenzen:} +\subsubsection{Physische Konsistenz:} +Alle Speicheurngsstrukturen sind korrekt. Alle TID's stimmen etc. + +\subsubsection{Logische Konsistenz:} +Setzt Physische Konsistenz voraus.\\ +Korrektheit der Dateninhalte.\\ +Alle Bedingungen des Datenmodells und alle Benutzerdefinierten +Bedingungen sind erfüllt (Assertions). + +\subsection{Synchronisation} +\subsubsection{Zustandsdiagramm TA} +\begin{figure}[H] + \begin{center} + \includegraphics[scale=0.6]{TA_status.png} + \caption{Transaktionszustände} + \end{center} +\end{figure} + +\subsubsection{Anomalien ohne Synchronisation} +\begin{itemize} + \item \textbf{lost updates}\\ + $r_1(x) r_2(x) w_1(x) w_2(x)$ + \item Abhängigkeiten von nicht freigegeben Änderungen + \begin{itemize} + \item \textbf{dirty read}\\ + $w_1(x)r_2(x)a_1 c_2$\\ + Änderung wird noch nicht freigegeben (ggf abgebrochen) aber trotzdem gelesen + \item \textbf{dirty write}\\ + $w_1(x)r_2(x)w_2(x)a_1 c_2$\\ + Änderung wird noch nicht freigegeben (ggf abgebrochen) aber trotzdem geschrieben + \end{itemize} + \item \textbf{Non Repeatable Read}\\ + $r_1(x)w_2(x)r_1(x)$\\ + T1 sieht beim erneuten lesen einen anderen Wert als zuvor + \item \textbf{Phantom}\\ + $r_1(P)w_2(x in P)r_1(P)$\\ + Wie bei \textit{Non Repeatable Read} nur Prädikat statt einzelnes Element +\end{itemize} +\textit{Legende: c = commit, a = abort, w = write, r = read} +\subsubsection{Serialisierung} +Hintereinanderausführung aller TA's. Problem werden +sehr große Wartezeiten. Allgemein ist deine Datenbank für Mehrbenutzerbetrieb +ausgelegt, dies würde ab adsurdum geführt durch Serialisierung. +Was tun im Fehlerfall + +\subsubsection{Serialisierbarkeit} +Ziel:\\TA's laufen \textit{verzahnt} ab, aber ihr Ergebnis gleicht dem eines seriellen +Ablaufes.\\ +$\rightarrow$ Ein Schedule von TA's ist \textbf{serialisierbar}, wenn es einen äquivalten +\textbf{seriellen} Ablauf gibt. + +\subsubsection{Implementierung von Sperren} +\textbf{Wann sperren?}\\ +Statisch:\\ +Alles sperren was evtl gebraucht wir (preclaiming) + +Dynamisch:\\ +Zur Laufzeit von TA nach Bedarf sperren\\ +$\rightarrow$ Gefahr von Verklemmungen! + +Sperrgranulat:\\ +Warum nicht Tupel: +\begin{itemize} + \item Nicht immer effizient, bei großen Mengen + \item Phantom Tupel; es können nur bereits existente Tupel gesperrt werden. +\end{itemize} +Deshalb wird \textit{hierarchische Schachtelung} der Datenobjekte:\\ +\begin{figure}[H] + \begin{center} + \includegraphics[scale=0.8]{sperrgranulat.png} + \caption{Sperrgranulate} + \end{center} +\end{figure} + +Für jedes Objekt kann man nun einen Sperrmodus vergeben. +Andere TA können daran erkennen, ob sie ihre Aktion ausführen dürfen. +\begin{figure}[H] + \begin{center} + \includegraphics[scale=0.6]{komp_matrix.png} + \caption{Kompatibilitätsmatrix} + \end{center} +\end{figure} +Das Problem an dieser Art der Sperrung ist, dass +\begin{itemize} + \item Alle Nachfolgeknoten implizit mitgesperrt werden + \item Alle Vorgängerknoten auch gesperrt werden müssen +\end{itemize} +Daher werden sogenannte \textbf{(Intention) Anwartschaftssperren} eingeführt: +\begin{itemize} + \item {IS Sperre:\\ + falls auf untergeordnete Objekte lesend zugegriffen wird} + \item {IX Sperre:\\ + falls auf untergeordnete schreibend zugegriffen wird} +\end{itemize} +$\rightarrow$ Benutzung von Untersperre wird angezeigt, aber nochmal explizit weiter unten gesetzt! +\paragraph{TOP-DOWN bei Sperre} +\begin{itemize} + \item Bevor ein Knoten mit S oder IS gesperrt werden darf, müssen alle Vorgänger + in der Hierarchie im IX- oder im IS-Modus gesperrt worden sein. + \item + Bevor ein Knoten mit X oder IX gesperrt werden darf, müssen alle Vorgänger + in der Hierarchie im IX-Modus gesperrt worden sein. +\end{itemize} +\paragraph{BOTTOM-UP bei Freigabe} +\begin{itemize} + \item Freigabe von unten nach oben + \item kein Knoten darf entsperrt werden, wenn noch andere Nachfolger dieses Knotens + gesperrt sind +\end{itemize} +Als Optimierung gibt es noch die \textbf{SIX} Sperre. Alles wird lesend gesperrt +und eine Menge an Nachfolgern schreibend. Das lohnt sich z.B. wenn aus einer Relation +nur wenige Tupel verändert werden. + +\subsubsection{Probleme beim Sperren} +\begin{itemize} + \item Sperren muss sehr schnell gehen, da Anforderungen sehr hoch + \item halten von Sperren bis TA-ende führt zu langen Wartezeiten + \item Eigenschaften des Schemas können \glqq hotspots\grqq erzeugen + \item {Optimierungen: + \begin{itemize} + \item Nutzung mehrere Objektversionen + \item spezialisiertes Sperren + \item Änderungen auf privaten Objektkopien + \end{itemize} + } +\end{itemize} + +\subsubsection{Verklemmungen} +Lösungsmöglichkeiten: +\begin{itemize} + \item{\textbf{Timout:}\\ + Transaktion nach bestimmter Wartezeit zurücksetzen.\\ + $\rightarrow$ problematisch Länge des Timeouts zu bestimmen + } + \item{\textbf{Verhütung (Prevention)}\\ + Durch Preclaiming (s.o.) keine Deadlock Verhinderung zur Laufzeit notwenig.} + \item{\textbf{Vermeidung (Avoidance)}\\ + Potentielle Deadlocks im vorhinein erkennen und vermeiden\\ + $\rightarrow$ Laufzeitunterstützung notwendig + } + \item{\textbf{Erkennung (Detection)}\\ + Explizites führen eines Wartegraphen und darin Zyklensuche. Im Zyklus dann + eine oder mehrere (am besten billigste) TA zurücksetzen.} +\end{itemize} +\textbox{Deadlock - nicht serialisierbarer Schedule}{ + Nicht serialisierbare Schedules, beschreibt Abläufe die zu + keinem seriellen Ablauf äquivalent sind. Die somit zu Deadlocks führen. + Führt man diese mit \textit{dynamischen} Sperren aus, muss es aber nicht + zwangsläufig auch zu Deadlocks kommen! +} +\subsection{Recovery} +\textbf{Recovery Klassen:} +\begin{itemize} + \item {Partial Undo (R1-Recover) + \begin{itemize} + \item nach Transaktionsfehler + \item isoliertes und vollständiges Zurücksetzen der Daten + in Anfangszustand + \item beeinflusst andere TA nicht + \end{itemize} + } + \item {Partial Redo (R2-Recover) + \begin{itemize} + \item nach Systemfehler (mit Verlust von HS) + \item Wiederhlung aller verlorengegangenen Änderungen + (waren nur im Puffer) von abgeschlossenen TA + \end{itemize} + } + \item {Global Undo (R3-Recover) + \begin{itemize} + \item nach Systemfehler (mit Verlust von HS) + \item Zurücksetzen aller durch Ausfall unterbrochenen TA + \end{itemize} + } + \item {Global Redo (R4-Recover) + \begin{itemize} + \item nach Gerätefehler + \item Einspielen von Archivkopie und nachvollziehen + aller beendeten TA's + \end{itemize} + } +\end{itemize} +\subsubsection{Archivkopien} +Arten: +\begin{itemize} + \item \glqq cold backup\grqq: DBS muss au"ser Betrieb sein + \item \glqq hot backup\grqq: Beeinträchtigung des laufenden Betriebs +\end{itemize} +\subsubsection{Einbringstrategien} +Wann werden geänderte Daten aus dem Puffer auf die Platte geschrieben? +\begin{itemize} + \item {STEAL:\\ + Bei Verdrängung au dem Puffer, auch vor ende der Transaktion} + \item {NO STEAL:\\ + Frühestens am Ende der Transaktion $\rightarrow$ kein UNDO erfoderlich (aber großen Puffer)} + + \item {FORCE:\\ + Spätestens am Ende der Transaktion $\rightarrow$ kein Partial Redo erfoderlich} + + \item {NO FORCE:\\ + Erst bei Verdränung aus dem Puffer} +\end{itemize} +Wie werden geänderte Daten aus dem Puffer auf Platte geschrieben? +\begin{itemize} + \item{ATOMIC:\\ + Indirekte Einbringstrategie.\\ + Ununterbrechbares Umschalten} + \item{NOT ATOMIC: + Direkte Einbringstrategie.\\ + Ist nicht ununterbrechbar. + } +\end{itemize} +\subsubsection{Protokolldaten} +Als Protollinformation zählt was über die Einbringungsstrategie hinaus +benötigt wird, um nach einem Systemausfall den jüngsten konsisten Zustand +wiederherzustellen. +\begin{figure}[H] + \begin{center} + \includegraphics[scale=0.6]{protokoll2.png} + \caption{Protokollinformationen} + \end{center} +\end{figure} + +\paragraph{Wann wird in Protokolldatei geschrieben?} +\begin{itemize} + \item{UNDO-Information:\\ + \begin{itemize} + \item bevor die zugehörigen Änderungen in Datenbestand eingebracht werden + \item sonst rücksetzen unmöglich + \end{itemize} + } + \item{REDO-Information:\\ + \begin{itemize} + \item muss geschrieben sein (in tmp Log Datei und Archivdatei), bevor der Abschluss der TA + an Programm bzw Benutzer gemeldet wird + \item sonst Wiederherstellung nicht möglich + \end{itemize} + } +\end{itemize} +\subsubsection{Backward-/Forward Recovery} +\begin{enumerate} + \item{ Forward:\\ + Änderungen sind noch nicht in DB, aber schon in Log. Bevor + diese auf DB geschrieben werden, wird ein Commit-Record in + Log File geschrieben. Falls was schief geht und der Commit Record noch da ist, werden alle diese Änderungen wiedehrolt und ansonsten nichts getan, da alte Version noch in DB steht.} + \item{ Backward:\\ + Ins Log kommt immer \textbf{alte} Version eines Wertes. Bei + einem Commit wird gewartet bis alle neuen werte in DB stehen. + Danach erst wird CommitRecord erstellt und eine Bestätigung + signalisiert. + Bei Verlust werden entweder alte Daten hergestellt oder nichts getan.} +\end{enumerate} +\paragraph{Vergleich} +\begin{itemize} + \item{ Forward Recovery: Hoher Speicherplatzbedarf! Daten werden erst nach Beendigung der TA in DB geschrieben und deswegen solange in Puffer behalten} + \item{ Backward-Recovery: Hoher I/O Aufwand! Alle Änderungen müssen vor TA-Ende in Datenfiles stehen.} +\end{itemize} +\subsubsection{Undo-/Redo Logging} +Verbesserung zu Backward-/Forward Recovery. +\begin{figure}[H] + \begin{center} + \includegraphics[scale=0.8]{protokoll.png} + \caption{Physische Protokollierung} + \end{center} +\end{figure} +Zustände vor bzw nach einer Änderungen werden protokolliert: +\begin{itemize} + \item alter Zustand: Before Image (BI) für UNDO + \item neuer Zustand: After Image (AI) für REDO + \item für jede veränderte Seite (3) wird jeweils eine + vollständige Kopie vor (2) und nach (4) der Änderung in den Log + geschrieben.\\ + $+$ schnelle Recovery\\ + $-$ hoher E/A Aufwand +\end{itemize} +\paragraph{Optimierungen} +Um Log-Aufwand zu reduzieren nur geänderte \textbf{Teile einer Seite} +protokollieren.\\ +Sammlung und Pufferung im HS: +\begin{itemize} + \item $+$ reduzierter E/A Aufwand + \item $-$ komplexeres und zeitaufwändigeres Recovery\\ + Zurückspeichern gleicht eher dem Neu einfügen (freien Platz suchen, TID vergeben), da Stelle von wo Einträge stammen andersweitig genutzt werden können +\end{itemize} + +\subsubsection{Sicherungspunkte} +Ma"snahmen zur Begrenzung des REDO Aufwands nach Systemfehlern (alle +erfolgreichen Änderungen die im Puffer verloren gegangen sind müssen wiederholt werden $\rightarrow$ nicht praktikabel! +\paragraph*{Methoden} +\begin{itemize} + \item{ \textbf{Transaction-Oriented Checkpoint}\\ + Geänderte Seiten einer TA nach TA-ende sofort in DB bringen (siehe FORCE) $\rightarrow$ zu hohe Belastung} + \item{ \textbf{ Transaction-COnsisten Checkpoint} + \begin{itemize} + \item Einbringung aller Änderung erfolgreicher TA's + \item Lesesperee auf ganzer DB zum Zeitpunkt des Sicherungspunktes + \item Verzögerung von TA's + \item Sicherungspunkt begrenzt Undo und Redo Recovery + \end{itemize} + } + \item{ \textbf{Action-Consisten Checkpoint} + \begin{itemize} + \item Zum Zeitpunkt des Sicherungspunktes dürfen keine Änderunen aktiv sein + \item Begünstigt nur Recovery, dafür kürzere Totzeit von System + \end{itemize} + } +\end{itemize} +\subsubsection{Allgemeine Restart Prozedur} +\textbf{3-phasiger Ansatz} +\begin{enumerate} + \item Analyse Lauf + Vom letzten Checkpoint bis zum Log Ende. Bestimmung von Gewinner und Verlierer TA's, sowie Seiten, die von ihnen geändert wurden + \item Undo Lauf \\ + Rücksetzen der Verlierer TA's durch Rückwärtslesen des Logs bis zum BOT Satz der ältesten Verlierer TA + \item Redo Lauf \\ + Vorwärtslesen des Logs (Startpunkt abhängig von Checkpoint Typ) und Änderungen der Gewinner TA's wiederholen +\end{enumerate} +