From c9b437db2409e28155bdbed98866da1300cdd3da Mon Sep 17 00:00:00 2001 From: Christian Bay Date: Tue, 11 Feb 2014 17:38:35 +0100 Subject: [PATCH] =?UTF-8?q?Transaktionen=20Kapitel=20um=20=C3=9Cbungen=20e?= =?UTF-8?q?rweitert.=20Rename?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- Transaktionen.tex => IDB.tex | 35 +++++++++++++++++++++++++++-------- Makefile | 2 +- 2 files changed, 28 insertions(+), 9 deletions(-) rename Transaktionen.tex => IDB.tex (91%) diff --git a/Transaktionen.tex b/IDB.tex similarity index 91% rename from Transaktionen.tex rename to IDB.tex index 862ff8b..4da76ab 100644 --- a/Transaktionen.tex +++ b/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} diff --git a/Makefile b/Makefile index b6d90e3..a1a0dda 100644 --- a/Makefile +++ b/Makefile @@ -1,4 +1,4 @@ -PDF = Transaktionen +PDF = IDB all: $(PDF)