commit b849313663e550cbea78352e42a0263a8fa0811b Author: Christian Bay Date: Tue Feb 11 12:10:35 2014 +0100 Init diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..e0e6f7d --- /dev/null +++ b/.gitignore @@ -0,0 +1,7 @@ +*.fls +*.pdf +*.aux +*.out +*.log +*.toc +*.fdb* diff --git a/Makefile b/Makefile new file mode 100644 index 0000000..b6d90e3 --- /dev/null +++ b/Makefile @@ -0,0 +1,22 @@ +PDF = Transaktionen + +all: $(PDF) + +continuous: $(PDF).continuous + +%.continuous: %.pdf + latexmk -jobname=$(@:%.continuous=%) -pvc -pdf $(@:%.continuous=%).tex + +$(PDF): $(PDF).pdf + +%.pdf: %.tex + latexmk -jobname=$(@:%.pdf=%) -pdf $< + +clean: + latexmk -c -f $(PDF).tex + +distclean: + latexmk -C -f $(PDF).tex + rm -f $(PDF).pdf + +.PHONY: all clean distclean $(PDF) continuous diff --git a/TA_status.png b/TA_status.png new file mode 100644 index 0000000..b2b50d2 Binary files /dev/null and b/TA_status.png differ diff --git a/Transaktionen.tex b/Transaktionen.tex new file mode 100644 index 0000000..862ff8b --- /dev/null +++ b/Transaktionen.tex @@ -0,0 +1,383 @@ +\documentclass[12pt,a4paper]{article} +\usepackage[utf8]{inputenc} +\usepackage[ngerman]{babel} +\usepackage{graphicx} +\usepackage{amsmath} +\usepackage{amssymb} +\usepackage{amsfonts} +\usepackage{lmodern} +\usepackage{psfrag} +\usepackage{colortbl} +\usepackage{color} +\usepackage{hyperref} +\usepackage{float} +\usepackage{listings} +\usepackage{lstautogobble} +\usepackage{wrapfig} +\newcommand{\RM}[1]{\MakeUppercase{\romannumeral #1{.}}} +\definecolor{dkgreen}{rgb}{0,0.6,0} +\definecolor{gray}{rgb}{0.5,0.5,0.5} +\definecolor{mauve}{rgb}{0.58,0,0.82} +\lstset{ + basicstyle=\footnotesize, % the size of the fonts that are used for the code + breakatwhitespace=false, % sets if automatic breaks should only happen at whitespace + breaklines=true, % sets automatic line breaking + captionpos=b, % sets the caption-position to bottom + commentstyle=\color{dkgreen}, % comment style + frame=single, % adds a frame around the code + keywordstyle=\color{blue}, % keyword style + language=C++, % the language of the code + mathescape=true, + autogobble, + numbers=left % where to put the line-numbers; possible values are (none, left, right) + %title=\lstname % show the filename of files included with \lstinputlisting; also try caption instead of title +} +\setcounter{secnumdepth}{4} +\setcounter{tocdepth}{4} +\setlength{\parindent}{0pt} +%==INFOBOXEN========================================= +%idee: http://tex.stackexchange.com/a/66822 +\usepackage[tikz]{bclogo} +\definecolor{YellowGreen}{rgb}{0.603922,0.803922,0.196078} +%\renewcommand\bcStyleTitre[1]{\large\textcolor{black}{#1}} +%textbox{Titel}{Text} +\newcommand{\textbox}[2]{% + \begin{bclogo}[couleur=YellowGreen,logo =, arrondi=0.2,barre=none]{#1}% + \vspace*{10pt}% + #2% + \end{bclogo} +}% +%textonlybox{Text} +\newcommand{\textonlybox}[1]{% + \begin{bclogo}[couleur=YellowGreen,logo =, arrondi=0.2,barre=none]{#1} + \end{bclogo} +}% +%---------------------------------------------------- + +\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{Physische Protokollierung} +\vspace{5pt} +\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{Tranaction-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 ovn Checkpoint Typ) und Änderungen der Gewinner TA's wiederholen +\end{enumerate} +\end{document} diff --git a/komp_matrix.png b/komp_matrix.png new file mode 100644 index 0000000..56f32b1 Binary files /dev/null and b/komp_matrix.png differ diff --git a/protokoll.png b/protokoll.png new file mode 100644 index 0000000..0dc3a41 Binary files /dev/null and b/protokoll.png differ diff --git a/protokoll2.png b/protokoll2.png new file mode 100644 index 0000000..bac9941 Binary files /dev/null and b/protokoll2.png differ diff --git a/sperrgranulat.png b/sperrgranulat.png new file mode 100644 index 0000000..cf81190 Binary files /dev/null and b/sperrgranulat.png differ