Transaktionen Kapitel um Übungen erweitert. Rename

IDB.tex

@@ -320,8 +320,26 @@ wiederherzustellen.
 						\end{itemize}
 				}
 \end{itemize}
-\subsubsection{Physische Protokollierung}
-\vspace{5pt}
+\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}
@@ -335,8 +353,8 @@ Zustände vor bzw nach einer Änderungen werden protokolliert:
 		\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
+				$+$ schnelle Recovery\\
+				$-$ hoher E/A Aufwand
 \end{itemize}
 \paragraph{Optimierungen}
 Um Log-Aufwand zu reduzieren nur geänderte \textbf{Teile einer Seite}
@@ -353,7 +371,7 @@ 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{Tranaction-Oriented Checkpoint}\\
+		\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}
@@ -375,9 +393,10 @@ erfolgreichen Änderungen die im Puffer verloren gegangen sind müssen wiederhol
 \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
+		\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 ovn Checkpoint Typ) und Änderungen der Gewinner TA's wiederholen
+		\item Redo Lauf \\
+				Vorwärtslesen des Logs (Startpunkt abhängig von Checkpoint Typ) und Änderungen der Gewinner TA's wiederholen
 \end{enumerate}
+
 \end{document}

Makefile

@@ -1,4 +1,4 @@
-PDF = Transaktionen
+PDF = IDB
 
 all: $(PDF)