Datenbanktuning und deren Wirkungsweise

Diplomarbeit von Sebastian Wenzky

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 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 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.

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 über einen Indexzugriff 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. Ist dadurch mit einer deutlich schlechteren Bearbeitungszeit zu rechnen? Die Frage nach der Wirkungsweise von Tuningaspekten gilt es aus diesem Grund zu hinterfragen.

Ein Auszug aus einem anderen Fachbuch wirft ebenfalls eine weitere Frage von allgemeinem Charakter auf:

The optimum page size is related to the disk system´s attributes. Smaller page sizes like 2KB were once thenorm, 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 ziehen: 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 Konsequenzen 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 „Wissen“ visualisiert werden? Hier gilt es die Vermittlung möglicher Vor- als auch Nachteile durch die Anwendung von Tuningaspekten zu untersuchen.

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, auf dem die vorliegende Arbeit zu Teilen basiert, ein praktischer Nutzen erzielt werden.

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 resultiert 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 werden? Die Implikationsregel ist ein einfaches Beispiel, um die Komplexität einer Entscheidung zu 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 Arbeit die Indexstrukturen sowie die kleinsten Speichereinheiten in Form von unterschiedlichen Versuchsaufbauten betrachtet. Insbesondere die hohe Abhängigkeit zwischen diesen beiden Parteien wird in diesem Zusammenhang aufgezeigt.

Je nach Verlauf der jeweiligen Szenarien ist es dann notwendig, weiterführende Analysen vorzunehmen, 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.

Gang der Untersuchung:

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 experimentelle Plattform 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. Weiterhin wird dort eine konkrete Einführung in wichtige Komponenten(Cache, Indexstrukturen, Datenblöcke) eines Datenbanksystems gegeben.

Kapitel 3: In Kapitel 3 werden die Testplattformen spezifiziert; die Anforderung der Versuchsaufbauten wird in Abschnitt 3.1 benannt und genau beschrieben. Abschnitt 3.2 grenzt die Arbeit in ihrem Inhalt ab. Im Abschnitt 3.3 erfolgt anschließend die Konzeptionierung der Umgebungen10.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 Versuchsaufbauten (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 Versuchsaufbau 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 Abschnitt 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 ausgewä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 vorliegende Arbeit.

Inhaltsverzeichnis:

1.	Das erste Kapitel	1
1.1	Motivatio	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
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 Darstellung87
5.3	Auswirkungen unterschiedlicher Blockgrößen. 88
5.3.1	Versuchsaufbau	89
5.3.2	Versuchsdurchführung	89
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
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

Textprobe:

Kapitel 4.2.3, Index und E/A-Zugriffe Im vorangegangenen Abschnitt wurde festgestellt, dass der Index nicht in jedem Fall schlechte Ergebnisse bezüglich der Anfragezeit liefert. Daher wird in diesem Teil die Ursache für das sprunghafte Verhalten der Anfragezeit von einem Testpunkt zum nächsten untersucht.

Ursachenforschung:

Es muss zuerst eine Möglichkeit gefunden werden, das oben beschriebene Verhalten zu ergründen. Die Schwierigkeit besteht jedoch darin, dass momentan ein plausibler Anhaltspunkt fehlt, in welcher Ebenebeziehungsweise Komponente des DBMS die Bearbeitung des Statements zu einem Flaschenhalsproblem führt. Man könnte etwas polemisch formulieren, dass es sich möglicherweise auch nicht um ein Problem des DBMS handelt, sondern das Problem von einer (Betriebssystem-)Komponente „weitergegeben“ wird. Kann dann theoretisch nicht auch die Annahme korrekt sein, das dass Betriebssystem und dessen Verwaltung der Zugriffe auf den Primär- und Sekundärspeicher dafür verantwortlich ist? Vielleicht besteht keine Möglichkeit diese Problematik zu lösen, weil das Problem außerhalb der Möglichkeiten eines Administrators liegt, nämlich im Systemkern?

Jedoch ist die spekulative Suche nach einer Ursache an dieser Stelle nicht zielführend und es wird nunmehr nach dem Top-Down-Prinzip die Ursache gesucht. Ein erster wissenschaftlicher Anhaltspunkt für die deutliche Verschlechterung der Anfragezeit ist dem allgemeinen Architekturaufbau nach den Fachbüchern (RE02), (TH01) oder (Tow03) zu entnehmen. So findet man in (Tow03) folgendes:

Every time the database must access a block of data not already in cache, it requests a read from disk and places the newly populated block at the head end of the buffer list. Since the list length is fixed while the database runs, adding a block at the head end forces the block at thetail end of the list to fall off.

Welche Implikation ergibt sich aus dieser Erläuterung zur Verhaltensweise des Caches? Wird zunächst - als eine Möglichkeit, eine Anfrage schnell zu bearbeiten, - ein Index-Zugriff betrachtet, spielt die Granularität eine große Rolle. Ein Index-Zugriff greift auf diejenigen Datenblöcke zu, in welchen garantiert relevante Datensätze vorzufinden sind. Dadurch, dass eine hohe Granularität vorliegt, verändern sich Blockgruppierungen eines Caches nur minimal, da 10 Datenblöcke bedeutend besser im Cache gehalten werden können als beispielsweise das 100-fache bei einem Tabellenzugriff. Obwohl im aktuellen Beispiel der Effizienz eine hohe Anfragezeit gegenübergestellt ist, liegt eine hohe Granularität vor. Die Betrachtung von Abbildung 4.6 zeigt deutlich die Anfrage nach Datenblöcken von der Platte ab dem Break-Even-Point.

Durch die oben beschriebene Granularität ist der Index jedoch weit unter dem Bereich eines Tabellenzugriffs. Das wirft eine weitere Frage auf. Denn folgt man den E/A-Anfragen, also den sequentiellen Blockzugriffen, stehen diese in keinem Verhältnis zu einem FTS. Vergleicht man sie jedoch mit dem Verlauf der E/A-Wartezeit in Abbildung 4.6, ergibt sich ein paradoxes Schaubild; in Abbildung 4.6 sind beide Testergebnisse zusammengefasst. Eigentlich sollte, ausgehend von der Theorie, nur ein kleiner Teil vom Sekundärspeicher nachgeladen werden - die 50 fehlenden Datensätze. Nur die E/A-Wartezeit liegt um ein Vielfaches über derjenigen, die 50 Datensätze hervorrufen könnten.

Mutmaßung:

Aus diesen Erkenntnissen heraus können theoretisch folgende Schlüsse gezogen werden: Da ein Index-Zugriff ab einer bestimmten Datenmenge scheinbar nicht mehr in der Lage ist, alle geforderten Daten im Cache zu halten beziehungsweise das DBMS diese dort nicht vorfindet, werden Anfragen an die Platte erzeugt, um die benötigten Blöcke bereitzustellen. Daraus folgt, dass im Cache nur wenige benötigte Datenblöcke zur Verfügung stehen, die auf das Statement passen, trotz hoher Granularität. Sollte diese Erklärung zutreffen, kann das vorliegende Problem unter Umständen gelöst werden. Hierfür sind jedoch weitere Untersuchungen der Hypothese notwendig.

Weitere Vorgehensweise:

Im nächsten Schritt werden auf Basis der aufgestellten Hypothese aufeinander aufbauende Tests initiiert, um Besonderheiten im Cache zu finden. Der Cache ist hier so interessant, da er alle benötigten Informationen zum Status der zwischengespeicherten Blöcke enthält. Der erste Test beschäftigt sich mit der konkreten Vorgehensweise des DBMS bei einem Index-Zugriff. Dabei ist zunächst festzustellen, in welcher „Reihenfolge“ das DBMS die benötigten Datenblöcke akquiriert.

Test 1: Reihenfolge der Index-Zugriffe:

Um die Reihenfolge der Akquirierung der Datenblöcke zu bestimmen, sind konkret zwei Wege denkbar. Zum einen lässt sich durch die wiederholte Ausgabe aller Tupeln bei der Ausführung des Statements die Reihenfolge bestimmen. Etwas eleganter ist es jedoch, die in Oracle vorhandene Funktion zu nutzen, mittels der die Zugriffe auf ein Tupel in Blockadressen umgerechnet werden. Zur weiteren Analyse werden diese dann beispielsweise in einer Textdatei oder als LOAD AS SELECT15-Direktive in der Datenbank gespeichert. Dieser Test wird mehrmals wiederholt, um zu prüfen, ob das DBMS beim nächsten Fetchen eventuell eine andere Reihenfolge wählt. Die Differenz der verschiedenen Versuchsauswertungen kann auf verschiedene Arten ermittelt werden. Als Beispiel dient hier ein Java-Programm als Helfer, welches die Daten gemäß Abschnitt 4.2.1 auf Abweichungen untersucht.