mirror of
https://gitlab.cs.fau.de/ik15ydit/latexandmore.git
synced 2024-12-24 09:06:06 +01:00
typos in chap. 6, 7, 8, 9
This commit is contained in:
Christian Strate
parent
473b8187bf
commit
8bff52d98a
@ -25,8 +25,8 @@ interner DBS-Operationen
|
||||
\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 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})
|
||||
@ -80,7 +80,7 @@ Heuristik:
|
||||
\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 Selektioinsprädikat Attribute aus den beiden Relationen verwendet (Regel 9)
|
||||
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}
|
||||
|
||||
@ -19,7 +19,7 @@ Die grundsätzliche Aufgabe besteht darin die logischen Operatoren
|
||||
SQL erlaubt Anfragen über k-Relationen:
|
||||
\begin{itemize}
|
||||
\item Ein Variablen Ausdrücke (eine Relation)
|
||||
\item Zwei Variablem AUsdrücke (zwei Relationen)
|
||||
\item Zwei Variablen Ausdrücke (zwei Relationen)
|
||||
\item k-Variablen Ausdrücke (zerlegt in Ein- und Zwei Variablen Ausdrücke)
|
||||
\end{itemize}
|
||||
|
||||
@ -72,7 +72,7 @@ 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)
|
||||
uebernimm kombinierten Satz (r,s)
|
||||
in das Ergebnis;
|
||||
\end{lstlisting}
|
||||
Komplexität: $\mathcal O(N^2)$
|
||||
@ -156,7 +156,7 @@ Die Wichtigsten Kostenarten sind:
|
||||
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 Operationsreiehenfolgen.
|
||||
Diese Vielfalt entsteht durch verschiedene Implementierungen der Planoperatoren und der Operationsreihenfolgen.
|
||||
|
||||
$\rightarrow$ \textbf{Ziel der Plangenerierung}:
|
||||
\begin{itemize}
|
||||
@ -178,11 +178,11 @@ Unterschiedliche Strategieklassen:
|
||||
$\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{CPU}}$ = \#Instr-pro-Aufruf-des-Zugriffsystems /\\ (\#Instr-pro-I/O-Vorgang + Zugriffzeit $\times $ MIPS-Ratte)
|
||||
$\text{W}_{\text{IO}}$ = \#Instr-pro-Aufruf-des-Zugriffsystems /\\ (\#Instr-pro-I/O-Vorgang + Zugriffzeit $\times $ MIPS-Ratte)
|
||||
}
|
||||
\end{itemize}
|
||||
|
||||
\paragraph{Selektivitätsanschätzung}
|
||||
\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
|
||||
|
||||
@ -14,7 +14,7 @@
|
||||
\begin{itemize}
|
||||
\item Menge von Sätzen mit gleicher Struktur $\rightarrow$ einmalige
|
||||
Beschreibung im Systemkatalog
|
||||
\item beim speichern eines Satzes wird im ein Satztyp zugeordnet
|
||||
\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}
|
||||
@ -30,7 +30,7 @@
|
||||
\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
|
||||
\item direkt zur Anfangs-Byte-Position innerhalb des Satzes
|
||||
\end{itemize}
|
||||
|
||||
|
||||
|
||||
@ -23,7 +23,7 @@ Nebenläufigkeitsprobleme auftauchen.
|
||||
|
||||
\subsection{Konsistenzen:}
|
||||
\subsubsection{Physische Konsistenz:}
|
||||
Alle Speicheurngsstrukturen sind korrekt. Alle TID's stimmen etc.
|
||||
Alle Speicherungsstrukturen sind korrekt. Alle TID's stimmen etc.
|
||||
|
||||
\subsubsection{Logische Konsistenz:}
|
||||
Setzt Physische Konsistenz voraus.\\
|
||||
@ -64,7 +64,7 @@ Bedingungen sind erfüllt (Assertions).
|
||||
\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.
|
||||
ausgelegt, dies würde ad adsurdum geführt durch Serialisierung.
|
||||
Was tun im Fehlerfall
|
||||
|
||||
\subsubsection{Serialisierbarkeit}
|
||||
@ -214,7 +214,7 @@ Arten:
|
||||
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}
|
||||
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)}
|
||||
|
||||
@ -222,7 +222,7 @@ Wann werden geänderte Daten aus dem Puffer auf die Platte geschrieben?
|
||||
Spätestens am Ende der Transaktion $\rightarrow$ kein Partial Redo erfoderlich}
|
||||
|
||||
\item {NO FORCE:\\
|
||||
Erst bei Verdränung aus dem Puffer}
|
||||
Erst bei Verdrängung aus dem Puffer}
|
||||
\end{itemize}
|
||||
Wie werden geänderte Daten aus dem Puffer auf Platte geschrieben?
|
||||
\begin{itemize}
|
||||
@ -247,13 +247,13 @@ wiederherzustellen.
|
||||
|
||||
\paragraph{Wann wird in Protokolldatei geschrieben?}
|
||||
\begin{itemize}
|
||||
\item{UNDO-Information:\\
|
||||
\item{UNDO-Information:
|
||||
\begin{itemize}
|
||||
\item bevor die zugehörigen Änderungen in Datenbestand eingebracht werden
|
||||
\item sonst rücksetzen unmöglich
|
||||
\item sonst Rücksetzen unmöglich
|
||||
\end{itemize}
|
||||
}
|
||||
\item{REDO-Information:\\
|
||||
\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
|
||||
@ -266,7 +266,7 @@ wiederherzustellen.
|
||||
\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.}
|
||||
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.
|
||||
@ -304,7 +304,7 @@ 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
|
||||
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}
|
||||
@ -314,10 +314,10 @@ erfolgreichen Änderungen die im Puffer verloren gegangen sind müssen wiederhol
|
||||
\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}
|
||||
\item{ \textbf{ Transaction-Consisten Checkpoint}
|
||||
\begin{itemize}
|
||||
\item Einbringung aller Änderung erfolgreicher TA's
|
||||
\item Lesesperee auf ganzer DB zum Zeitpunkt des Sicherungspunktes
|
||||
\item Lesesperre auf ganzer DB zum Zeitpunkt des Sicherungspunktes
|
||||
\item Verzögerung von TA's
|
||||
\item Sicherungspunkt begrenzt Undo und Redo Recovery
|
||||
\end{itemize}
|
||||
@ -332,7 +332,7 @@ erfolgreichen Änderungen die im Puffer verloren gegangen sind müssen wiederhol
|
||||
\subsubsection{Allgemeine Restart Prozedur}
|
||||
\textbf{3-phasiger Ansatz}
|
||||
\begin{enumerate}
|
||||
\item Analyse Lauf
|
||||
\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
|
||||
|
||||
Loading…
Reference in New Issue
Block a user