diff --git a/idb_skript/.gitignore b/idb_skript/.gitignore new file mode 100644 index 0000000..c1647c2 --- /dev/null +++ b/idb_skript/.gitignore @@ -0,0 +1,10 @@ +*.fls +*.lof +*.swp* +*.pdf +*.aux +*.out +*.log +*.toc +*.fdb* +X.tex diff --git a/idb_skript/Anfrageverarbeitung.tex b/idb_skript/Anfrageverarbeitung.tex new file mode 100644 index 0000000..4acece2 --- /dev/null +++ b/idb_skript/Anfrageverarbeitung.tex @@ -0,0 +1,86 @@ +\section{Anfrageverarbeitung} + +\subsection{Allgemein} +Eine SQL Anfrage ist ein mengenorientierter Zugriff. +D.h. diese mengenorientierten Operatoren müssen auf satzorientierte +Operatoren abgebildet werden. +\subsubsection{Phasen} +\textbf{Verarbeitungsschritte}: +\begin{itemize} + \item Syntax überprüfen + \item Rechte und Integritätsbedingungen (Formate) prüfen + \item \textbf{Anfrageoptimierung} um effizient Query zu bearbeiten + \item Code Generieung +\end{itemize} +\begin{figure}[H] + \begin{center} + \includegraphics[scale=0.7]{pics/anfrageverarbeitung.png} + \caption{Phasen der Anfrageverarbeitung} + \end{center} +\end{figure} +\textbf{Ziel}:\\ +Umsetzung deskriptiver Anfragen in eine \glqq optimale\grqq Folge +interner DBS-Operationen +\subsection{Interndarstellung} +\subsubsection{Relationale Algebra} +Definition von relationalen \textbf{logischen Operatoren}: +\begin{itemize} + \item Selektion: Auswahl von \glqq Zeilen\grqq (\textbf{where}-Klausel) + \item Projektion Auswahl von \glqq Spalten\grqq (\textbf{select}-Klausel) +\item Kreuzprodukt: Konkatenation derjenigen Tupel aus zwei Relationen(\textbf{from}) + \item Verbund: Konkatenation derjenigen Tupel aus zwei Relationen + die eine Bedingung erfüllen(\textbf{from-where}) + \item Mengenoperationen auf zwei Relationen: + \begin{itemize} + \item $R \cup S$ bzw \textbf{UNION(R,S)} + \item $R \cap S$ bzw \textbf{INTERSECT(R,S)} + \item $R \setminus S$ bzw \textbf{EXCEPT(R,S)} + \end{itemize} +\end{itemize} +\subsubsection{Operatorbaum} +Beispiel: +\begin{lstlisting} +select Name, Beruf +from Abt a, Pers p, + PM pm , Projekt pj + where a.ANr = p.ANr + and a.AOrt = "Erlangen" + and p.PNr = pm.PNr + and pm.JNr = pj.JNr + and pj.POrt = "Erlangen" +\end{lstlisting} + +\begin{figure}[H] + \begin{center} + \includegraphics[scale=0.7]{pics/operatorbaum.png} + \caption{Operatorbaum} + \end{center} +\end{figure} +Blattknoten: Relationen\\ +Gerichtete Kanten: Datenfluss\\ +Knoten: Operatoren der Relationalen Algebra +\subsection{Restrukturierung} +Regeln: +\begin{enumerate} + \item Ein n-facher Verbund kann durch eine Folge von binären Verbunden ersetzt und werden und umgekehrt + \item Verbund ist kommutativ + \item Verbund ist assoziativ + \item Selektionen können zusammengefasst werden + \item Projektionen können zusammengefasst werden + \item Selektionen und Projektionen dürfen vertauscht werden + \item Selektionen und Verbund dürfen vertauscht werden + \item Selektion darf mit Vereinigung und Differenz vertauscht werden + \item Selektion und Kreuzprodukt können zu Verbund zusammengefasst weren +\end{enumerate} +\subsubsection{Algorithmus} +\textbf{Ziel}: Kreuzprodukt vermeiden +Heuristik: +\begin{itemize} + \item komplexe Verbundoperationen zerlegen in binäre Verbunde (Regel 1) + \item Selektionen mit mehreren Prädikat Termen separieren in Selektionen mit jeweils einem Prädikat Term (Regel 4) + \item Selektionen so früh wie möglich ausführen (Regel 7 und 8) + \item Selektionen und Kreuzprodukt zu Verbund zusammenfassen, wenn + das Selektionsprädikat Attribute aus den beiden Relationen verwendet (Regel 9) + \item Projektionen so früh wie möglich ausführen, allerdings nicht vor Selektion und Mengenoperationen. + +\end{itemize} diff --git a/idb_skript/BBaum.tex b/idb_skript/BBaum.tex new file mode 100644 index 0000000..051f317 --- /dev/null +++ b/idb_skript/BBaum.tex @@ -0,0 +1,112 @@ +\section{BBaum} +Idee: Zusammenfassung ganz bestimmter Sätze in einem Block. +Mehrwegbaum: jeder Knoten entspricht einem Block. + +\subsection{Aufbau} +Am Anfang eines jeden Knotens steht $n$. $n$ ist Anzahl der verwendeten +Einträge, $k \leq n \leq 2k$ (in root $ 1 \leq n \leq 2k$). + +\begin{figure}[H] + \begin{center} + \includegraphics[scale=1.0]{pics/bbaumknoten.png} + \caption{BBaum Knoten} + \end{center} +\end{figure} +Danach folgen Tripel (Ki,Di,Pi) welche einen \textbf{Eintrag} bilden: +Ki = Schlüsselwert\\ +Di = Datensatz\\ +Pi = Zeiger auf Nachfolgeknoten +\subsection{Eigenschaften} +\begin{itemize} + \item jeder Pfad ist perfekt balanciert + \item jeder Knoten mit Ausnahme von root und Blättern hat + mindesten $k+1$ Nachfolger und höchstens $2k+1$ + \item jeder Knoten (Ausnahme root) immer mindestens halb voll +\end{itemize} +\subsection{Löschvorgang} +\begin{enumerate} + \item Suche Knoten, in dem der zu löschende Schlüssel S liegt + \item Falls S in Blattknoten, dann lösche S und behandle ggf Unterlauf + \item Fall S in innerem Knoten dann untersuche linken und rechten + Unterbaum von S + \begin{itemize} + \item finde direkten Vorgänger $\text{S}'$ und Nachfolger $\text{S}''$ + \item Wähle den aus der mehr Elemente hat + \item Ersetze zu löschenden Schlüssel S durch $\text{S}'$ oder $\text{S}''$ aus gewähltem Blattknoten und behandle ggf Unterlauf + + \end{itemize} +\end{enumerate} +\subsection{Unterlauf} +\begin{itemize} + \item Ein endgülter Unterlauf entsteht bei obigen Algorithmus erst auf Blattebene + \item \textbf{Unterlaufbehandlung} wird durch Mischen des Unterlaufknotens mit seinem Nachbarknoten und darüber liegenden Diskriminator durchgeführt $\rightarrow$ Splitt rückwärts + \item Unterlaufbehandlung endet in einem der Blätter! +\end{itemize} +\subsection{B*-Baum} +Alle Sätze werden in den Blattknoten abgelegt. Innere Knoten enthalten nur noch Verzweigungsinformationen, keine Daten. +Am Ende eines Knotens ist ein Zeiger auf den nächsten enthalten. +\begin{figure}[H] + \begin{center} + \includegraphics[scale=1.0]{pics/bstern.png} + \caption{B*-Baum Aufbau} + \end{center} +\end{figure} +\textbf{Merke:}\\ +Beim Löschen von Werten bleibt der gleiche Diskriminator in inneren +Knoten enthalten. +\subsubsection{Löschen} +Entsteht durch das Löschen ein Unterlauf? +\begin{itemize} + \item Nein:\\Entferne Satz aus Blatt + \item Ja:\\ + Mische das Blatt mit einem Nachbarknoten. Ist die + Summe der Einträge in beiden Knoten größer als 2k? + \begin{itemize} + \item Nein:\\ + Fass beide Blätter zu einem Blatt zusammen. Falls Unterlauf + in Vaterknoten entsteht: Misch die inneren Knoten analog + \item Ja:\\ + Teil die Sätze neu auf beide Knoten auf, so dass ein Knoten + jeweils die Hälfte der Sätze übernimmt. Der Diskriminator ist + zu aktualisieren. + + \end{itemize} +\end{itemize} +\subsection{Vergleich} +\begin{itemize} + \item BBaum: + \begin{itemize} + \item keine Redundanz + \item lesen von Baum Inorder nur mit Stack von Höhe h + \item Gergingerer Verzweigungsgrad $\rightarrow$ größere Höhe + \item einige wenige Sätze (root) mit 1 Blockzugirff + \end{itemize} + \item $\text{B}^*$Baum: + \begin{itemize} + \item Schlüsselwerte teilweise redundant + \item Kette von Blattknoten liefert alle Sätze nach Reihenfolge sortiert + \item hohe Verzweigung der inneren Knoten $\rightarrow$ geringe Höhe + \item für alle Blöcke müssen h Sätze gelesen werden + \item Schlüsselwerte der inneren Knoten müssen nicht in den + Datensätzen vorkommen + \end{itemize} +\end{itemize} +\subsection{Bitmap Index} +\textbf{B-Bäume (und Hashing) machen nur Sinn bei hoher Selektivität! ($\approx 5\%$)} +Lege für jeden Schlüsselwert eine Bitliste an. Bitwert 1 bedeutet, der +Schlüssel hat im Satz den Wert zu dem die Liste gehört. 0 bedeutet er hat keinen anderen Wert.\\ +Gut bei Wertigkeiten bis ca. 500. Hilft bei einfacher und effizienter +Verknüpfung. + +\subsection{Primär- und Sekundär-Organisation} +\textbf{Primär-Organisation}:\\ +Bedeutung: Speicherung der Sätze selbst. + +\textbf{Sekundär-Organisation}:\\ +Bedeutung: verweist nur auf Sätze, die nach beliebigen anderen Kriterien +abgespeichert werden. Ist allerdings nur möglich, wenn Primärorganisation +Direktzugriff auf einzelnen Satz haben. + +$\rightarrow$ B-Baum/$\text{B}^*$Baum als Sekundär Organsiation (Di); +auch gestreute Speicherung als Sekundär Organsiation möglich (Buckets +[Schlüsseltwer,Satzadresse] Paare) diff --git a/idb_skript/Einfuehrung.tex b/idb_skript/Einfuehrung.tex new file mode 100644 index 0000000..2fab344 --- /dev/null +++ b/idb_skript/Einfuehrung.tex @@ -0,0 +1,39 @@ +\section{Einführung} +\subsection{Basiswissen} +\begin{enumerate} + \item {Warum ein Datenbanksystem benutzen? + \begin{itemize} + \item vielseitig verwendbar + \item Mehrbenutzerbetrieb + \item redundanzfrei + \item ausfallsicher + \item leistungsfähig + \end{itemize} + } + \item {Wozu dient Schichtenbildung in der Softwarearchitektur? + \begin{itemize} + \item Höhere Ebenen werden einfacher, weil sie tiefere benutzen können + \item Änderungen in höheren Ebenen haben keinen Einfluss auf tiefere + \item tiefere Ebenen können getestet werden, bevor höhere lauffähig sind + \item Optimierungen von unteren Ebenen + \end{itemize} + Schichtenmodell: + \begin{figure}[H] + \begin{center} + \includegraphics[scale=0.6]{pics/schichten.png} + \caption{Schichtenübersicht} + \end{center} + \end{figure} + + } + \item { Was tut eine Schicht: + \begin{itemize} + \item Realisiert einen bestimmten Dienst, den sie der Schnittstelle nach oben zur Verfügung stellt + \item Nimmt Dienste der darunter liegenden Schicht in Anspruch + \item Verbirgt darunter liegende Schicht vollständig und muss daher alle erforderlichen Funktionen anbieten + \end{itemize} + } + \item { Was bedeutet Datenunabhängigkeit einer Anwendung:\\ + Speichern und Wiedergewinnen von persistenten Daten + ohne Kenntnis der Details der Speicherung.} +\end{enumerate} diff --git a/idb_skript/IDB.tex b/idb_skript/IDB.tex new file mode 100644 index 0000000..45fc0c8 --- /dev/null +++ b/idb_skript/IDB.tex @@ -0,0 +1,113 @@ +\listfiles +\documentclass[12pt,a4paper]{scrartcl} +\usepackage[utf8]{inputenc} +\usepackage[ngerman]{babel} +\usepackage{graphicx} +\usepackage{amsmath} +\usepackage{amssymb} +\usepackage{amsfonts} +\usepackage{lmodern} +\usepackage{a4wide} +\usepackage{psfrag} +\usepackage{colortbl} +\usepackage{color} +\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} +\usepackage{datetime} +\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=sql, % 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} +% wrapping environment for pic in paragraphs +\usepackage{floatflt} +% Einruecken nach newline via '//' unterbinden +\setlength{\parindent}{0pt} + +\makeatletter +\renewcommand\paragraph{% + \@startsection{paragraph}{4}{0mm}% + {-\baselineskip}% + {.5\baselineskip}% +{\normalfont\normalsize\bfseries}} +\makeatother + +%==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} +}% +%---------------------------------------------------- + +\title{IDB Skript} +\date{\today ~- \currenttime ~Uhr} +\begin{document} +\maketitle +\noindent{Dieses Skript zur Vorlesung Implementierung von + Datenbanksystemen im Wintersemester 2013/14 wurde von + untenstehenden Studenten erarbeitet. Es ist somit + offensichtlich inoffiziell und erhebt weder einen + Anspruch auf Korrektheit noch auf Vollständigkeit. +} + +\begin{description} + \item[Christian Bay] christian.bay@studium.fau.de +\end{description} + +\vfill + +\noindent { + \textbf{\footnotesize Dieses Skript ist keine offizielle + Veröffentlichung des Lehrstuhls 6 am Department Informatik der + Friedrich-Alexander-Universität Erlangen-Nürnberg.} +} + +\newpage + +\tableofcontents +\listoffigures +\newpage +\include{./Einfuehrung} +\include{./Saetze} +\include{./BBaum} +\include{./Puffer} +\include{./Programmschnittstellen} +\include{./Speicherung} +\include{./Anfrageverarbeitung} +\include{./Relationale_Operatoren} +\include{./Transaktionen} + +\end{document} diff --git a/idb_skript/Makefile b/idb_skript/Makefile new file mode 100644 index 0000000..ed0a8ed --- /dev/null +++ b/idb_skript/Makefile @@ -0,0 +1,18 @@ +PDF = IDB + +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 + +.PHONY: all clean $(PDF) continuous diff --git a/idb_skript/Programmschnittstellen.tex b/idb_skript/Programmschnittstellen.tex new file mode 100644 index 0000000..239a960 --- /dev/null +++ b/idb_skript/Programmschnittstellen.tex @@ -0,0 +1,56 @@ +\section{Programmschnittstellen} +Vor- und Nachteile:\\ +Programmzugriff: +\begin{itemize} + \item Keine SQL Injection nötig + \item Kompakt + \item spezieller Übersetzer nötig +\end{itemize} +Unterprogrammaufruf +\begin{itemize} + \item Optimierung und Typprüfung + \item SQL Injection möglich + \item Aufwändig für Programmierer +\end{itemize} +\subsection{SQL Anfrage} +Aufruf einer SQL Anfrage mit Index: +\begin{lstlisting}[language=java] +RecordFile index = new KeyedRecordFile("KNr","r"); +TID tid = index.read.Key(23); +RecordFile saetze = new DirectRecord(Kunden", "r"); +Record ergebnis = saetze.read(tid); +print(ergebnis.toString()); +\end{lstlisting} +Aufruf einer SQL Anfrage ohne Index: +\begin{lstlisting}[language = java] +RecordFile saetze = new DirectRecordFile("Kunden","r"); +Record ergebnis; +while (saetze.hasNext()){ + ergebnis = saetze.next(); + if(ergebnis.getKNr() == 23){ + print(ergebnis); + break; + } +} +\end{lstlisting} + +\subsection{SQL Schnittstelle} +\begin{enumerate} + \item Verbindung aufbauen + \begin{lstlisting}[language=java] + Connection DriverManager.connect(username, password, database) + \end{lstlisting} + \item Methode um eine Anfrage auszuführen + \begin{lstlisting}[language=java] + Handle Connection.executeQuery (String query); + \end{lstlisting} + \item Methode um zu prüfen, ob es weitere Ergebnisse gibt + \begin{lstlisting}[language=java] + Boolean Handle.hasNext(); + \end{lstlisting} + \item Methode um überhaupt an Ergebnisse zu kommen + %TODO das soll vermutlich weder vom Typ Boolean sein, noch hasNext() heißen + \begin{lstlisting}[language=java] + Boolean Handle.hasNext(); + \end{lstlisting} +\end{enumerate} diff --git a/idb_skript/Puffer.tex b/idb_skript/Puffer.tex new file mode 100644 index 0000000..8c880c6 --- /dev/null +++ b/idb_skript/Puffer.tex @@ -0,0 +1,61 @@ +\section{Puffer} +Frame = Im HS vorgesehener Platz zur Aufnahme eines Blocks $\rightarrow$ normalerweise so groß wie Block + +Bei Zugriff auf Blöcke im HS müssen diese ggf eingelagert werden. +\subsection{Ersetzungsstrategie} +\begin{itemize} + \item wählt den zu verdrängenden Block aus + \item Ziel: Minimierung von physischen Zugriffen +\end{itemize} + +\subsubsection{FIFO} +Block der am längsten im Puffer ist wird ersetzt.\\ $\rightarrow$ ungünstig +da häufig benutzte Blöcke gerade im Puffer bleiben sollen + +\subsubsection{LFU (least frequently used)} +Block auf den am seltensten zugegriffen wird ersetzt. +\begin{itemize} + \item $-$ für sequentielles Lesen nicht brauchbar + \item $-$ hat ein Block einmal wieder zugegriffen bleibt der lange erhalten +\end{itemize} + +\subsubsection{LRU (least recently used)} +\begin{itemize} + \item bewertetes Alter seit dem letzten Zugriff + \item quasi verkettete Liste aller Blöcke im Puffer, wo bei Verdrängung letzter Block der Kette ersetzt wird +\end{itemize} +\begin{figure}[H] + \begin{center} + \includegraphics[scale=0.7]{pics/lru.png} + \caption{LRU} + \end{center} +\end{figure} +\subsubsection{Clock} +LRU Verhalten mit einfacher Implementierung. +\textbf{Prinzip}: +\begin{itemize} + \item Benutzt(Dirty)-Bit eines Blocks im Puffer wird bei Zugriff auf + 1 gesetzt + \item bei Verdrängung zyklischer Suche mit dem Auswahlzeiger: + \begin{itemize} + \item Falls Benutzt Bit = 1, wird es auf 0 gesetzt $\rightarrow$ Zeiger wandert zum nächsten Block + \item Falls Benutzt Bit = 0, Block wird ersetzt + \end{itemize} +\end{itemize} + +\subsection{Dienste einer Pufferverwaltung} +Einkapselung der Pufferverwaltung: +\begin{lstlisting}[language=C] +char * Buffer::fix (BlockFile File, int BlockNo, char Mode); +\end{lstlisting} +\begin{itemize} + \item Block ist vor Verdrängung geschützt + \item \textbf{Mode} gibt an welcher Block nur gelesen oder auch + geändert werden soll +\end{itemize} +\begin{lstlisting} +void Buffer::unix (char * BufferAddresse) +\end{lstlisting} +\begin{itemize} + \item gibt Block im Puffer zur Ersetzung frei +\end{itemize} diff --git a/idb_skript/Relationale_Operatoren.tex b/idb_skript/Relationale_Operatoren.tex new file mode 100644 index 0000000..17f8c8c --- /dev/null +++ b/idb_skript/Relationale_Operatoren.tex @@ -0,0 +1,196 @@ +\section{Relationale Operatoren} +\subsection{Allgemein} +Die grundsätzliche Aufgabe besteht darin die logischen Operatoren +(SEL(),PROJ(),JOIN(),\ldots) durch \textbf{Planoperatoren} zu ersetzen.\\ +\textbf{Teilaufgaben}: +\begin{itemize} + \item Erkennung gemeinsamer Teilbäume (notwendig: Zwischenspeicherung + von Ergebnisrelation) + \item {Bestimmung der Verknüpfungsreihenfolge bei Verbundoperationen: + \begin{itemize} + \item Ziel: minimale Kosten für die Operationsfolge + \item Heuristik: Minimierung der Größe der Zwischenergebnisse, + d.h. kleinsten Relationen immer zuerst verknüpfen + \end{itemize} + } + \item Gruppierung von direkt benachbarten Operatoren zu einem einzelnen Planoperator (z.B. Verbund mit Selektion) +\end{itemize} +\subsection{Planoperatoren} +SQL erlaubt Anfragen über k-Relationen: +\begin{itemize} + \item Ein Variablen Ausdrücke (eine Relation) + \item Zwei Variablen Ausdrücke (zwei Relationen) + \item k-Variablen Ausdrücke (zerlegt in Ein- und Zwei Variablen Ausdrücke) +\end{itemize} + +\subsubsection{Selektion} +\begin{itemize} + \item Nutzung eines \textbf{Scan}-Operators\\ + Definition von Start- und Stoppbedingungen sowie Suchargumenten + \item Index Scan $\rightarrow$ Auswahl des kostengünstigsten Index + \item Relationen Scan +\end{itemize} +\subsubsection{Projektion} +\begin{itemize} + \item meist in Kobination mit Verbund, Selektion und Sortierung + \item auch als eigener Planoperator +\end{itemize} +\subsubsection{Sortierung} +\begin{itemize} + \item erforderlich bei \textbf{order by} + \item beschleunigt ggf Joins + \item Duplikateleminierung (\textbf{distinct}) +\end{itemize} +\subsubsection{Joins} +Joins werden in \textbf{binäre} Verbunde gegliedert. Bei $n$ Verbunden +sind $n!$ Reihenfolgen möglich. Die optimale Reihenfolge ist abhängig von +\begin{itemize} + \item Planoperatoren + \item passenden Sortierordnungen + \item Größe der Operanden usw +\end{itemize} +Verbundoperationen sind sehr häufig und auch teuer $\rightarrow$ Optimierung.\\ +Typisch sind \textbf{Gleichverbunde}. +Standartszenario für Verbunde: +\begin{lstlisting} +select * from R,S +where R.VA $\Theta$ S.VA // Verbundpraedikat + // $\Theta \in \{=, >, <, \neq, \geq, \leq\}$ +and P(R.SA) // lokale Selektion +and P(S.SA) // VA = Verbundattribut + // SA = Selektionsattribut + +\end{lstlisting} +\paragraph{Nested Loop Verbund} + +Annahmen:\\ +Sätze in R und S sind nicht nach Verbundsattributen geordnet.\\ +Es sind keine Indexstrukturen $I_R(VA)$ und $I_S(VA)$ vorhanden. +\begin{lstlisting} +Scan ueber $S$; //aeussere Schleife +fuer jeden Satz s, fuer den $P(s.SA)$ gilt: + Scan ueber $R$; //innere Schleife + fuer jeden Satz r, + fuer den P(r.SA) AND (r.VA $\Theta$ s.VA) gilt: + uebernimm kombinierten Satz (r,s) + in das Ergebnis; +\end{lstlisting} +Komplexität: $\mathcal O(N^2)$ + +\paragraph{Sort-Merge Verbund} + + +Zweiphasiger Algorithmus:\\ + +Phasen: +\begin{enumerate} + \item Sortierung von R und S nach R.VA und S.VA, dabei Eliminierung nicht benötigter Tupel (durch Prüfung von P(R.SA) oder P(S.SA)) + \item schritthaltende Scans über R- und S-Relationen mit Durchführung des Verbundes bei r.VA=s.VA +\end{enumerate} + +Komplexität: $\mathcal O(N \log N)$ +\begin{figure}[H] + \begin{center} + \includegraphics[scale=0.7]{pics/merge_sort_join.png} + \caption{Merge Sort Verbund} + \end{center} +\end{figure} + +\paragraph{Hash Verbund} +Spezialisierung für \textbf{Gleichverbund}. +Da der Hauptspeicher immer größer ist, lassen sich Zwischenergebnisse +besser ausnutzen.\\ +Idee: +\begin{itemize} + \item Tupel der einen Relation im HS ablegen, so dass sie über VerbundAttribut schnell gefunden werden können + \item Tupel der anderen Relation sequenziell durchlaufen und mit Wert + des VerbundAttributs die passenden Verbundpartner im HS aufsuchen + \item Organisation der Tupel im HS über \textbf{Hashing} +\end{itemize} +Einfachster Fall: \textbf{Classic Hashing}:\\ +Funktionsweise:\\ +Äußere Schleife +\begin{itemize} + \item Abschnittweise lesen der kleineren Relation R + \item Relation wird in $p$ Abschnitte aufgeteilt, die alle in HS passen + \item Aufbau einer Hash Tabelle mit $\text{h}_\text{A}($r.VA$)$ +\end{itemize} +Innere Schleife +\begin{itemize} + \item Überprüfung für jeden Satz von S mit P(S.SA) $\rightarrow$ + ebenfalls mit Hashing + \item wenn sich Verbundpartner in dieser Adresse befindet, Durchführung des Verbundes +\end{itemize} +Komplexität: $\mathcal O(p \times N)$. Da Verbundpartner S $p$-mal gelesen werden muss. +\begin{figure}[H] + \begin{center} + \includegraphics[scale=0.8]{pics/hash_join.png} + \caption{Hash Verbund} + \end{center} +\end{figure} +Problem ist, dass S $p$-mal durchlaufen werden muss. Daher die Idee +S analog zu R zu partitionieren.\\ +Stichwort Simple Hashing. + +\subsection{Anfrageoptimierung} +Ziel:\\$\rightarrow$ Ermittlung des \textit{kostengünstigsten} +Auswertungsweges + +Zentrales Problem: +\begin{itemize} + \item globales Optimieren hat hohe Komplexität (NP-Schwer zur Laufzeit) + \item Einsatz von Heuristiken, da nicht alles nötige Wissen immer vorhanden ist +\end{itemize} +Optimierungsziel: +\begin{itemize} + \item Maximierung des Outputs bei gegeben Ressoucren + \item Minimierung der Resourcennutzung +\end{itemize} +Die Wichtigsten Kostenarten sind: +\begin{itemize} + \item Berechnungskosten (CPU) + \item I/O Kosten (Anzahl physischer Referenzen) +\end{itemize} + +\subsubsection{Ausführungsplan} +Ziel ist es eine möglichst guten Ausführungsbaum zu erstellen. +Problematisch ist die riesige Anzahl an Möglichkeiten mit steigender +Komplexität der Anfrage (z.B. Query mit 15 Verbunden $10^{70}$ Möglichkeiten).\\ +Diese Vielfalt entsteht durch verschiedene Implementierungen der Planoperatoren und der Operationsreihenfolgen. + +$\rightarrow$ \textbf{Ziel der Plangenerierung}: +\begin{itemize} + \item finden von Plänen gelingt immer schnell + \item mit möglichst wenig generierten Plänen auskommen +\end{itemize} +Unterschiedliche Strategieklassen: +\begin{itemize} + \item voll enumerativ + \item beschränkt enumerativ + \item zufallsgesteuert +\end{itemize} + +\paragraph{Kostenformeln} +\begin{itemize} + \item{ gewichtetes Ma"s für I/O und CPU Belastung:\\ + C = \#physische-Seitenzugriffe + W $\times$ \#Aufrufe-des Zugriffsystems} + \item{ CPU-bound : höherer I/O-, geringerer CPU Aufwand:\\ + $\text{W}_{\text{CPU}}$ = \#Instr-pro-Aufruf-des-Zugriffsystems /\\ \#Instr-pro-I/O-Vorgang + } + \item{ I/O-bound : geringere I/O-, höherer CPU Aufwand:\\ + $\text{W}_{\text{IO}}$ = \#Instr-pro-Aufruf-des-Zugriffsystems /\\ (\#Instr-pro-I/O-Vorgang + Zugriffzeit $\times $ MIPS-Ratte) + } +\end{itemize} + +\paragraph{Selektivitätsabschätzung} +Der \textbf{Selektivitätsfaktor} beschreibt den erwarteten Anteil an +Tupeln, die ein Prädikat p erfüllen.\\ +Diese Trefferate gibt auch an, inwiefern eine vorhandene Indexstruktur +die Laufzeit reduzieren. +\begin{figure}[H] + \begin{center} + \includegraphics[scale=1.0]{pics/trefferrate.png} + \caption{Qualitatives Zugriffsdiagramm} + \end{center} +\end{figure} +Nur bei sehr geringen Trefferraten lohnt sich ein Index Scan! diff --git a/idb_skript/Saetze.tex b/idb_skript/Saetze.tex new file mode 100644 index 0000000..0a8d589 --- /dev/null +++ b/idb_skript/Saetze.tex @@ -0,0 +1,61 @@ +\section{Sätze} +\subsection{Allgemein} +Warum wurden Sätze eingeführt? \\ +Sätze abstrahieren von Blöcken. Blöcke sind Hardware spezifisch. +Sie haben unterschiedliche Längen und die Aufgabe von Einheiten von +Platte und HS zu transportieren. Daher hat man eine anwendungspezifische +Einheit eingeführt, die Daten zusammenfasst.\\ +\subsection{Satzadresse} +Eine Satzadresse ist ein Bezeichner unter der man einen einzelnen Satz wiederfinden kann. Sie wird als stabil bezeichnet, wenn sich beim +verschieben des Satzes die Adresse nicht ändert. +$\rightarrow$ Neue Schicht über Blöcke +\subsection{Wechselpuffertechnik} +Optimierungsmöglichkeit bei sequenziellen Dateien. +Man verwendet \textit{zwei} Blockpuffer.\\ +Anwendung beim +\begin{itemize} + \item Lesen: während Sätze in Puffer 1 gelesen werden \textbf{gleichzeitig} nächsten Block von Platte in Puffer 2 lesen + \item Schreiben: wenn Puffer 1 voll, \textbf{asynchron} auf Platte schreiben und gleichzeitig Puffer 2 zur Aufnahme weiterer Sätze verwenden +\end{itemize} +\subsection{Satzzugriff über Schlüsselwerte} +\subsection{Normales Hashing} +Man möchte nun Sätze und deren Inhalt nicht nur über +die Satzadresse wiederfinden, sondern auch über \textbf{inhaltliche Kriterien}. +\textbf{Schlüssel} definieren ein oder mehrere Felder eines Satzes, über +das man den Satz wiederfinden kann. + +Lösung dafür ist \textbf{Hashing} der Sätze nach Schlüssel. + +Kollisionen verhindern: +\begin{itemize} + \item Open Addressing (ausweichen auf Nachbar Buckets) + \begin{itemize} + \item $+$ kein zusätzlicher Speicherplatz erforderlich + \item $-$ beim Suchen findet man im Bucket auch Überläufer + \item $-$ beim löschen Überläufer zurückholen + \item $-$ in Nachbarbuckets werden ggf weitere Überläufe erzeugt + \end{itemize} + \item Overflow Buckets + \begin{itemize} + \item Anlegen spezieller Überlauf Buckets für jeden Bucket + \begin{itemize} + \item $-$ zusätzlicher Speicherplatz erforderlich + \item $+$ keine Mischung von sätzen + \item $+$ keine Beeinträchtigung der Nachbarbuckets + \end{itemize} + \end{itemize} +\end{itemize} +\subsubsection{Bewertung} +\begin{itemize} + \item sehr schneller Zugriff über Schlüssel (1 bis 2 Blockzugriffe) + \item gestreute Speicherung kann nur nach \textbf{einem} Schlüssel erfolgen + \item Speicherplatz muss um voraus belegt werden +\end{itemize} +\subsection{Virtuelles Hashing} +Vorteile vom virtuellen Hashing ggü. normalen Hashing:\\ +Das normale Hashing ist nicht erweiterbar, d.h. man muss den gesamten +Speicher im voraus belegen. Dadurch kommt man in Platznot oder verschwendet zuviel. +Beim linearen Hashing versucht man durch kontinuierliche Reorganisation +Überlaufprobleme zu vermeiden. + +Beschreibung von Dateizustand: diff --git a/idb_skript/Speicherung.tex b/idb_skript/Speicherung.tex new file mode 100644 index 0000000..bee5118 --- /dev/null +++ b/idb_skript/Speicherung.tex @@ -0,0 +1,125 @@ +\section{Speicherung von Tupeln und Relationen} +\subsection{Ziele} +\begin{itemize} + \item Relationen mit Mitteln der darunter implementierten Schichten sichern + \item Anfragen (SQL) möglichst effizient auswerten +\end{itemize} +\subsection{Speicherung von Tupeln in Sätzen} +\subsubsection{Aufbau von Sätzen} +\begin{itemize} + \item Sätze sind aus \textbf{Feldern} zusammengesetzt (Name, Typ, Länge) + \item \textbf{Systemkatalog}\\Informationen über Felder und Reihenfolge +\end{itemize} +\subsubsection{Satztyp} +\begin{itemize} + \item Menge von Sätzen mit gleicher Struktur $\rightarrow$ einmalige + Beschreibung im Systemkatalog + \item beim Speichern eines Satzes wird ihm ein Satztyp zugeordnet + \item Länge der Sätze zumeist variabel +\end{itemize} +\textbf{Annahme: Reihenfolge der Felder egal} + +\subsubsection{Anforderungen} +\textbf{Speicherplatzeffizienz}: +\begin{itemize} + \item variable Länge + \item undefinierte Werte nicht speichern + \item Hilfsstrukturen minimieren +\end{itemize} + +\textbf{direkter Zugriff auf Felder}: +\begin{itemize} + \item ohne vorher andere Felder lesen zu müssen + \item direkt zur Anfangs-Byte-Position innerhalb des Satzes +\end{itemize} + + +\textbf{Flexibilität}: +\begin{itemize} + \item Hinzufügen von Feldern bei allen Sätzen + \item Löschen eines Feldes aus allen Sätzen +\end{itemize} + +\subsubsection{Speicherungsstruktur im Satz} +Der Satz wird in zwei logische Teile untergliedert. Einer beinhaltet +alle Felder fester Länge und der andere alle der variablen. +Mit Katalogdaten und Längenangaben im Satz, lässt sich \textbf{flexibel} +und \textbf{direkt} auf die Felder zugreifen. + +\begin{figure}[H] + \begin{center} + \includegraphics[scale=1.0]{pics/satz_speicherstruktur.png} + \caption{Variable Satz Speicherstruktur} + \end{center} +\end{figure} +Würden man alle Felder mit den Zeiger erreichen, wäre das Speicherplatzverschwendung. +So sind alle Felder fester Größe direkt erreichbar. +\textbox{Speicheurngsstruktur in Sätzen}{ + Blatt 9 Aufgabe 2 üben. +} +\subsection{Speicherung von Relationen} +\subsubsection{Spaltenweise Speicherung (C-Store)} +\begin{itemize} + \item Auf das Lesen hin optimiert. Gut für Auswertung + großer Datenmengen + \item Nur Attribute lesen, die gebraucht werden + \item kompakte Speicherung der Attributwerte +\end{itemize} +\textbf{Prototyp} +\begin{itemize} + \item speichert Sammlung von Spaltengruppen + über mehrere Sätze verteilt + \item Sortierschlüssel ist ein Attribut + \item Gruppen von Spalten = Projektion + \item Speicherung + \begin{itemize} + \item \textbf{Schreibspeicher} für schnelles Einfügen und Ändern von Tupeln + \item \textbf{Lesespeicher} für umfangreiche Analysen + \end{itemize} + \item Änderung durch Löschen und Einfügen durch Tuple Mover +\end{itemize} +\textbf{Projektionen} +\begin{itemize} + \item Die Projektionen besitzen ein oder mehrere Attribute aus einer logischen +Tablle (ggf durch Fremdschlüssel auch Attribute aus anderen Tabellen) + \item Duplikate bleiben erhalten + \item Als Sortierschlüssel wird eines der Attribute hergenommen +\end{itemize} +\textbf{Komprimierungen} +Abhängig von zwei Eigenschaften der Spalte: +\begin{itemize} + \item Sortierung (nach der Spalte selbst) : ja/nein + \item Anzahl der verschiedenen Werte: wenig/viel +\end{itemize} +\begin{enumerate} + \item sortiert mit wenigen verschiedenen Werten:\\ + organisiert in einem B-Baum mit + \begin{itemize} + \item dichter Packung $\rightarrow$ alle Seiten voll (keine Änderungen!) + \item und großen Seiten $\rightarrow$ geringe Höhe + \end{itemize} + \item unsortiert mit wenigen verschiedenen Werten:\\ + Offset-Indexe: B-Baum für Abbildung von Positiionen in einer Spalte auf die Werte in dieser Spaltebegin + \item sortiert mit vielen verschiedenen Werten:\\ + \begin{itemize} + \item B-Baum mit dichter Packung + \item Delta Codierung: Differenzen zum Vorgänger speichern + \end{itemize} + \item unsortiert mit vielen verschiedenen Werten + \begin{itemize} + \item unkomprimiert + \item B-Baum mit dichter Packung als sek. Organisation möglich + \end{itemize} +\end{enumerate} +\subsubsection{Ausführung von Anfragen} +\textbox{Schritte für Ausführung von Query:}{ +\begin{enumerate} + \item Syntaxprüfung + \item gibt es die Relation und Attribute + \item wie heißt Datei zur Relation + \item was für eine Datei ist das - direkt oder schlüsselbasiert + \item gibt es passende Projektionen + \item wo liegen die Verbund Indizes + \item müssen Partitionen zusammgeführt werden +\end{enumerate} +} diff --git a/idb_skript/Transaktionen.tex b/idb_skript/Transaktionen.tex new file mode 100644 index 0000000..0dc4461 --- /dev/null +++ b/idb_skript/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 Speicherungsstrukturen 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]{pics/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 ad 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]{pics/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]{pics/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 aus 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ängung 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]{pics/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 wiederholt 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]{pics/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 anderweitig 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 Lesesperre 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} + diff --git a/idb_skript/pics/TA_status.png b/idb_skript/pics/TA_status.png new file mode 100644 index 0000000..b2b50d2 Binary files /dev/null and b/idb_skript/pics/TA_status.png differ diff --git a/idb_skript/pics/anfrageverarbeitung.png b/idb_skript/pics/anfrageverarbeitung.png new file mode 100644 index 0000000..36e423f Binary files /dev/null and b/idb_skript/pics/anfrageverarbeitung.png differ diff --git a/idb_skript/pics/bbaumknoten.png b/idb_skript/pics/bbaumknoten.png new file mode 100644 index 0000000..6cb04ee Binary files /dev/null and b/idb_skript/pics/bbaumknoten.png differ diff --git a/idb_skript/pics/bstern.png b/idb_skript/pics/bstern.png new file mode 100644 index 0000000..5fb5445 Binary files /dev/null and b/idb_skript/pics/bstern.png differ diff --git a/idb_skript/pics/clock.png b/idb_skript/pics/clock.png new file mode 100644 index 0000000..011d660 Binary files /dev/null and b/idb_skript/pics/clock.png differ diff --git a/idb_skript/pics/hash_join.png b/idb_skript/pics/hash_join.png new file mode 100644 index 0000000..c41a8b5 Binary files /dev/null and b/idb_skript/pics/hash_join.png differ diff --git a/idb_skript/pics/komp_matrix.png b/idb_skript/pics/komp_matrix.png new file mode 100644 index 0000000..56f32b1 Binary files /dev/null and b/idb_skript/pics/komp_matrix.png differ diff --git a/idb_skript/pics/lru.png b/idb_skript/pics/lru.png new file mode 100644 index 0000000..d3a8303 Binary files /dev/null and b/idb_skript/pics/lru.png differ diff --git a/idb_skript/pics/merge_sort_join.png b/idb_skript/pics/merge_sort_join.png new file mode 100644 index 0000000..b15180c Binary files /dev/null and b/idb_skript/pics/merge_sort_join.png differ diff --git a/idb_skript/pics/operatorbaum.png b/idb_skript/pics/operatorbaum.png new file mode 100644 index 0000000..950df60 Binary files /dev/null and b/idb_skript/pics/operatorbaum.png differ diff --git a/idb_skript/pics/protokoll.png b/idb_skript/pics/protokoll.png new file mode 100644 index 0000000..0dc3a41 Binary files /dev/null and b/idb_skript/pics/protokoll.png differ diff --git a/idb_skript/pics/protokoll2.png b/idb_skript/pics/protokoll2.png new file mode 100644 index 0000000..bac9941 Binary files /dev/null and b/idb_skript/pics/protokoll2.png differ diff --git a/idb_skript/pics/satz_speicherstruktur.png b/idb_skript/pics/satz_speicherstruktur.png new file mode 100644 index 0000000..d62fbb0 Binary files /dev/null and b/idb_skript/pics/satz_speicherstruktur.png differ diff --git a/idb_skript/pics/schichten.png b/idb_skript/pics/schichten.png new file mode 100644 index 0000000..5377258 Binary files /dev/null and b/idb_skript/pics/schichten.png differ diff --git a/idb_skript/pics/sperrgranulat.png b/idb_skript/pics/sperrgranulat.png new file mode 100644 index 0000000..cf81190 Binary files /dev/null and b/idb_skript/pics/sperrgranulat.png differ diff --git a/idb_skript/pics/trefferrate.png b/idb_skript/pics/trefferrate.png new file mode 100644 index 0000000..fed5bf9 Binary files /dev/null and b/idb_skript/pics/trefferrate.png differ