Datenbanktuning und deren Wirkungsweise
Visualisierung ausgewählter Szenarien
©2008
Diplomarbeit
130 Seiten
Zusammenfassung
Inhaltsangabe:Einleitung:
Effizienz, Effektivität sowie Performance im Datenbanksektor sind häufig mit der Vorstellung verbunden, dass Satz für Satz, Seite um Seite die zahlreichen Einführungen, Definitionen und Feststellungen zu rezipieren und verarbeiten seien, die zu diesem Thema publiziert wurden.
Doch die zu Beginn genannten Themen sind zugleich praxisnah und nur schwer mit Definitionen zu erfassen. Das Umfeld, in dem agiert wird, unterliegt keiner Limitation vielmehr existiert ein hoher Grad an Bewegungsfreiheit. Auch wenn es eine Vielzahl von Strategien und Lösungsvorschlägen in diesen Bereichen gibt, sind diese häufig rein theoretischer Natur und die praktische Anwendbarkeit bleibt ungewiss.
Diese Arbeit zeigt auf, welche Wirkungsweisen durch die Anwendung von Datenbanktechniken zur Performance-Optimierung zu erwarten sind. Der darauf aufbauende Visualisierungsteil beschäftigt sich mit der Umsetzung bestimmter, in dieser Arbeit ermittelter Wirkungsweisen in eine interaktive Testplattform.
Als Codd im Jahre 1970 in einem der IBM Research Laboratories einen Bericht über das relationale Modell verfasste, leitete er damit den Beginn einer neuen Ära von Datenbankmanagementsystemen ein. Die heutigen Datenbanken fußen auf zahlreichen Arbeiten, die dort ihren Ursprung hatten.
Im Laufe der Jahre wuchsen diese DBMS zu immer komplexer werdenden Systemen heran. Die stetige Steigerung des Datenaufkommens, die immer höhere Zahl an Zugriffen sowie die Interaktivität, die auf diese DBMS einwirkten, stellten diesen Bereich vor grundlegende Probleme im Verarbeitungsbereich.
Es musste eine ständig ansteigende Zahl an Datensätzen innerhalb einer zumutbaren Zeit verwaltet und abgefragt werden. Vor diesem Hintergrund waren Verzögerungen in der Verarbeitung mit Beginn des produktiven Einsatzes solcher DBMS eines ihrer Kernprobleme. Performante Anfragen, die eine zügige Verarbeitung garantieren, sind heute ein wesentlicher Bestandteil der Arbeit eines DBA.
DMBS bieten heutzutage verschiedenartige Komponenten an, welche den DBA hierbei unterstützen. Optimierer wie die Verwendung von Indizes, welche den schnellen Zugriff auf Daten über eine Art Register zulassen, sind ein Automatismus im DBMS selbst. Solche Optimierer bieten die Möglichkeit, bei einem lesenden Zugriff auf den Datenbestand zu entscheiden, ob der Zugriff auf die entsprechenden Daten über einen Index oder direkt auf die Tabelle erfolgen soll. Die Entscheidungsfindung, welche auf Basis […]
Effizienz, Effektivität sowie Performance im Datenbanksektor sind häufig mit der Vorstellung verbunden, dass Satz für Satz, Seite um Seite die zahlreichen Einführungen, Definitionen und Feststellungen zu rezipieren und verarbeiten seien, die zu diesem Thema publiziert wurden.
Doch die zu Beginn genannten Themen sind zugleich praxisnah und nur schwer mit Definitionen zu erfassen. Das Umfeld, in dem agiert wird, unterliegt keiner Limitation vielmehr existiert ein hoher Grad an Bewegungsfreiheit. Auch wenn es eine Vielzahl von Strategien und Lösungsvorschlägen in diesen Bereichen gibt, sind diese häufig rein theoretischer Natur und die praktische Anwendbarkeit bleibt ungewiss.
Diese Arbeit zeigt auf, welche Wirkungsweisen durch die Anwendung von Datenbanktechniken zur Performance-Optimierung zu erwarten sind. Der darauf aufbauende Visualisierungsteil beschäftigt sich mit der Umsetzung bestimmter, in dieser Arbeit ermittelter Wirkungsweisen in eine interaktive Testplattform.
Als Codd im Jahre 1970 in einem der IBM Research Laboratories einen Bericht über das relationale Modell verfasste, leitete er damit den Beginn einer neuen Ära von Datenbankmanagementsystemen ein. Die heutigen Datenbanken fußen auf zahlreichen Arbeiten, die dort ihren Ursprung hatten.
Im Laufe der Jahre wuchsen diese DBMS zu immer komplexer werdenden Systemen heran. Die stetige Steigerung des Datenaufkommens, die immer höhere Zahl an Zugriffen sowie die Interaktivität, die auf diese DBMS einwirkten, stellten diesen Bereich vor grundlegende Probleme im Verarbeitungsbereich.
Es musste eine ständig ansteigende Zahl an Datensätzen innerhalb einer zumutbaren Zeit verwaltet und abgefragt werden. Vor diesem Hintergrund waren Verzögerungen in der Verarbeitung mit Beginn des produktiven Einsatzes solcher DBMS eines ihrer Kernprobleme. Performante Anfragen, die eine zügige Verarbeitung garantieren, sind heute ein wesentlicher Bestandteil der Arbeit eines DBA.
DMBS bieten heutzutage verschiedenartige Komponenten an, welche den DBA hierbei unterstützen. Optimierer wie die Verwendung von Indizes, welche den schnellen Zugriff auf Daten über eine Art Register zulassen, sind ein Automatismus im DBMS selbst. Solche Optimierer bieten die Möglichkeit, bei einem lesenden Zugriff auf den Datenbestand zu entscheiden, ob der Zugriff auf die entsprechenden Daten über einen Index oder direkt auf die Tabelle erfolgen soll. Die Entscheidungsfindung, welche auf Basis […]
Leseprobe
Inhaltsverzeichnis
Sebastian Wenzky
Datenbanktuning und deren Wirkungsweise
Visualisierung ausgewählter Szenarien
ISBN: 978-3-8366-1780-2
Druck Diplomica® Verlag GmbH, Hamburg, 2008
Zugl. Fachhochschule Schmalkalden, Schmalkalden, Deutschland, Diplomarbeit, 2008
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,
insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von
Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der
Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,
bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung
dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen
der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik
Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in
diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,
dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei
zu betrachten wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können
Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die
Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine
Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.
© Diplomica Verlag GmbH
http://www.diplom.de, Hamburg 2008
Printed in Germany
Zusammenfassung
Die heutige Welt ist durch Schnelllebigkeit und die damit einhergehende Umstellung von An-
forderungen geprägt. Viele Prozesse müssen daher gleichzeitig und sehr zügig bearbeitet werden.
Hierzu ist meist ein hoher Grad an Automation notwendig, durch den unzählige aufeinanderfol-
gende Prozesse in hohem Tempo erledigt werden müssen.
Datenbankmanagementsysteme sind geradezu prädestiniert und wurden auch entworfen, um
diese Anforderungen zu erfüllen. Mit Hilfe von Administratoren oder automatisierten Komponenten
ist es dabei möglich, die zu verarbeitenden Prozesse in strukturierter Form abzuspeichern oder
bereitzustellen.
Ein Datenbankmanagementsystem muss eine schier endlose Anzahl von in einzelne Operationen
aufgeteilten Prozessen in kurzer Zeit bewältigen. Dabei sind die Leistungen nicht immer optimal.
So genannte Tuningmechanismen zur Optimierung des Datenbankbereichs sind daher immer stark
vom Datenaufkommen abhängig, das durch einen Prozess verarbeitet werden muss.
Im Rahmen dieser Arbeit werden mögliche Wirkungsweisen angewandter Tuningmaßnahmen auf
Datenbankmanagementsysteme untersucht. Durch die Verwendung geeigneter Szenarien wurden
vor diesem Hintergrund Punkte aufgezeigt, die einen kritischen Effekt auf die Bearbeitungsdauer
einer Operation hatten.
Dabei wurde deutlich, dass schon eine kleine Veränderung der Datenmenge eine negative Aus-
wirkung auf die Bearbeitungszeit hat. Eine minimale Anpassung einer Entität mündete ebenfalls
in hohe Leistungseinbußen.
Aufbauend auf den Erkenntnissen der Wirkungsweisen von Tuningmaßnahmen sind verschiedene
Szenarien ausgewählt und als experimentelle Plattform visualisiert worden. Hierbei war es unter
anderen das Ziel, die Leserschaft des Fachbuches Taschenbuch Datenbanken[Kud07] aktiv in einige
dieser Wirkungsweisen einzubeziehen.
Inhaltsverzeichnis
1
Das erste Kapitel
1
1.1
Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.3
Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.4
Abgrenzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.5
Strukturierung dieser Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2
Grundlagen
6
2.1
Datenbankmanagementsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.1.1
Oracle als DBMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.1.2
Komponenten eines DBMS . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.2
Didaktische Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.2.1
Formen des Lernens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.2.2
Einteilung einzelner Lernmethoden . . . . . . . . . . . . . . . . . . . . . . . .
14
2.2.3
Vorstellung möglicher Präsentationsmedien
. . . . . . . . . . . . . . . . . . .
14
3
Die Testumgebungen
17
3.1
Konkretisierung der Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.2
Abgrenzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.3
Konzeption der Umgebungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3.3.1
Testplattform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3.3.2
Visualisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.4
Spezifikation von Datenbankelementen . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.4.1
Messung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.4.2
Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
3.4.3
Datenbankschema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4
Indexstrukturen
28
4.1
Index und Datenmengen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
I
Inhaltsverzeichnis
4.1.1
Versuchsdurchführung und Auswertung mit 30.000 Datensätzen . . . . . . . .
29
4.1.2
Unterschiedliche Datenmengen . . . . . . . . . . . . . . . . . . . . . . . . . .
29
4.1.3
Auswertung der Index-Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
4.1.4
Erweiterung des Versuchsaufbaus . . . . . . . . . . . . . . . . . . . . . . . . .
31
4.1.5
Auswertungen der beiden Tests . . . . . . . . . . . . . . . . . . . . . . . . . .
31
4.1.6
Feststellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
4.1.7
Fragestellung
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
4.2
Die Erreichbarkeit eines Statements
. . . . . . . . . . . . . . . . . . . . . . . . . . .
34
4.2.1
Durchführung des Tests und Auswertung . . . . . . . . . . . . . . . . . . . . .
35
4.2.2
Die Leistungsfähigkeit eines Index-Zugriffs . . . . . . . . . . . . . . . . . . . .
38
4.2.3
Index und E/A-Zugriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
4.2.4
Untersuchung der Entscheidung des kostenbasierten Optimierers . . . . . . . .
50
4.3
Häufigkeitsverteilung
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
4.3.1
Durchführung des Tests und Auswertung . . . . . . . . . . . . . . . . . . . . .
58
4.3.2
Histogramme als Wissensbasis . . . . . . . . . . . . . . . . . . . . . . . . . .
60
4.4
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
5
Der Datenblock
63
5.1
Datensatzverwaltung
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
5.1.1
Versuchsaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
5.1.2
Versuchsdurchführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
5.1.3
Auswertung und Fragestellung . . . . . . . . . . . . . . . . . . . . . . . . . .
65
5.1.4
Vergleich der unterschiedlichen Datensatz-Anfragezeiten
. . . . . . . . . . . .
65
5.1.5
Analyse der Zugriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
5.1.6
Analyse der Blockanzahl
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
5.1.7
Auswertung und Schlussfolgerungen . . . . . . . . . . . . . . . . . . . . . . .
66
5.1.8
Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
5.1.9
Erweiterte Einsichten in die Zugriffsverfahren der Datenbank . . . . . . . . . .
71
5.1.10 Lösungsmöglichkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
5.1.11 Beispielhafte Darstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
5.2
Organisation von Datenblöcken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
5.2.1
Analyse des vorherigen Beispiels . . . . . . . . . . . . . . . . . . . . . . . . .
83
5.2.2
Auswertung und weitere Vorgehensweise . . . . . . . . . . . . . . . . . . . . .
84
5.2.3
Versuchsreihe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
5.2.4
Neuaufsetzen der beispielhaften Darstellung . . . . . . . . . . . . . . . . . . .
87
5.3
Auswirkungen unterschiedlicher Blockgrößen . . . . . . . . . . . . . . . . . . . . . . .
88
5.3.1
Versuchsaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
5.3.2
Versuchsdurchführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
II
Inhaltsverzeichnis
5.3.3
Auswertung und Schlussfolgerung . . . . . . . . . . . . . . . . . . . . . . . . .
89
5.3.4
Weiterführende Betrachtungen . . . . . . . . . . . . . . . . . . . . . . . . . .
90
5.4
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
6
Von Indizes und Datenblöcken
93
6.1
Versuchsaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
6.2
Ermittlung und Vergleich der Anfragezeit . . . . . . . . . . . . . . . . . . . . . . . . .
94
6.3
Ausführungsplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
6.4
Auswertung
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
6.5
Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
95
6.6
Sammeln der strukturellen Werte . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
95
6.7
Auswertung und Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
6.8
Mutmaßung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
6.9
Versuchsaufbau zur Analyse der Datensatzgruppierungen . . . . . . . . . . . . . . . .
97
6.10 Versuchsdurchführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
97
6.11 Auswertung
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
97
6.12 Schlussfolgerung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
6.13 Weitere Überlegungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
6.14 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
7
Visualisierung
100
7.1
Zielgruppe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
100
7.2
Niveau der Thematiken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
101
7.2.1
Datenblock
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
101
7.2.2
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
102
7.3
Didaktikische Herangehensweise und Auswahl . . . . . . . . . . . . . . . . . . . . . .
102
7.3.1
Datenblock
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
102
7.3.2
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
103
7.3.3
Der rote Faden
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
104
7.4
Auswahl von didaktischen Mitteln
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
104
7.4.1
Auswahl geeigneter Präsentationsarten . . . . . . . . . . . . . . . . . . . . . .
104
7.4.2
Verfeinerung ausgewählter Präsentationsarten . . . . . . . . . . . . . . . . . .
105
7.5
Die Testplattform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
108
7.5.1
Der Rahmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
108
7.5.2
Die Szenarien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
109
8
Schlusskapitel
111
8.1
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
111
8.2
Selbstkritik und Stellungnahme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
112
III
Inhaltsverzeichnis
8.3
Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
113
Literaturverzeichnis
115
Abbildungsverzeichnis
117
Tabellenverzeichnis
119
A Anhang
122
A.1 Die Testplattform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
122
A.2 CD-Inhaltsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
123
Eidesstattliche Erklärung
124
IV
Ich glaube, daß die Ungeduld,
mit der man seinem Ziele zueilt,
die Klippe ist, an der gerade oft
die besten Menschen scheitern.
Friedrich Hölderlin (1770 - 1843)
1
Das erste Kapitel
Effizienz, Effektivität sowie Performance im Datenbanksektor sind häufig mit der Vorstellung
verbunden, dass Satz für Satz, Seite um Seite die zahlreichen Einführungen, Definitionen und
Feststellungen zu rezipieren und verarbeiten seien, die zu diesem Thema publiziert wurden.
Doch die zu Beginn genannten Themen sind zugleich praxisnah und nur schwer mit Defi-
nitionen zu erfassen. Das Umfeld, in dem agiert wird, unterliegt keiner Limitation - vielmehr
existiert ein hoher Grad an Bewegungsfreiheit. Auch wenn es eine Vielzahl von Strategien und
Lösungsvorschlägen in diesen Bereichen gibt, sind diese häufig rein theoretischer Natur und die
praktische Anwendbarkeit bleibt ungewiss.
Diese Arbeit zeigt auf, welche Wirkungsweisen durch die Anwendung von Datenbanktechni-
ken zur Performance-Optimierung zu erwarten sind. Der darauf aufbauende Visualisierungsteil
beschäftigt sich mit der Umsetzung bestimmter, in dieser Arbeit ermittelter Wirkungsweisen in
eine interaktive Testplattform.
1.1. Motivation
Als Codd im Jahre 1970 in einem der IBM Research Laboratories einen Bericht über das relatio-
nale Modell verfasste, leitete er damit den Beginn einer neuen Ära von Datenbankmanagement-
systemen ein [AS91]. Die heutigen Datenbanken fußen auf zahlreichen Arbeiten, die dort ihren
1
1. Das erste Kapitel
Ursprung hatten.
Im Laufe der Jahre wuchsen diese DBMS
1
zu immer komplexer werdenden Systemen heran.
Die stetige Steigerung des Datenaufkommens, die immer höhere Zahl an Zugriffen sowie die
Interaktivität, die auf diese DBMS einwirkten, stellten diesen Bereich vor grundlegende Probleme
im Verarbeitungsbereich.
Es musste eine ständig ansteigende Zahl an Datensätzen innerhalb einer zumutbaren Zeit ver-
waltet und abgefragt werden. Vor diesem Hintergrund waren Verzögerungen in der Verarbeitung
mit Beginn des produktiven Einsatzes solcher DBMS eines ihrer Kernprobleme. Performante An-
fragen, die eine zügige Verarbeitung garantieren, sind heute ein wesentlicher Bestandteil der Ar-
beit eines DBA
2
.
DMBS bieten heutzutage verschiedenartige Komponenten an, welche den DBA hierbei unter-
stützen. Optimierer wie die Verwendung von Indizes, welche den schnellen Zugriff auf Daten
über eine Art Register zulassen, sind ein Automatismus im DBMS selbst. Solche Optimierer bie-
ten die Möglichkeit, bei einem lesenden Zugriff auf den Datenbestand zu entscheiden, ob der Zu-
griff auf die entsprechenden Daten über einen Index oder direkt auf die Tabelle erfolgen soll. Die
Entscheidungsfindung, welche auf Basis verschiedener Zustände und Einstellungen des DBMS
und der Datenbestände getroffen wird, reiht sich in einen eigens dafür vorgesehenen Bereich ein.
Dieser Bereich wird heute als Datenbanktuning bezeichnet, in dem das Erreichen performanter
Bearbeitungszeiten
3
von Anfragen das vorrangige Ziel ist.
Die Publikationen zu diesem Thema lassen einen wichtigen Aspekt häufig unberücksichtigt:
Bei welchem Zustand der Datenbank, hinsichtlich der Cachegröße oder der Datenmenge, gilt es
beispielsweise einen Index zu verwenden? In der Fachliteratur findet man hierzu oftmals nur
eine recht grobe Beschreibung, wie etwa das folgende Beispiel aus dem Buch Beginning Database
Design von Gavin Powell zeigt [Pow06]
4
:
Tables with few fields and large numbers of records can benefit astronomically from indexing. Indexes are
usually specially constructed in a way that allows fast access to a few records in a table, after reading on a
small physical portion of the index.
Diesem Auszug zufolge ist die Akquirierung von nur wenigen Datensätzen
5
über einen Index-
zugriff als optimale Strategie anzusehen. Doch die quantitative Angabe ,,wenig" ist unpräzise
und demnach ist auch die Wirkungsweise bei der Verwendung eines solchen Indexzugriffs nicht
genau zu bestimmen. Wenn die Mengenangabe ,,wenig" nicht zutrifft, stellt sich die Frage nach
den Auswirkungen dieses Optimierungsversuch bezüglich der Bearbeitungszeit einer Anfrage.
1
Datenbankmanagementsysteme
2
Datenbankadministrators
3
Mit Bearbeitungszeit ist das Ausführen eines Statements einer SQL-Anfrage im DML- sowie SELECT-Bereich
gemeint.
4
Seite 342, die ersten zwei Stichpunkte.
5
. . . beziehungsweise -Tupeln
2
1. Das erste Kapitel
Ist dadurch mit einer deutlich schlechteren Bearbeitungszeit zu rechnen? Die Frage nach der Wir-
kungsweise von Tuningaspekten gilt es aus diesem Grund zu hinterfragen.
Ein Auszug aus einem anderen Fachbuch wirft ebenfalls eine weitere Frage von allgemeinem
Charakter auf [PG02]
6
:
The optimum page size is related to the disk system´s attributes. Smaller page sizes like 2KB were once the
norm, but disks capacity tends to increase over time, so now 8KB is reasonable, while 16KB is what we´ll
upgrade to soon.
Man könnte hier hinsichtlich der Vergrößerung einer Blockgröße einen falschen Schluss zie-
hen: Nach dem letzten Satz des Zitats zu urteilen, scheint es vollkommen verständlich, auf einen
immer größer werdenden Block zu migrieren. Doch welche Wirkungsweise hat die Änderung
dieser fundamentalen Komponente eines DBMS auf die Bearbeitungszeit? Ist es wirklich ratsam,
auf einen immer größeren Datenblock umzusteigen oder könnte dies ebenfalls fatale Konsequen-
zen haben?
Aus den aufgeführten Fragestellungen ergibt sich eine für die Arbeit wichtige Frage: Können
Wirkungsweisen in einer bestimmten Art und Weise für den Leser klar und verständlich als ,,Wis-
sen" visualisiert werden? Hier gilt es die Vermittlung möglicher Vor- als auch Nachteile durch die
Anwendung von Tuningaspekten zu untersuchen.
1.2. Problemstellung
In der vorliegenden Arbeit soll die Wirkungsweise des Einsatzes von Indizes und Datenblöcken
untersucht werden. Dabei ist es wichtig, auf Szenarien in einem ,,realen" Umfeld aufzubauen,
um die Praxisrelevanz zu verdeutlichen. Eine weitere Fragestellung befasst sich mit der Art und
Weise der grafischen Darstellungen derartiger Wirkungsweisen, denn für die Leserschaft ist es
leichter, Sachverhalte mit Hilfe von Grafiken zu verstehen. Vor diesem Hintergrund kann für
Leser des Buches Taschenbuch Datenbanken [Kud07], auf dem die vorliegende Arbeit zu Teilen
basiert, ein praktischer Nutzen erzielt werden.
1.3. Ziele
Die Art und Weise der Wissensvermittlung ist grundlegend für ein Fachbuch. Demzufolge ist es
umso wichtiger, die zu vermittelnden Inhalte in ihrer Genauigkeit abzuwägen. Fachbücher wie
die im vergangenen Abschnitt zitierten folgen einer einfachen Implikationsregel - ,,aus x resul-
tiert z". Daher ist es entscheidend, die im letzten Abschnitt aufgeworfene Frage zu präzisieren:
Kann durch das Aufstellen einfacher Regeln tatsächlich eine Leistungssteigerung erreicht wer-
den? Die Implikationsregel ist ein einfaches Beispiel, um die Komplexität einer Entscheidung zu
6
Seite 174
3
1. Das erste Kapitel
verdeutlichen. Im Rahmen dieser Arbeit ist es die Intention, Wirkungsweisen aufzuzeigen (so sie
vorhanden sind), die gerade dann auftreten, wenn nicht aus ,,x" ,,z" folgt. Die Basis hierfür bilden
Szenarien, die sich wiederum an Thematiken orientieren.
Die Thematiken spielen dabei eine wesentliche Rolle. Zunächst werden im Rahmen dieser Ar-
beit die Indexstrukturen sowie die kleinsten Speichereinheiten in Form von unterschiedlichen
Versuchsaufbauten betrachtet. Insbesondere die hohe Abhängigkeit zwischen diesen beiden Par-
teien wird in diesem Zusammenhang aufgezeigt.
Je nach Verlauf der jeweiligen Szenarien ist es dann notwendig, weiterführende Analysen vor-
zunehmen, da untersucht werden soll, welche Einflussgrößen zu diesem Ergebnis geführt haben.
Darauf aufbauend werden ausgewählte Wirkungsweisen anhand der Versuchsaufbauten prä-
sentiert, wobei Anschaulichkeit und die Einbeziehung des Lesers im Vordergrund stehen. Die
Verständlichkeit ist hierzu mit Hilfe von geeigneten didaktischen Mitteln, wie etwa Grafiken, zu
untermauern.
1.4. Abgrenzung
Jede Arbeit ist davon abhängig, welchem Zweck sie dient. Der Fokus im Abschnitt Ziele ist durch
zwei Thematiken klar definiert. Dennoch scheint die Auswahl schier endlos, so dass ein engerer
Fokus erforderlich ist. In der vorliegenden Arbeit wird besonders der Aspekt der Anfragezeit,
definiert durch eine SELECT-Operation und die korrespondierenden Zugriffsraten, betrachtet.
DML-Operationen
7
sind nur zum Aufbau und Ablauf bestimmter Versuche notwendig und die-
nen keinem weiteren Zweck.
8
1.5. Strukturierung dieser Arbeit
Die vorliegende Arbeit ist in sechs Teile gegliedert, deren Inhalt hier kurz zusammengefasst wird.
Ausgehend von der Spezifikation der Testplattformen widmet sich der Hauptteil der Arbeit den
Versuchsaufbauten und deren Thematiken, um sie schließlich im Kapitel Visualisierung als expe-
rimentelle Plattform
9
umzusetzen.
Kapitel 1:
Dieses Kapitel dient der Einführung und dem Formulieren der Arbeitshypothese.
Kapitel 2:
Hier werden Grundlagen eingeführt, die für das spätere Verständnis essentiell sind.
Abschnitt 2.1 führt dabei in das ausgesuchte Datenbankmanagementsystem Oracle ein. Wei-
7
Als DML-Operation ist hier die Manipulationssprache an sich gemeint. Die Anfragesprache ist als exklusiver Be-
standteil anzusehen.
8
Auch hier ist zu erwähnen, dass DML-Operationen einen eigenen Bereich in der Performance-Philosophie darstellen.
Diese Aspekte übersteigen jedoch den Rahmen der vorliegenden Arbeit bei Weitem. Allerdings unterliegen auch
die Thematiken an sich weiteren Einschränkungen. Untersuchungen hinsichtlich unterschiedlicher Füllgrade eines
Blocks oder der Anwendung unterschiedlicher Arten von Indexstrukturen bieten zwar weiteren Raum zur Analyse,
können hier aber nicht berücksichtigt werden.
9
Diese kann nachfolgend auch auch Testplattform genannt werden.
4
1. Das erste Kapitel
terhin wird dort eine konkrete Einführung in wichtige Komponenten(Cache, Indexstruktu-
ren, Datenblöcke) eines Datenbanksystems gegeben.
Kapitel 3:
In Kapitel 3 werden die Testplattformen spezifiziert; die Anforderung der Versuchsauf-
bauten wird in Abschnitt 3.1 benannt und genau beschrieben. Abschnitt 3.2 grenzt die Ar-
beit in ihrem Inhalt ab. Im Abschnitt 3.3 erfolgt anschließend die Konzeptionierung der Um-
gebungen
10
. Der letzte Abschnitt 3.4 beschreibt den konkreten Aufbau der Testumgebung
welche für die Versuchsaufbauten in den Kapiteln 4 bis 6 eine Rolle spielen.
Kapitel 4:
Dieses Kapitel handelt von der Thematik der Indize. Anhand von drei Versuchsauf-
bauten (siehe Abschnitte 4.1, 4.2 sowie 4.3) werden verschiedene Wirkungsweisen durch
die Verwendung von Indize untersucht.
Kapitel 5:
Das Datenblockkapitel untersucht ebenfalls drei Versuchsaufbauten(siehe Abschnitt
5.1, 5.2 sowie 5.3) auf deren Wirkungsweisen genauer.
Kapitel 6:
Schlussendlich erfolgt die ganzheitliche Betrachtung der Abhängigkeit zwischen den
Indize sowie den Datenblöcken. Diese Abhängigkeit wird durch ein erneuten Versuchsauf-
bau untersucht.
Kapitel 7:
Die schlussendliche visuelle Umsetzung bestimmter Szenarien auf Grundlage zuvor
dargelegten Inhalte aus den Kapiteln 4 bis 6 ist Bestandteil dieses Kapitels. Abschnitt 7.1
grenzt zunächst die zu erreichende Zielgruppe oder Zielgruppen voneinander ab, die es
mit der Umsetzung zu erreichen gilt. Anschließend ist das Niveau der umzusetzenden
Szenarien oder Thematiken basierend aus den Erkenntnissen der Kapitel 4 bis 6 im Ab-
schnitt 7.2 näher zu untersuchen und zu bestimmen. Abschnitt 7.3 erläutert dann konkret
die didaktische Herangehensweise bei der Vermittlung konkreter Wirkungsweisen der aus-
gewählten Thematiken oder Szenarien. Der letzte Abschnitt 7.4 klärt die Darstellungsart
von Wirkungsweisen basierend auf didaktischen Mitteln.
Kapitel 8:
Das Erreichte wird resümiert und kritische betrachtet. Ein Ausblick beschließt die vor-
liegende Arbeit.
10
Mit Umgebungen ist hier zum einen die Testumgebung für die Versuchsaufbauten und zum anderen die experi-
mentelle Plattform gemeint.
5
Große Leidenschaften sind wie Naturkräfte.
Ob sie nutzen oder schaden,
hängt nur von der Richtung ab,
die sie nehmen.
Ludwig Börne (1786 - 1837)
2
Grundlagen
In diesem Kapitel werden die folgenden grundlegenden Aspekte näher erläutert: Zunächst wird
im Abschnitt 2.1 das verwendete DBMS näher vorgestellt. Auch allgemeine Komponenten, die
in jedem DBMS vorzufinden sind, werden hier erläutert. Abschnitt 2.2 führt in den didaktischen
Grundlagenteil dieser Arbeit ein.
2.1. Datenbankmanagementsystem
Das wichtigste Element in dieser Arbeit ist das DBMS. Der kommende Abschnitt beschäftigt sich
mit wesentlichen Grundlagen und Besonderheiten des in Abschnitt 3.3.1.2 ausgesuchten DBMS,
Oracle.
2.1.1. Oracle als DBMS
Oracle ist ein komplexes Produkt, in das hier nur eine grobe Einführung gegeben werden kann.
Auch Fachbücher sind sich der Komplexität dieser Aufgabe bewusst [RG04]:
Where do we start? One of the problems in comprehending a massive product such as the Oracle database
is the difficulty of getting a good sense of how the product works without getting lost in the details of
implementing specific solutions.
6
2. Grundlagen
An dieser Stelle sollen vor allem diejenigen Komponenten von Oracle betrachtet werden, die
im Hinblick auf die vorliegende Arbeit wichtig sind.
Bevor überhaupt ein Standard hinsichtlich der Spezifizierung einer einheitlichen Anfragespra-
che erschienen ist
1
, gab es Oracle schon mehr als 7 Jahre: Das erste kommerzielle Produkt mit
dem Namen Oracle Release 2 ist 1979 auf dem Markt erschienen. Die weiteren Entwicklungen
führten zu Merkmalen wie Netzwerkfähigkeit, Modellierungsunterstützung und schlussendlich
interdisziplinär hervortretenden Produktpaletten [RG04]. Es entstanden Komponenten zur Per-
formanceverwaltung, die sich in folgende Punkte gliedern lassen können:
Funktionalität:
Tracing-Werkzeuge, zusätzliche Funktionen in vorhandenen Software-Lösungen
wie SQL-Plus
2
sowie eine umfassende Unterstützung von statistischen Methoden, um den
kostenbasierten Optimierer
3
bei der Auswahl des optimalen Ausführungsplans zu unter-
stützen, sind Bestandteile des DBMS.
Speicherstrukturen:
Oracle bietet viele Möglichkeiten zur Speicherung von Daten an. Von Standard-
Tabellen über gruppierte Tabellen bis hin zu indexorganisierte Tabellen sind für viele Sze-
narien ausbalancierte Möglichkeiten einsetzbar.
Einstellungen:
Die schier unendliche Anzahl an Konfigurationen auf jeglicher Ebene
4
ist für einen
erfahrenen Datenbankadministrator ein solides Fundament zur Optimierung.
Parallelisierung:
Seit der Version 7.3 des DBMS ist es möglich, SQL-Anfragen bei der Ausführung
auf verschiedene CPUs zu verteilen. Hierunter fallen beispielsweise Tabellenvollzugriffe
5
,
Gruppierungen, Unterabfragen oder verschiedene Arten von Verbundoperationen.
Skalierung:
Oracles standardisierte Lösung zum verteilten Arbeiten, das Real Application Clus-
ter, bietet ein hohes Maß an Verfügbarkeit und Effizienz bei steigender Belastung.
Jeder dieser Aspekte basiert auf einem Fundament, von dem aus er agieren kann. Bezogen auf
das DBMS Oracle existieren hierfür zwei Terminologien: Instanz und Datenbank. Die Datenbank
repräsentiert die physische Speicherung der Daten, während eine Instanz der Software als Ver-
mittler zwischen Anwendung und Datenbank dient. Des Weiteren ist die Instanz aber auch, als
teilweise in ein Betriebssystem integriertes Modul, als logisch zu betrachten.
2.1.1.1. Die Datenbank
Die Datenbank gliedert sich in Tablespaces und die darin enthaltenen Dateien. Daten, die in der
Datenbank gespeichert sind, finden sich innerhalb sogenannter Tablespaces wieder. Daher be-
trachtet man im Allgemeinen Tablespaces als logische Struktur innerhalb der Datenbank. Darüber
1
vgl. http://en.wikipedia.org/wiki/SQL, 22. Juni 2008
2
Beispielsweise das Anzeigen der Statistik oder der Anfragezeit
3
Abkürzung ist CBO = Cost Based Optimizer
4
. . . nach ANSI/SPARC, siehe auch [Kud07]
5
In dieser Arbeit werden Full-Table-Scans auch als Tabellenzugriff bezeichnet.
7
2. Grundlagen
hinaus existieren verschiedene Kontrolldateien, die sowohl die Daten als auch Verwaltungsinfor-
mationen für das DBMS darstellen. Unter anderem erfolgt dort die Abspeicherung von Infor-
mationen hinsichtlich des Aufbaus und aktuellen Zustands des Tablespace, aber auch die Log-
bucheinträge der Vergangenheit, Backups sowie eventuell erstellte Checkpunkte werden dort ge-
speichert.
Datendateien respräsentieren hingegen den eigentlichen Bereich zur Abspeicherung von Da-
ten. Indizes, das Data Dictionary, sowie Tabellen sind dort abgelegt. Dabei unterliegt jede Da-
tendatei bestimmten Restriktionen. Beispielsweise erfolgt - bei Platzmangel - bei der Erstellung
einer Datendatei gleichzeitig die Definition der Vorgehensweise. Diese Informationen sind jedoch
in den Kontrolldateien abgespeichert. Auch die Blockgröße kann in einem Tablespace angepasst
werden. Diese ist dann für jedes Element innerhalb des Tablespace gültig.
Eine Datendatei ist in Blöcke, Extents sowie Segmente aufgeteilt. Ein Extent stellt eine Menge
von aufeinander folgenden Blöcken dar. Ein Segment verfügt über mehrere Extents, so dass man
- dieser Beschreibung folgend - das Segment als eine Tabelle auffassen kann. Sind Daten in eine
spezifische Tabelle zu schreiben und steht kein freies Extent mit freien Blöcken zur Verfügung,
erfolgt das hinzufügen eines neuen Extents. Freie Blöcke in Extents beziehungsweise Blöcke, in
denen Daten abgelegt werden können, sind in sogenannten Freilisten organisiert, die bei DML-
Operationen eine wichtige Rolle spielen. Sind neue Datensätze in einer Relation zu speichern,
überprüft das DBMS die Freiliste nach freien Blöcken und stellt diese zum Speichern schlußend-
lich zur Verfügung.
Redo-Log-Dateien speichern Änderungen, die aus einer Transaktion oder einer internen Akti-
vität seitens Oracle resultieren. Ein plötzlicher Fehler in der Instanz bei der Verarbeitung von Da-
ten zwischen dem Cache und der Platte garantiert in den meisten Fällen eine Wiederherstellung
durch die Redo-Logs. Elemente, die innerhalb eines Tablespaces gespeichert sind, unterliegen
demnach dieser Protokollstrategie. Jedoch kann diese Methode durch die Direktive NOLOGGING
übergangen werden [JA05] [Kud07].
2.1.1.2. Die Instanz
Der logische Bereich von Oracle ist in die SGA
6
, und die PGA
7
aufgeteilt. Die SGA setzt sich wie-
derum aus verschiedenen Komponenten zusammen: Zum einen befinden sich diverse Puffer für
verschiedene Blockgrößen sowie der Puffer für Protokollierungen in der SGA
8
. Auch der Shared
Pool, eine Komponente, die u. a. zur Verwaltung von Cursorn sowie Ausführungsplänen dient,
ist ebenfalls ein wichtiger Bestandteil.
Im Hintergrund arbeiten Prozesse, wie Database Writer der Datenblöcke vom Cache auf die
Platte zum schreiben dirigiert, oder ein Archiver um die Protokollierung durchzuführen. Diese
6
System Global Area
7
Process Global Area
8
Im Kapitel 5 (Der Datenblock) wird auf die der Thematik der Blockgrößen noch näher eingegangen.
8
2. Grundlagen
führen verschiedene Aufgaben zeitgesteuert oder synchron aus.
Die PGA dient der Verwaltung von ausführbaren Programmen wie Java Stored Procedures
[JA05].
2.1.1.3. DBMS-Objekte
Die Tabelle DBA_OBJECTS stellt sowohl einen dynamischen als auch statischen Teil einer Da-
tenbank dar. Dynamische Objekte werden nach ihrer Verwendung aus der entsprechenden Ta-
belle ausgeschlossen. Die Spalte object_id, dient dabei der Identifizierung eines Objektes mit ei-
ner Komponente der Datenbank, beispielsweise einer Tabelle. Diese Informationen ist in der
Spalte object_name verfügbar, wodurch über einen Verbund mit der Tabelle DBA_TABLES oder
DBA_INDEXES weitere Informationen erhältlich sind.
2.1.1.4. DBMS-Sichten
Oracle arbeitet intern zur Verwaltung des Caches mit verschiedenen Mechanismen wie u. a. v$-
Views sowie x$-Views. Die x$-Views dienen der internen Verwaltung von Oracle und sind von
C-Strukturen abgebildet. Diese Tabellen dienen wiederum den v$-Views als Grundlage, denn
über die Tabelle v$fixed_table sowie v$fixed_table_definition erfolgt deren projektive Definition
[Mit03]. Diese Views dienen der Datenbank zur Verwaltung der Datenblöcke im Cache und beide
Views können über die Blocknummern-Spalten miteinander verbunden werden. Vor allem die
Sichten v$bh sowie x$bh spielen in dieser Arbeit eine zentrale Rolle. Im Kapitel 4 sind diese
Sichten notwendig, um Datenblöcke die einer bestimmten Relation zugeordnet sind, im Cache
ausfindig zu machen.
Die x$-View bietet gegenüber dem v$-View die Möglichkeit, den MRU
9
-Algorithmus von Oracle
einzusehen. Unter anderen dient die Spalte TCH zur Verwaltung der Zugriffshäufigkeit auf die-
sen Block. Die Spalte TIM speichert hingegen den letzten Zugriff als numerischen Zeitwert im
UNIX-Zeitstempel-Format
10
. Im v$-View existiert hingegen die Spalte OBJID. Weitergehende In-
formationen über dieses Objekt, beispielsweise bezüglich der Zugehörigkeit, ist durch einen Ver-
bund mit der Tabelle aus Abschnitt 2.1.1.3 möglich.
2.1.2. Komponenten eines DBMS
Im Folgenden sind diejenigen Aspekte des DBMS separat aufgeführt, auf welche in den Ver-
suchsaufbauten insbesondere eingegangen wird.
9
Most Recently Used
10
vgl. http://www.oracle-training.cc/oracle_tips_view_columns.htm, 26. Juni 2008
9
2. Grundlagen
2.1.2.1. Datenblock
Wie schon im vorangegangenen Kapitel erläutert, existiert der physische Bereich aus Extents, die
wiederum auf einer bestimmten Datenblockanzahl aufgebaut sind. Datenblöcke stellen dabei die
kleinste Informationseinheit in einem DBMS dar. Ist ein Datensatz von der Platte in den Cache
zu transportieren, ist nicht der Datensatz an sich, sondern der korrespondierende Block von der
Platte zu laden.
Verwaltungsinformationen
Freier Speicherplatz
Nutzdaten
Repräsentation eines Datenblocks
mit Nummer in dieser Arbeit
12
Abbildung 2.1.: Aufbau eines DBMS-Datenblocks nach [JA05]
In Abbildung 2.1 ist der Aufbau eines einzelnen Datenblocks dargestellt. Dabei gliedert sich
ein Block in einen Header, den sogenannten Verwaltungsteil sowie den reinen Nutzdatenanteil.
Je nach Speicherplatzausnutzung und Strukturierung des Datenblocks benötigt der Kopfanteil
einen variablen Speicherplatz von im Schnitt 100 Byte. Der Nutzdatenanteil selbst teilt sich in
den aktuell verwendeten und verfügbaren Speicherplatz auf. In dieser Arbeit werden vor allem
die Wirkungsweisen unterschiedlichen Datenblockgrößen wie 2, 4, 8 sowie 16 Kilobyte betrachtet
[JA05].
2.1.2.2. Cache
Ein wichtiger Bestandteil eines DBMS ist der Cache. Der Cache ist eine ausgezeichnete Einheit
eines DBMS, der einen bestimmten Anteil des Hauptspeichers belegt. Liegen benötigte Daten be-
ziehungsweise Datenblöcke im Hauptspeicher vor, so kann dadurch eine effizientere Performance
erreicht werden.
32 22 17
84
14
12 27
4
20
18
7 16
14
Logischer E/A
Head
Tail
Gelöschter Block
87
Physischer E/A
Sekundärspeicher
Abbildung 2.2.: Grober Aufbau und Vorgehensweise eines Caches nach [Tow03]
10
2. Grundlagen
In Oracle ist ein Blockpuffer ein Cache für Operationen zwischen der Instanz, der Anwendung
und der Datenbank. Ist ein Block im Cache vorhanden, so erfolgt ein Zugriff, auch logischer Zugriff
genannt. Bei einem einem physischen Zugriff hingegen muss ein Datenblock zunächst von der
Platte geladen und in den Cache eingefügt werden. Ist der Cache für eine erneute Aufnahme
eines Datenblocks zu klein, so erfolgt eine LRU
11
-Verdrängungsstrategie. Der Datenblock, der am
Ende der Liste steht, am Tail, fällt aus dem Cache heraus. Der neue Block wird am Kopf (Head)
angefügt (siehe Abbildung 2.2).
Des Weiteren verfügen viele DBMS, wie auch Oracle, über eine MRU
12
-Strategie. Diese beinhal-
tet zum einen den Hot-Bereich, wo die am meisten benutzten Datenblöcke angeordnet sind. Am
anderen Ende existiert der Cold-Bereich. Diese Datenblöcke sind weniger in Benutzung. Durch
die Verwendung eines MRU-Algorithmus verändert sich auch die Einfügeposition eines Daten-
blocks. Dabei ist die Position gemeint, welche den Mittelpunkt zwischen dem Hot- und dem
Cold-Bereich darstellt [Tow03].
2.1.2.3. Zugriffsarten
In dieser Arbeit erfolgt der Zugriff auf Daten überwiegend mittels der SELECT-Operation. Hier-
bei unterscheidet man vor allem zwei Kategorien, die in den folgenden Abschnitten erläutert
werden.
2.1.2.3.1. Tabellenzugriff
Zum einen ist es möglich, direkt auf die Daten - über die Datenblöcke - in einer Relation zuzugrei-
fen. Um den jeweiligen Inhalt eines Blockes lesen zu können, ist dieser zunächst in den Cache zu
transportieren (siehe Abschnitt 2.1.2.2). Da selbst bei einer Spezifizierung in der WHERE-Klausel
keine Vorauswahl an Blöcken möglich ist, sind in der Regel alle Datenblöcke in dieser Relation zu
lesen und im Cache, basierend der Prädikate in der WHERE-Klausel, bezüglich der Übereinstim-
mung zu prüfen.
2.1.2.3.2. Indexzugriff
Um dieser Situation aus dem Weg zu gehen, ist es möglich, bei einer Spezifizierung der WHERE-
Klausel eine Vorauswahl zu treffen. Dies geschieht, indem eine separate Speicherstruktur ange-
legt wird, die Informationen zu einer bestimmten Spalte in der WHERE-Klausel speichert. Zum
einen ist es dabei notwendig, sowohl den Wert der Spalte als auch die Blocknummer zu spei-
chern, an dem der korrespondierende Datensatz zu finden ist. Dadurch gelingt es dem DBMS
relativ leicht, nur die Blöcke von der Platte zu lesen, die tatsächlich benötigt werden. Die Spei-
cherstruktur ist in vielen DBMS als balancierter Stern-Baum, als B*-Baum, implementiert. In jeder
11
Last Recently Used
12
Most Recently Used
11
2. Grundlagen
Ebene (Knoten) des Baumes wird der gesuchte Indexwert mit den dort ansässigen Werten (eben-
falls Indexwerte) überprüft. Finden sich Übereinstimmungen, dann werden die Referenzen der
übereinstimmenden Werte zu deren Blöcken weiterverfolgt um schlussendlich in den Blättern
zu landen. An deren Blättern sind erneut die Werte mit den korrespondierenden Blocknummern
auf der Platte gespeichert. Erst dort erfolgt das ,,fetchen"
13
der jeweiligen Blocknummern um die
Datensätze in einem bestimmten Block ausfinden zu machen. Nun kann das DBMS erst im Ca-
che - falls nicht gefunden - und anschließend auf der Platte nach diesen Blöcken suchen und die
Datensätze aus den Blöcken lesen. Der Baum kann selbst eine beliebige Höhe, je nach Umfang
der zu speichernden Werte, annehmen [TH01]. Findet ein Zugriff auf die Relation über eine indi-
zierte Spalte statt, werden die korrespondierenden Werte in dem angegebene WHERE-Prädikat
gesucht. Nacheinander werden dann die jeweiligen Blöcke, die diesem Suchmuster entsprechen,
nach den dazugehörigen Datensätzen durchsucht.
2.1.2.4. Kostenbasierter Optimierer
Entscheidungen bezüglich einer effizienten Zugriffsstrategie sollten im Allgemeinen nicht Auf-
gabe des Programmierers oder Datenbankadministrators sein. Aus diesen Grund existieren in
DBMS Optimierer
14
, die genau für diese Aufgabe gedacht sind. In einer Datenbank gilt es unzäh-
lige Einflussgrößen zu beachten: Angefangen von den zugreifbaren Ressourcen über den Auf-
bau der Relationen bis hin zu unzählig parametrisierbaren Einstellungen ist es praktisch gesehen
unmöglich für eine Person, eine effiziente Entscheidung für jedes Statement zu treffen. Die Ent-
scheidung betrifft vor allem die Art des Zugriffs. Dabei legt der Optimierer eine Gleichverteilung
der jeweiligen Werte einer Spalte fest. Ermittelt beispielsweise der Optimierer, dass ein Index-
Zugriff höhere Kosten als ein Tabellenzugriff verursacht, folgt ein Full-Table-Scan. Der kostenba-
sierte Optimierer trifft diese Entscheidungen auf Basis von statistischen Messungen hinsichtlich
relevanter Größen wie Tabellen und Indizes sowie die Art des Statements. Sogenannte Ausfüh-
rungspläne, die bei einem unbekannten Statement für verschiedene Zugriffsarten zu ermitteln
sind, bilden zunächst eine Liste von Gegenüberstellungen für den Optimierer. Die anhand dieser
Gegenüberstellung ermittelten Werte - wie beispielsweise die Kosten für einen E/A-Zugriff, oder
die CPU-Kosten - gehen in die Bewertung und schlussendliche Entscheidung mit ein. Ein Ausfüh-
rungsplan stellt am Ende die Strategie des Zugriffs dar. Kosten haben dabei keine repräsentative
Größe, dienen sie doch dem DBMS als Basis zur Gegenüberstellung [Lew05].
13
Mit ,,fetchen" ist die Akquirierung von Datenblöcken oder Daten im Allgemeinen von der Platte oder aus dem
Cache gemeint.
14
Es existieren zwei Typen. Zum einen der regelbasierte, zum anderen der kostenbasierte Optimierer.
12
2. Grundlagen
2.2. Didaktische Grundlagen
Die Notwendigkeit, sich ständig Weiterzubilden, unterliegt der allgemeinen Definition der Mo-
tivation. Jede Person benötigt zum Erlernen neuer ,,Dinge" eine geistige Einstellung, die es er-
möglicht, Wissen aus Daten herzuleiten beziehungsweise aufzubauen. Nach [MS07] ist die eige-
ne Auffassung vom ,,Lernen" ein wichtiger Bestandteil für das Erfassen neuer Tatsachen allge-
mein. Ist die Einstellung gegeben, dass man Wissens sammeln möchte, um etwas zu erreichen,
bezeichnet man dies als Motivation [Rhe06]. Die Motivation gleicht bei einem Lernprozess einer
ständigen Berg- sowie Talfahrt. Denn nicht jede Thematik ist auf verständliche Art und Weise
zu vermitteln, sei es aufgrund fehlenden Hintergrundwissens, mangelnder Literatur oder nicht
vorhandenen Praxisbezug. Auch die Herangehensweise der Lernenden ist dabei ein wichtiger
Aspekt. Der Leitfaden, nach dem Wissen zu vermitteln ist, stellt demnach ein wichtiger Bestand-
teil dar. Die Abschnitte 2.2.1 und 2.2.3 dienen für die am Ende dieser Arbeit umgesetzten Visua-
lisierungen als wesentliche Grundlagen.
2.2.1. Formen des Lernens
Visualisierungen zur Vermittlung von bestimmten Zuständen oder Situationen, um den Lernen-
den einen tieferen Einblick in bestimmte Verhalten zu geben, erfordert den Einsatz von didakti-
schen Hilfsmitteln. Nach Norbert Meder [Med06] wird die Vermittlung von Inhalten in die Kate-
gorien rezeptives, interaktives sowie gruppenbasiertes Lernen gegliedert.
Rezeptives Lernen:
Die Aufnahme von Inhalten erfolgt nur aus konsumierender Sicht. Medien
wie Texte, Bilder oder Videos dienen nur zur Präsentation. Der Nutzer ist selbst in die Pflicht
genommen, aus den Informationen
15
die notwendigen Schlussfolgerungen zu ziehen. Auch
wenn diese anhand von Beispielen in Medien integriert sind, ist es dennoch theoretischer
Natur, was dem Wesen eines Menschen zur Erlangung neuem Wissens nicht entspricht
16
.
Interaktives Lernen:
Ist es das Ziel, dem Leser anhand von änderbaren, beziehungsweise dem
individuellen Gestalten eines Beispiels eine Thematik näher zu erläutern, so spricht man
von interaktivem Lernen. Hier ist das Ziel klar die Miteinbeziehung des Nutzers.
Gruppenbasiertes Lernen:
Sollen mehrere Leser eine Aufgabe lösen oder miteinander kommu-
nizieren, bezeichnet man diese Vorgehensweise als Gruppenlernen.
15
Wobei die Definition von ,,Information" hier etwas missbraucht wird. Es ist tatsächlich so, dass erst das jeweilige
Gehirn ,,entscheidet", ob die aufgenommenen Daten in Kombination mit anderen bereits erlerntem Wissen neue
Informationen ergeben.
16
Kurz gesagt, ist der Mensch ein praktisch orientierter Mensch.
13
2. Grundlagen
2.2.2. Einteilung einzelner Lernmethoden
Wichtig in dieser Arbeit sind vor allem die Formen des rezeptiven und interaktiven Lernens.
Gruppenbasiertes Lernen ist dahingehend nicht von Relevanz, da diese Art des Lernens hier nicht
angewandt werden soll
17
. Betrachtet man zunächst interaktives Lernen, so kann man Orientierungs-
, Handlungs-, Erklärungs- sowie Quellwissen unterscheiden. Hierbei dient Orientierungswissen
dem Aufbau von grundlegenden Aspekten einer neuen Thematik. Diese Art der Wissensvermitt-
lung suggeriert die Motivation, sich mit dieser Thematik auseinanderzusetzen. Handlungswissen
dagegen versucht dem Benutzer anhand beispielhafter Erklärungen eine Thematik näher zu brin-
gen. Eine konsequente Fortsetzung des Orientierungswissens bildet das Erklärungswissen. Hier
wird dem Benutzer anhand von theoretischen Grundlagen, Definitionen sowie Argumenten ei-
ne Thematik näher gebracht. Quellenwissen zeigt schließlich Verweise zu Inhalten auf, die sich
eingehender mit bestimmten Aspekten beschäftigen.
2.2.3. Vorstellung möglicher Präsentationsmedien
In diesen Abschnitt erfolgt eine Einteilung von unterschiedlichen Medien in den Kategorien, des
Lernens nach Mirko Bettels [Med06].
2.2.3.1. Rezeptives Wissen
2.2.3.1.1. Text
Texte dienen der sukzessiven Beschreibung von Wissen. Der ,,Transport" dieses Wissens erfolgt
im Allgemeinen langsam, da zum einen das Gehirn die benötigten Textzeichen als interne Dar-
stellungsart transformieren muss. Anschließend ist das Gehirn gezwungen, daraus Semantik zu
erzeugen, um einen Vergleich mit anderem Wissen herzustellen.
2.2.3.1.2. Tabelle
Von Tabellen verspricht man sich strukturierte Darstellungen wichtiger Informationen, die bei-
spielsweise Texten angefügt sind. Spalten dienen dabei der Kategorisierung, Zeilen wiederum als
Ausprägung ihrer Merkmale. Eine zu komplex konstruierte Tabelle kann zu Problemen bei der
rezeptiven Aufnahme führen: unter Umständen zu Missverständnissen oder gar zur Unverständ-
nis des zu vermittelten Wissens.
17
Diese Art des Lernens erfordert deutlich mehr Implementationsaufwand, um eine Synchronisation der beteiligten
Personen mit den Arbeitsabläufen sicherzustellen. Weiterhin stellt sich auch die Frage, wie lange ein Nutzer auf
Beteiligung anderer Nutzer warten soll, bevor ein Test gestartet werden kann. Deswegen wird diese Art des Lernens
nicht weiter berücksichtigt.
14
2. Grundlagen
2.2.3.1.3. Abbildungen
Mit Hilfe augenfreundlicher Darstellungen von ,,Wissen", in Form von graphischen Elementen,
sollen bestimmte Inhalte beschrieben beziehungsweise verdeutlicht werden. Eine graphische Ver-
dichtung eines bestimmten Sachverhalts kann - geschickt eingesetzt - das Verständnis für eine
Thematik fördern. Abbildungen können in Diagramme, Wissenslandkarten, grafischen Abbil-
dungen sowie animierten Abbildungen eingeteilt werden. Diagramme dienen dabei der Veran-
schaulichung von Tabellen, um das einen bestimmten, der Tabelle immanenten Sachverhalt zu
verdeutlichen. Wissenslandkarten dienen hingegen der schematischen Darstellung von Begriffs-
beziehungen
18
. Zur verständlichen Präsentation bestimmter Modelle können Lernenden grafi-
sche beziehungsweise animierte Modelle hilfreich sein.
2.2.3.1.4. Bild
Im Gegensatz zu einer Abbildung soll ein Bild dazu dienen, eine Systematik praktisch zu verdeut-
lichen. Mit Hilfe von nebeneinander aufgestellten Bildern kann beispielsweise die Auswirkung
eines zu schildernden Sachverhalts anschaulich präsentiert werden, um so die zu vermittelnden
Inhalte zu verdeutlichen.
2.2.3.1.5. Film und Video
Um ein bestimmtes Verhalten einer zu beschreibenden Thematik besser nachvollziehen zu kön-
nen, kann es sinnvoll sein, aufeinanderfolgende Bilderreihen zu nutzen. Da der Sachverhalt wie
in der natürlichen Wahrnehmung aufgenommen wird, ist es möglich, bestimmtes Wissen durch
reales Handeln in der Umwelt zu vermitteln.
2.2.3.1.6. Klang
Akustisch präsentierbares Wissen kann zu einer erhöhten rezeptiven Aufnahme an Wissen in be-
stimmten Gebieten führen. Erfolgt mit Hilfe einer sprachlichen Ausdrucksweise die Übermittlung
von Informationen, wird der Lernende in die Lage eines ,,Schülers" versetzt. Eingeteilt werden
kann der Klang in eine sprachliche, eine musikalische sowie eine geräuschvermittelnde Art der
Repräsentation.
2.2.3.2. Interaktives Lernen
2.2.3.2.1. Simulation
Eine genaue Nachbildung realer Szenarien oder Vorgänge ist vor allem durch ein dynamisches
Modell mit Testmöglichkeiten möglich. Dabei muss ein spezifisches Szenario handlungsgetreu
wiedergegeben werden. Sowohl die Motivation als auch das zu vermittelnde Verständnis für eine
18
Ein Beispiel wäre eine MindMap.
15
2. Grundlagen
Thematik soll dabei drastisch erhöht werden, da vor allem auf die interaktive Beeinflussung eines
Bereichs durch den Lernenden reagiert wird.
2.2.3.2.2. Programmierte Instruktion
Mit Hilfe einer deterministischer Vorgehensweise sollen dem Lernenden durch Suggestion be-
stimmte Szenarien nähergebracht werden. Dabei erfolgt durch eine bestimmte Aktion des Nut-
zers genau dieselbe Reaktion. Nützlich kann dies sein, wenn beispielsweise vor allem bestimmte
Arten von Verhalten mit einer bewussten Auswirkung erläutert werden sollen.
2.2.3.2.3. Formular
Ein strukturiertes Dokument mit Leerstellen, die für die Eingabe seitens des Lernenden zur Verfü-
gung stehen, bezeichnet man im Allgemeinen als Formular. Dabei existieren verschiedene Mög-
lichkeiten, Steuerelemente in ein solches Dokument zu integrieren. In vielen Fällen dienen For-
mulare als Testsystem oder der Steigerung der Interaktivität eines Szenarios.
2.2.3.2.4. Interaktiver Film/Video
In einem interaktiven Film hat der Lernende die Möglichkeit, an bestimmten Positionen den Fort-
gang des Films zu beeinflussen. Hier kann der Grad der Motivation deutlich erhöht werden, da
ein Film, der in viele Teilstücke mit semantischer Kennzeichnung zerlegt wird, nicht die sukzessi-
ve Abarbeitungsreihenfolge der Wissensübermittlung erfordert, sondern stattdessen der Lernen-
de selbst entscheidet, nach welchem Schema Informationen vermittelt werden.
16
Unsere Hauptaufgabe ist nicht,
zu erkennen, was unklar in weiter Entfernung liegt,
sondern zu tun, was klar vor uns liegt.
Thomas Carlyle (1795 - 1881)
3
Die Testumgebungen
Einst war das Alter, da Ymir lebte:
Da war nicht Sand nicht See, nicht salzige Wellen,
Nicht Erde fand sich noch Überhimmel,
Gähnender Abgrund und Gras nirgends.
Eingeleitet durch einen Auszug aus der Völuspa in der älteren Edda [Kra04], in welchem die
Entstehung der Welt nach nordischer Mythologie beschrieben wird, beginnt an dieser Stelle die
eigentliche Arbeit. Dieses Kapitel dient der kurzen Definition des Anforderungsprofils sowie der
Vorstellung der Testumgebungen. Analog zur Entstehungsgeschichte der Welt müssen ein klares
Ziel und ein Weg dorthin existieren, an dem Dinge, Prozesse, Szenarien definiert, analysiert und
überhaupt umgesetzt werden können. Bezogen auf diese Arbeit, ist der Weg für die Versuchsauf-
bauten sowie die sich anschließende Visualisierung zu ebnen.
Im ersten Abschnitt wird zunächst das Anforderungsprofil konkretisiert und die dort aufge-
führten Punkte gelten als zukünftige Vorgehensweisen bezüglich der Testumgebungen. Abschnitt
3.2 dient der weiteren formalen Abgrenzung der Arbeit. Im Abschnitt 3.3 wird näher auf die Be-
schreibung der Testumgebungen eingegangen. Testkomponenten, die für die Arbeit notwendig
gewesen sind, werden dort näher aufgeführt. Darauf aufbauend ist es in Abschnitt 3.4 notwendig,
das DBMS näher vorzustellen. Dabei werden die verwendeten Relationen sowie Konfigurationen
17
3. Die Testumgebungen
von DBMS-spezifischen Komponenten näher erläutert, die in dieser Arbeit vorgenommen wur-
den.
3.1. Konkretisierung der Anforderungen
Das hier zu postulierende Anforderungsprofil richtet sich nach der Thematik der vorliegenden
Arbeit und erst durch die Auswahl zu bearbeitender Inhalte entsteht ein klares Anforderungspro-
fil. Anders als bei ,,herkömmlichen" Arbeiten steht hier nicht die programmiertechnische Imple-
mentierung von Testfällen oder ausgewählten Umsetzungen im Vordergrund, sehr wohl jedoch
die damit verbundene Vorgehensweise und die Schlussfolgerungen. In gewisser Weise gleicht
diese Beschreibung einem kybernetischen System, folgt doch anhand einer Eingabe die Ausgabe
und die erneute Überprüfung auf Anpassung oder Optimierung dieses Regelkreises. Dennoch
ist zu überlegen, welche grundlegenden Anforderungen beziehungsweise Disziplinen als allge-
meingültige Anforderungen vorliegen.
Generisch:
Es liegt nicht im Interesse dieser Arbeit, mögliche Problematiken eines DBMS oder
dessen Features aufzuzeigen. Ziel ist vielmehr die Abbildbarkeit von Tests und deren Aus-
wirkungen auf möglichst viele DBMS-Hersteller zu erreichen.
Grenzszenario:
So genannte Break-Even-Points einer Thematik sind von großem Interesse. Wei-
tere Tests und Szenarien zur Bearbeitung oder Diskussionen können hierauf aufbauen.
Nachbildungsarm:
Die Analyse von Grenzszenarien ist auch deshalb so wichtig, da sie in kaum
einem Lehr- oder Fachbuch beschrieben wird und auch in allgemeinerer Literatur nicht
behandelt wird. Allgemeine Definition dienen in dieser Arbeit nur an einzelnen Punkten
der erläuternden Gegenüberstellung.
Inhärente Betrachtung:
Möglichst ohne große Einwirkung anderer Komponenten - wie bestimm-
te Funktionalitäten beziehungsweise Einstellungen - sind diese soweit wie möglich zu un-
terbinden oder entsprechend so zu konfigurieren, dass eine geringe Beeinträchtigung bezie-
hungsweise Verfälschung zum Analysezeitpunkt
1
vorliegt.
Aufbauender Wissenshorizont:
Die Tests in den Kapiteln 4 bis 6 unterliegen einem bestimmten
Wissenshorizont. Zu Beginn jedes Kapitels ist nur ein geringes Hintergrundwissen vorhan-
den, das bewusst unscharf gehalten wird. Aufbauend auf dem Wissen, das dem Leser da-
durch in kleinen Schritten vermittelt wird, entsteht aus vielen einzelnen Aspekten sukzes-
sive ein Bild von der Problematik der Performance-Optimierung.
1
Der Analysezeitpunkt ist der Punkt, zu welchem in das DBMS eingegriffen wird, um Informationen zum ausge-
führten Statement zu erhalten.
18
3. Die Testumgebungen
Auswahl geeigneter Visualisierungsthemen:
Nachdem in den Kapiteln 4 bis 6 verschiedene Ver-
suche durchgeführt wurden, müssen auf Basis der Auswertungen geeignete Visualisierungs-
themen ausgewählt werden.
Wirkungsweisen von Optimierungsstrategien:
Die Auswahl geeigneter Visualisierungsszenari-
en auf Basis von Visualisierungsthemen ist ein wichtiger Aspekt dieser Arbeit, da die zu
behandelnden Themen auch in einer geeigneten didaktischen Art und Weise umgesetzt
werden sollen.
Wissenschaftliche Arbeiten, die einen eher allgemeinen Mehrwert bieten und weniger auf ein
Thema spezialisiert sind, sprechen eine breitere Gruppe von Nutzern an. Zwar wird in der vorlie-
genden Arbeit ein bestimmtes DMBS behandelt, jedoch ist es wichtig, allgemeine Vorgehenswei-
sen des jeweiligen DBMS zu nutzen. Des Weiteren werden anhand relativ einfach konstruierter
Versuche diejenigen Auswirkungen dargestellt, die bestimmte Probleme oder daraus resultieren-
de Fragestellungen genau aufzeigen. Die Fachliteratur selbst zeigt hierfür mögliche Lösungswege
oder Vorgehensweisen zur Optimierung oder Lösung auf, stellt diese jedoch nur grob dar (siehe
Kapitel 1).
In einer wissenschaftlichen Umgebung müssen Dinge oder Vorgänge oftmals einzeln betrach-
tet werden. Daraus folgt eine Deaktivierung beziehungsweise eine günstige Parametrisierung
der beteiligten Systeme und Komponenten, die für die jeweiligen Versuche auf das Testergebnis
einwirken. Jedoch gilt hier, ähnlich wie nach Heisenberg
2
, das Problem der Genauigkeit bezie-
hungsweise der Granularität des zu untersuchenden Gegenstands.
In den folgenden Abschnitten werden die geforderten Aspekte konzeptartig spezifiziert.
3.2. Abgrenzung
In dieser Arbeit ist es nicht das Ziel, OLAP
3
, OLTP
4
oder DSS
5
-Systeme zu simulieren. Grundlage
bilden vielmehr die SELECT-Operationen. Demzufolge grenzt die Thematik alle Problematiken,
die durch DML-Operationen entstehen könnten, ab. UPDATE- oder DELETE-Anweisungen als
Basis für diese Arbeit zu nehmen, kam in dieser Hinsicht nicht in Frage. Ziel der vorliegenden
Arbeit ist es, die häufigsten kritischen Bereiche von DBMS-Anweisungen zu entdecken und zu
verfolgen. DML bietet dagegen eine hervorragende Fortführung, da ein optimiertes DBMS im
SELECT
-Bereich, nicht annähernd ein Garant für eine schnelle Laufzeit darstellt. Folgendes Bei-
spiel veranschaulicht dies: Eine Anwendung übt häufige DML-Befehle an ein DBMS ohne einen
Teil jeweils zu bestätigen
6
; stattdessen erfolgt diese ressourcenlastige Anweisung erst am Ende.
2
Die Heisenberg'sche Unschärferelation, vgl. http://de.wikipedia.org/wiki/Werner_Heisenberg, 25. Juni 2008
3
Online Analytical Processing
4
Online Transaction Processing
5
Decision Support System
6
Commit;
19
3. Die Testumgebungen
Fatalerweise führt - wie es in [PG02]
7
beschrieben ist - eine stark verzögerte Bestätigung von ei-
ner bestimmten Anzahl an DML-Operationen zu einem hohen Aufwand seitens des DBMS. Nicht
nur nimmt der DBMS-Bereich zur temporären Protokollierung der Änderungen immer größere
Ausmaße, sondern auch andere Transaktionen gefährden durch weitere Änderungen ohne regel-
mäßiges Bestätigen die Leistungsfähigkeit das DBMS. Nach [Mul02]
8
und [Shi03]
9
ist so zeitnah
wie möglich ein Commitment abzugeben, um Ressourcen zügig freizugeben.
3.3. Konzeption der Umgebungen
In diesen Abschnitt werden die experimentellen Szenarien und die Testplattform ausgewählt.
Dabei sind die im Abschnitt Konkretisierung der Anforderungen formulierten Punkte zu konkreti-
sieren. Die experimentellen Szenarien stellen dabei die zu visualisierenden Teile dar, während die
Konzeptionierung der Testplattform für die Kapitel 4 bis 6 von Bedeutung ist.
3.3.1. Testplattform
Zunächst ist es notwendig, den Rahmen für die Versuchsaufbauten zu beschreiben.
3.3.1.1. System
Die Hardware sowie das Betriebssystem, auf welchem Aufbau und Durchführung erfolgen, wird
nicht separat ausgewählt; vielmehr findet eine vorhandene Konfiguration Verwendung, die für
die jeweiligen Tests vollkommen ausreichend ist.
CPU
3.400 MHz
L2 Cache
512 Kilobyte
Arbeitsspeicher
2.048 DDR2
Massenspeicher (7.200 rpm)
2x80 GB
Tabelle 3.1.: Auflistung der verwendeten Hardwarekomponenten
Als Betriebssystem ist Windows XP die bevorzugte Wahl gewesen. UNIX kam in diesen Fall
aus Installationsgründen nicht in Frage.
3.3.1.2. Datenbankmanagementsystem
Es gilt an dieser Stelle nicht, eine weitreichende Analyse hinsichtlich verschiedener DBMS-Hersteller
zu präsentieren, sondern vielmehr ein DBMS zu wählen, welches in der Lage ist, alle benötigten
Anforderungen an die Tests zu erfüllen sowie bei optionalen Features eine Spitzenposition ein-
nimmt. Dabei ist darauf zu achten, dass die jeweiligen Funktionalitäten dieses DBMS auf mög-
lichst viele andere Systeme abbildbar sind. Natürlich sind verschiedenartige Konfigurationen in
7
Seite 337
8
Seite 348
9
Seite 494
20
3. Die Testumgebungen
einem DBMS nicht immer in anderen DBMS verfügbar, jedoch muss die gleiche Vorgehensweise
möglich sein. Die Frage, ob ein DBMS wie DB2
10
, Oracle
11
, Informix
12
oder PostgreSQL
13
Verwen-
dung finden soll, stellt sich demnach nicht im Detail. Stattdessen erfolgt die Selektion eher aus
pragmatischen Gründen und ist vor diesem Hintergrund auf das System des DBMS-Herstellers
von Oracle in der Standard-Edition gefallen.
14
Unzählige Features von Oracle sind schon vor der
offiziellen Spezifikation in einem aktuellen Standard implementiert, gewesen (siehe Abschnitt
2.1.1). Oracle hat fortwährend an den Standards mitgearbeitet und ist hier teilweise auch heute
noch teilweise federführend. Durch die Stellung, die Oracle in diesen Sektor genießt, behält sich
der DBMS-Hersteller vor, vom Standard abweichende Implementierungen vorzunehmen. Natür-
lich ist es das Ziel jedes DBMS, gewisse Alleinstellungsmerkmale zu besitzen - daraus ergeben
sich schließlich schon alleine in SQL verschiedenartige ,,Dialekte".
Oracle hingegen ist beispielsweise dem SQL2003-Standard im Hinblick auf den objektrelatio-
nalen Teil einen Schritt voraus. Anders als in der SQL2003-Spezifikation vorgesehen und wie
von anderen Herstellern implementiert erfolgt die Vergabe einer eindeutigen Objektidentifikati-
on nicht tabellen-, sondern systemweit. Dies schließt Anomalien in Views beispielsweise komplett
aus, wenn zwei Objekte mit zwei gleichen Objektnummern verbunden werden. Konzeptionelle
Schwächen
15
in der SQL-Spezifikation versucht Oracle auf eigene Art und Weise zu lösen oder zu
ignorieren. Beispielsweise ist dem DBMS-Hersteller die Verwendung von so genannten Distinct-
Typen
16
gänzlich unbekannt. DB2 sowie PostgreSQL implementieren dagegen diesen Standard
[CT05] [WP00].
3.3.1.3. Benchmarking-Programme oder Einzeltests
Auch hier stellt sich die Frage, nach dem Punkt, den es zu erreichen gilt. Sind spezifische Fälle
oder komplette Szenarien zu simulieren, die in der realen Welt vorkommen können? Beide Vari-
anten sind interessant, jedoch baut eine Thematik unmittelbar auf einer anderen auf. Das heißt,
dass ein falsch konfiguriertes DBMS im Regelfall auch Auswirkungen auf die Resultate eines
Benchmarks hat. Andererseits gibt es jedoch auch Situationen, in denen selbst keine Performance-
Probleme auftreten - in einem Benchmarktest dann aber sehr wohl. Benchmarking-Programme
eignen sich, wenn sowohl die Anwendung als auch das DBMS nach besten Gewissen optimiert
10
vgl. http://www-306.ibm.com/software/data/db2/, 30. Juni 2008
11
vgl. http://www.oracle.com/lang/de/database/index.html, 30. Juni 2008
12
vgl. http://www-306.ibm.com/software/data/informix/, 30. Juni 2008
13
vgl. http://www.postgresql.org/, 30. Juni 2008
14
Von einem pragmatischen Standpunkt aus betrachtet, liegt ein wesentlicher Vorteil der Verwendung von Oracle
darin, dass dem Autor dies durch Arbeiten bei FuThuer(www.FuThuer.de - Eine Initiative zur mittel- bis lang-
fristigen Sicherung des Fachkräftebedarfs in Thüringen) oder im DatabaseCompetence Center(http://dbcc.fh-
schmalkalden.de/, 09.Juli 2008) bekannt ist.
15
Beispielsweise die Domänen-Spezifikation in SQL92. Erst durch die Verwendung von Distinct-Typen ist das Kon-
zept von Domänen für die Entwicklung interessant.
16
Diese Typen basieren auf Basisdatentypen wie NUMBER oder VARCHAR. Sie stellen demnach eine exakte Kopie
dieser dar, allerdings mit strenger Typisierung. Das heißt, zwei unterschiedliche Distinct-Typen, die von einem
gleichen Basisdatentyp definiert sind, können nicht ohne weiteres miteinander verglichen werden.
21
Details
- Seiten
- Erscheinungsform
- Originalausgabe
- Jahr
- 2008
- ISBN (eBook)
- 9783836617802
- DOI
- 10.3239/9783836617802
- Dateigröße
- 6.8 MB
- Sprache
- Deutsch
- Institution / Hochschule
- Hochschule Schmalkalden, ehem. Fachhochschule Schmalkalden – Informatik
- Erscheinungsdatum
- 2008 (August)
- Note
- 1,1
- Schlagworte
- datenbank tuning performance dantenbanktuning oracle
