Datenbanken II Optimierung von Datenbanken von
Werbung
Datenbanken II Optimierung von Datenbanken von Bettina Keil 45748 MIM 07 Inhaltsverzeichnis 1 Motivation 1 2 Phase 1.1: Optimierung des Datenbankschemas 2 2.1 Ziel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.2 Konzeptuelles Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.3 Internes Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.4 Externes Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3 Phase 1.2: Anwendungsoptimierung 5 3.1 Ziel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2 Optimierung der Anwendung . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3 Optimierung im Mehrbenutzerbetrieb . . . . . . . . . . . . . . . . . . . . 6 3.4 Formulierung von SQL-Anweisungen . . . . . . . . . . . . . . . . . . . . . 7 4 Phase 2: Hauptspeicheroptimierung 8 4.1 Ziel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2 Optimierung des Datenbankpuffers . . . . . . . . . . . . . . . . . . . . . . 8 4.3 Optimierer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5 Phase 3: Eingabe-/Ausgabeoptimierung 12 5.1 Ziel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.2 Betriebssystemfunktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.3 Lastverteilung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.4 Optimierung der physischen Speicherstrukturen . . . . . . . . . . . . . . . 13 6 Zusammenfassung 15 7 Quellenverzeichnis 16 i 1 Motivation Bei der Verwaltung großer Datenmengen mittels Datenbanken nimmt mit wachsender Zahl der Datensätze die Wichtigkeit der Performance der Datenbank zu. Diese kann auf vielfältige Weise gesteigert werden: Die Erstellung eines optimalen Datenbankschemas bildet den Grundstein einer effizient nutzbaren Datenbank. Weiterhin können Bereiche wie Anfragen oder Hardware in Bezug auf die Performance analysiert und umstrukturiert werden. Ein einfacher aber kostenintensiver Weg zur Performancesteigerung ist die Aufrüstung der Rechnersysteme durch Hinzufügen zusätzlicher Hardware. Durch eine geschickte Optimierung der bestehenden Datenbank können diese finanziellen Mehrbelastungen umgangen werden. Hauptmotivation ist die Verkürzung der Antwortzeiten in Verbindung mit einem erhöhten Datendurchsatz. Die Optimierung von Datenbanken umfasst 4 Phasen: In Phase 1 wird eine Optimierung des Datenbankschemas sowie eine Anwendungsoptimierung vorgenommen. Dabei liegt der Fokus auf der Schaffung eines effizient nutzbaren Datenbankschemas in Bezug auf die Anwendung, für welche die Datenbank konstruiert wurde. Ziel ist es, den Großteil der meistgenutzten Daten im Datenbankpuffer halten zu können. Die Anwendungsoptimierung zielt darauf ab, ineffiziente Datenbankanfragen zu vermeiden und Anfragen allgemein zu otpimieren. In Phase 2, der Hauptspeicheroptimierung, wird durch Anpassung des Datenbankpuffers und des Optimierers eine Minimierung der Anzahl physischer Speicherzugriffe angestrebt. In Phase 3, der Eingabe-/Ausgabeoptimierung bzw. Optimierung der Sekundärspeicherzugriffe, werden die in Phase 2 in der Anzahl minimierten physischen Zugriffe auf den Sekundärspeicher in ihrer Ausführung optimiert. Phase 4, die Konfliktoptimierung, dient dem Lösen verbleibender Zugriffskonflikte innerhalb der logischen Strukturen der Datenbank. In den folgenden Kapiteln werden die Phasen 1-3 näher beschrieben sowie detaillierte Optimierungsansätze dargestellt. Auf Phase 4, die Konfliktoptimierung, wird nicht näher eingegangen, da es sich um fallspezifisch vorzunehmende Konfliktlösungen handelt. 1 2 Phase 1.1: Optimierung des Datenbankschemas 2.1 Ziel Durch die Optimierung des Datenbankschemas soll die Anzahl der für die Anwendung der Datenbank benötigten Zugriffe auf die Datenbank minimiert werden sowie die verbleibenden Zugriffe in der Formulierung ihrer Anfragen optimiert werden. Die Erstellung des Datenbankschemas erfolgt nach dem relationalen Datenmodell, welches die in Tabellen gespeicherten Daten durch entsprechende Operationen mengenorientiert verknüpft und verarbeitet. Daraufhin folgt eine weitere Verfeinerung des Datenbankschemas durch Normalisierung, wobei das Schema in eine bestimmte Normalform gebracht wird. Diese sind die Erste Normalform, die Zweite Normalform, die Dritte Normalform, die Boyce-Codd Normalform und die Vierte Normalform. Das Datenbankschema besteht nach ANSI-SPARC aus einem internen Schema (Datenverwaltung auf Platte, Indexstrukturen, ...), einem konzeptuellen Schema (Beschreibung der Gesamtstruktur, Integritätsbedingungen, ...) und i.a. mehreren externen Schemata (Sichten für verschiedene Anwendungen, Benutzergruppen, ...). Innerhalb dieser drei Ebenen der Drei-Schema-Architektur bestehen Möglichkeiten für die Optimierung des Datenbankschemas. 2.2 Konzeptuelles Schema Innerhalb des konzeptuellen Schemas wird die Gesamtstruktur der Datenbank für alle Benutzer beschrieben, welche sich auf die Objekte, die Datentypen, die Beziehungen untereinander und die Operationen bezieht. Mögliche abstrakte Datenmodelle für die Modellierung des Schemas sind das relationale Datenmodell und das Entity-RelationshipModell. 2 KAPITEL 2. PHASE 1.1: OPTIMIERUNG DES DATENBANKSCHEMAS 3 Ein erster Ansatzpunkt für die Optimierung im konzenptuellen Schema ist die Zuweisung von Datentypen bei Attributen. Bei der Verwendung von Attributen sind variabel lange Datentypen oft sehr teuer, wenn zusätzlicher Speicherplatz bei einer Vergrößerung der Werte beschafft werden muss. So sollte z.B. statt VARCHAR der statische Datentyp CHAR genutzt werden, falls bekannt ist, dass sich die Größe des Attributs mit hoher Wahrscheinlichkeit ändern wird, jedoch mit Hinblick auf den grundsätzlich höheren Speicherbedarf dieses Datentyps. Somit ist im Zusammenhang mit den genutzten Werten abzuwägen, ob von vorneherein große Datentypen verwendet werden und somit ein hoher Speicherbedarf in Kauf genommen wird oder ob variable Datentypen genutzt werden, bei deren Vergrößerung kostspielige Operationen ausgeführt werden müssen. Ein weiterer Optimierungspunkt sind Tabellen: Beim Anlegen von Tabellen sollte die Nutzung der Daten in der Anwendung genauso berücksichtigt werden wie die semantischen Beziehungen der Entitäten sowie die Aspekte der Normalisierung. Bei der Normalisierung kann eine hohe Anzahl von Tabellen entstehen, die unter Anwendungsaspekten und bei Auftreten von 1:1-Muss-Beziehungen zusammengefasst werden können. Umgedreht können auch Tabellen einer vertikalen Partitionierung - analog führt auch eine horizontale Partitionierung zu mehr und kleineren Tabellen - unterzogen werden, sofern einige Attribute nur selten genutzt werden, die allerdings bei Anfragen auf die oftgenutzten Attribute die Suche behindern. Wie eben bereits angedeutet, bedeutet eine Normalisierung nicht immer die effizienteste Lösung eines Datenbankkonzepts für die Anwendung. Zwar werden dadurch Redundanzen vermindert bzw. eliminiert, jedoch kann durch gezielte Denormalisierung - und somit auch Wiedereinführung von Redundanzen - eine bessere Performance erreicht werden, da Verbundoperationen umgangen werden, wodurch allerdings ein höherer Aufwand bei der Wartung der Redundanzen entsteht. Redundanzen sind nicht immer nur exakt doppelt vorkommende Attribute, die meist vermieden werden sollen. Redundanzen erstrecken sich auch auf abgeleitete Attribute, womit Atrribute bezeichnet werden, die aus Kombination bzw. Modifikation anderer Attribute hergeleitet werden können, sofern dies durch das Datenbanksystem effizient unterstützt wird. 2.3 Internes Schema Innerhalb des internen Schemas, auch physisches Schema genannt, wird die Datenverwaltung auf der Platte beschrieben sowie Zugriffspfade wie z.B. Indexstrukturen definiert. Je nach Anwendungsfall kann die Nutzung eines bestimmten Indexes Vorteile bei Datenbankoperationen bringen. Für das Anlegen eines Indexes auf eine Spalte sprechen KAPITEL 2. PHASE 1.1: OPTIMIERUNG DES DATENBANKSCHEMAS 4 u.a. die folgenden Gründe: die Spalte wird häufig in Suchprädikaten referenziert, die spalte bildet einen Primär- oder Fremdschlüssel und/oder die Spalte besitzt eine hohe Selektivität. Gegen einen Index sprechen folgende Gründe: die Spaltenwerte ändern sich häufig, die Spalte kann NULL-Werte enthalten und/oder die Spalte gehört zu sehr kleinen Tabellen. Neben Indexen auf ein Attribut exisitieren verkettete Indexe, bei denen der Schlüssel aus zwei und mehr Attributen zusammengesetzt ist. Diese Indexe sind für AND-Argumente in der WHERE-Klausel einer Anfrage von Vorteil. Ähnlich wird das Überladen von Indexen genutzt, wenn über den Index auf die gesamte Tabelle zugegriffen werden soll, somit die angehängten Spalten mitgezogen werden. Dies kann natürlich auch nachteilig sein, sofern nicht alle Spalten genutzt werden, es wird von nutzlos überladenen Indexen gesprochen. 2.4 Externes Schema Innerhalb der meist vielfältigen externen Schemata werden - neben Prozeduren und Funktionen - Sichten, für verschiedene Anwendungen und Benutzergruppen angelegt, wodurch nur ein gewisser, anwendungsspezifischer Ausschnitt der Daten sichtbar ist. Nichtbenötigte Daten bleiben verborgen. Bei der Nutzung von Sichten sollte beachtet werden, dass diese, sofern sie ausschließlich auf einer Tabelle operieren, besser vermieden werden, da sonst unnötige Verbundoperationen zur Ersetllung der Sicht durchgeführt werden müssen. Durch Prozeduren, speziell prozedurale SQL-Erweiterungen datenbankinterner Prozeduren, lassen sich Teile der Anwendung in die Bearbeitung durch das Datenbankmanagementsystem übertragen. Außerdem können verschiedene SQL-Anweisungen zusammengefasst, kompakt übertragen und direkt auf der Datenbank ausgeführt werden. Dadurch werden Anwendung und Netzwerk, somit die Kommunikationskanäle zwischen Anwendung und Datenbank, entlastet, jedoch auf Kosten der CPUs des Datenbanksystems, welche einer höheren Belastung durch die Ausführung der Prozeduren ausgesetzt sind. 3 Phase 1.2: Anwendungsoptimierung 3.1 Ziel Ähnlich der Optimierung des Datenbankschemas soll durch die Anwendungsoptimierung die Anzahl der für die Anwendung der Datenbank benötigten Zugriffe auf die Datenbank minimiert sowie die verbleibenden Zugriffe in der Formulierung ihrer Anfragen optimiert werden. Bei der Betrachtung der Daten sowie der Zugriffe auf die Daten der Datenbank in Hinblick auf eine Anwendungsoptimierung wird eine vorherige Optimierung der Geschäftsprozesse durch beispielsweise ein Workflow-Management vorausgesetzt. Dies soll bereits vor Erstellung des Datenbankschemas eine unnötige Belastung des Datenbankmanagementsystems vermeiden sowie die benötigten Daten und Anfragen minimieren. Von einem optimierten Datenbankschema ausgehend, bieten sich mehrere Ansatzmöglichkeiten für die Anwendungsoptimierung. Diese beziehen sich einerseits auf die tatsächliche Optimierung der Anwendung sowie auf die Formulierung der SQL-Anweisungen. Ein wichtiger Ansatz ist weiterhin die Optimierung im Mehrbenutzerbetrieb hinsichtlich Transaktionen und deren Synchronisation. 3.2 Optimierung der Anwendung Bei der Optimierung der Anwendung wird vorrangig das Vermeiden überflüssiger Daten in Datenbankanfragen angestrebt. Dadurch wird die Kommunikation mit dem Datenbankmanagementsystem reduziert sowie die Hauptspeicher- und Zugriffseffizienz hinsichtlich Speicherbedarf, Datenmenge und somit Zugriffszeiten erhöht. Die Reduktion der Kommunikation zwischen Anwendung und Datenbankmanagementsystem ist ein wichtiges Ziel bei der Optimierung. Bei der Abwägung von satzorientiertem gegen mengenorientierten Datenzugriff, sollte auf letzteren zurückgegriffen werden sofern die Anwendungsanforderungen erfüllt werden können. Gegenüber einer wiederholten satzorientierten Bearbeitung in Schleifen, vermindert eine geschickte mengenorientierte 5 KAPITEL 3. PHASE 1.2: ANWENDUNGSOPTIMIERUNG 6 Bearbeitung den Zugriff auf die Datenbank. Daten können im Nachhinein aus dem größeren Datensatz durch die Anwendung satzweise bearbeitet werden. Bei der Formulierung von Datenbankanfragen sollte darauf geachtet werden, dass strukturgleiche Anfragen identisch formuliert werden. Selbst bei kleinen Unterschieden - beispielsweise die Verwendung von zwei Leerzeichen zwischen den Worten statt eines Leerzeichens - kann es dazu führen, dass der Parser des Datenbankmanagementsystems den Ausführungsplan neu berechnet, wodurch Performance eingebüßt wird. Unterscheiden sich Anfragen lediglich im Wert des Suchprädikats, können sogenannte Hostvariablen genutzt werden, eine Art Platzhalter, der durch die jeweiligen Werte ersetzt wird. Der Parser muß dann den Ausführungsplan nur einmal berechnen. Die Rechenzeit wird reduziert und Hauptspeicherplatz gespart. 3.3 Optimierung im Mehrbenutzerbetrieb Durch den Mehrbenutzerbetrieb können Ressourcen besser ausgenutzt werden, da bei Wartezeiten eines Prozesses ein anderer Prozess die Rechenleistung nutzen kann, bis er selbst auf Betriebsmittel oder Nutzereingaben warten muß. Für die Kontrolle bezüglich der Konsistenzerhaltung im Mehrbenutzerbetrieb wird das Prinzip der Isolation aus dem ACID-Paradigma zugrunde gelegt: Jede Transaktion sieht die Datenbank so, als sei sie selbst die einzige darauf laufende Anwendung. Beim Konzept der Serialisierbarkeit wird das Konzept der Isolation, als Vorteil der seriellen Ausführung, mit den Vorteilen des Mehrbenutzerprinzips, erhöhtem Datendurchsatz, kombiniert. Es entstehen Ausführungspläne von kontrollierten, nebenläufigen und verzahnten Transaktionen. Dabei ist immer abzuwägen, wieviele Transaktionen parallel ablaufen können und dass dennoch die Konsistenz der Daten gesichert ist. Dabei spielt die Synchronisation eine wichtige Rolle, welche eigentlich durch das Datenbankmanagementsystem übernommen wird. Sollte sie allerdings explizit definiert werden, sind folgende Regeln zu beachten: Der Sperrmodus sollte abhängig von der Operation - Lesen oder Schreiben - gewählt werden. Bei Aufeinanderfolgen von Leseund Schreiboperationen auf dasselbe Objekt sollte in den meisten Fällen gleich eine Schreibsperre angefordert werden, um Verklemmungen zu vermeiden. Es sollten nur die tatsächlich für die Transaktion benötigten Datensätze, Tabellen oder Seiten gesperrt werden - bei einer Vielzahl kleiner Datensätze kann es allerdings auch effizienter sein, die komplette Tabelle zu sperren, da so ein unnötig hoher Synchronisationsaufwand vermieden werden kann. KAPITEL 3. PHASE 1.2: ANWENDUNGSOPTIMIERUNG 7 Allgemein sollten Transaktionen durch eine Transaktionsanalyse erfasst werden. Davon ausgehend sollten Transaktionen möglichst kurz sein, damit Ressourcen nicht zu lange von einer einzigen Transaktion blockert werden. 3.4 Formulierung von SQL-Anweisungen Ziel der Anfrageoptimierung sind eine möglichst schnelle Anfragebearbeitung sowie eine möglichst geringe Anzahl von Seitenzugriffen. Zwar wird diese Aufgabe zumeist vom Optimierer übernommen, kann aber auch direkt beeinflußt werden. Dabei sind folgende Ziele zu beachten: Selektionen sollten so früh wie möglich erfolgen, um Zwischenergebnisse klein zu halten. Basisoperationen, die wie Selektion und Projektion zusammengefasst werden können, sollten ohne Zwischenspeicherung von Zwischenergebnissen als ein Berechnungsschritt realisiert werden. Es sollten nur Berechnungen ausgeführt werden, die auch einen Beitrag zum Gesamtergebnis liefern. Redundante Operationen, Idempotenzen (z.B. die Vereinigung einer Relation mit sich selbst) oder nachweisbar leere Zwischenrelationen können aus Berechnungsplänen entfernt werden. Das Zusammenfassen gleicher Teilausdrücke ermöglicht die Wiederverwendung von Zwischenergebnissen. Zu beachten ist, dass Zwischenergebnisse nicht indexiert werden können. Verbundoperationen sind bei der Nutzung derselben Datensätze - allerdings ohne Operationen wie AVG, MIN, MAX - Unteranfragen vorzuziehen. Bei Unteranfragen sollten die Anfragen mit der höchsten Selektivität die inneren Anfragen darstellen, da diese zwischengespeichert werden müssen, und die Schachtelungstiefe sollte möglichst gering gehalten werden. Um kostspielige Sortieroperationen zu vermeiden, sollte die ORDER BY-Funktion nicht bei bereits in der gewünschten Reihenfolge gespeicherten Daten verwendet werden. Die Funktionen DISTINCT und UNION sollten vermieden werden, wenn doppelte Datensätze bereits ausgeschlossen werden können. In der Regel wird die Optimierung in die drei Phasen logische Optimierung, interne Optimierung und kostenbasierte Optimierung unterteilt - worauf in dieser Arbeit nicht expliziter eingegangen werden soll - zumeist findet jedoch eine Kombination der drei Modelle statt, so dass der beste Ausführungsplan basierend auf Heuristiken und statistischen Informationen erstellt wird. 4 Phase 2: Hauptspeicheroptimierung 4.1 Ziel Der Hauptspeicher in Datenbannkmanagementsystemen dient der Zwischenspeicherung von Daten. Diese sind vom Hauptspeicher mit Zugriffszeiten im Nanosekundenbereich schneller abrufbar als vom Sekundärspeicher, bei dem sich Zugriffszeiten im Millisekundenbereich bewegen. Natürlich können nicht alle Daten im Hauptspeicher liegen, da dieser zumeist eine Kapazität von lediglich 32 MB bis 1 GB aufweist, im Gegensatz zum Sekundärspeicher mit Kapazitäten von 1 GB bis mehrere Terrabyte. Ziel der Hauptspeicheroptimierung ist die Minimierung der Anzahl unnützer physischer Zugriffe auf den Sekundärspeicher durch eine Optimierung des Hauptspeichers bezüglich der Verteilung der Ressourcen auf die einzelnen Komponenten des Datenbankpuffers. Dazu zählen der Datenpuffer, der SQL-/Prozedurpuffer und der Protokollpuffer. Diese sollten eine bestimmte Menge der Daten beinhalten. Eine einfache Vergrößerung des Hauptspeichers bringt nur bedingt Performancesteigerungen, da mit größerer Kapazität und größerer Datenmenge wiederum ein erhöhter Verwaltungsaufwand eintritt. 4.2 Optimierung des Datenbankpuffers Wie bereits erwähnt, brint eine bloße Vergrößerung des Hauptspeichers nicht automatisch eine Leistungssteigerung. Vielmehr ist es sinnvoll, die Daten des Datenbankpuffers bezügliche der Semantik der Datenstrukturen aufzuteilen und auf semantisch verschiedene Puffer aufzuteilen. Den verschiedenen Aufgabenbereichen der Datenbank werden somit optimale Pufferanteile zugewiesen. Dabei sind folgende Komponenten des Datenbankpuffers sowie deren optimaler Füllgrad zu beachten: Im Datenpuffer werden die Daten (Tabellen und Indexe) gehalten, auf die zugegriffen wird. Es sollten möglichst soviele Daten enthalten sein, dass die Mehrzahl der Anfragen bereits mit dem Zugriff auf den Datenpuffer beantwortet werden können. Es wird eine Trefferrate von 80-90% empfohlen. Das heißt, dass 80-90% der für die Anfragen benötigten Daten im Datenpuffer enthalten sind. 8 KAPITEL 4. PHASE 2: HAUPTSPEICHEROPTIMIERUNG 9 Der SQL-/Prozedurpuffer enthält die SQL-Anweisungen und Prozeduren, die bereits durch das Datenbankmanagementsystem übersetzt und optimiert wurden. Daher sollten auch SQL-Anweisungen in einheitlicher Form formuliert werden, damit Ausführungspläne wiederverwendet werden können und nicht ineffizient neu berechnet werden müssen. Für die im SQL-/Prozedurpuffer enthaltenen Anweisungen und Prozeduren wird eine Trefferrate von bis zu 99% empfohlen. Somit sollten für eine optimale Nutzung der Datenbank eigentlich alle Anweisungen darin enthalten sein. Im Protokollpuffer werden die Transaktionen protokolliert, genauer die Log-Einträge, die bei Transaktionsende in die Protokolldatei geschrieben werden, zwischengespeichert. Die Größe des Protokollpuffers ist relativ zur durchschnittlichen Änderungswahrscheinlichkeit der Daten sowie der Häufigkeit des Schreibens des Protokollpufferinhalts in die Protokolldatei zu wählen. Es wird empfohlen, die Wartezeit gegen 0 laufen zu lassen bzw. Fehlversuche beim Schreiben der Protokolldatei unter 5% zu halten. Ausgehend von den eben vorgestellten optimalen Größen der einzelnen Datenbankpufferelemente, ist die optimale Größe des gesamten Datenbankpuffers zu ermitteln. Basierend auf einer optimalen Größe in Relation zur Gesamtgröße des Haupspeichers sowie der optimalen Größe der einzelnen Elemente wird der Speicher zugeteilt, wobei der SQL-/Prozedurpuffer und der Protokollpuffer höhere Priorität besitzen, da es zu Wartezeiten und Performanceeinbußen kommen kann, wenn Transaktionen bei gefülltem Protokollpuffer ihre Änderungen nicht protokollieren können bzw. Ausführungspläne aufwendig berechnet werden müssen, sofern sie nicht im Puffer enthalten sind. 4.3 Optimierer Der Optimierer eines Datenbankmanagementsystems berechnet die Ausführungspläne, die geeignetste Strategie für den Datenzugriff bei Datenbankanfragen, wobei er kostengünstige Operationen nach vorne zieht und kostspielige Operationen anhängt. Der Optimierung liegen die zwei Varianten regelbasierte und kostenbasierte Optimierung zugrunde. Die regelbasierte Optimierung bezieht sich auf das Erkennen kostengünstiger, primär auszuführender Operationen anhand der Syntax. Die kostenbasierte Optimierung dagegen umfasst das Erkennen tatsächlich kostengünstigster Operationen anhand von Statistiken. Dabei ist natürlich vorausgesetzt, dass das System über aktuelle statistische Angaben bezüglich der Anzahl der Datensätze und der Selektivität der Attribute verfügt, welche optimalerweise bei zuvoriger niedriger Datenbanklast berechnet wurden. Die Vorgehensweise des Optimierers kann durch Planhinweise beeinflußt werden, welche die KAPITEL 4. PHASE 2: HAUPTSPEICHEROPTIMIERUNG 10 Wahl des Optimierers, die Nutzung bzw. das Übergehen von Indexen, die Festlegung der Reihenfolge von Verbundoperationen sowie die Ausführung von Verbundoperationen betreffen. Im folgenden sind die Einflußmöglichkeiten am Beispiel von Oracle und DB2 dargestellt. Der DB2-Optimierer kann durch Angabe einer der folgenden Optimierungsklassen beeinflußt werden: • Klasse 0 führt eine minimale Optimierung durch, die bei einfachen, interaktiven Anfragen genutzt werden sollte • Klasse 1 führt keine Auswertung von Attributwertverteilungen zur Selektivitätsabschätzung durch • Klasse 2 nutzt Informationen über Attributwertverteilungen • Klasse 3 nutzt dynamische Programmierung zur Planauswahl • Klasse 5 ist der Defaultwert, für interaktive Anfragen werden Heuristiken zur Einschränkung des Suchraumes verwendet • Klasse 7 wie Klasse 5, ohne Einschränkung des Suchraumes • Klasse 9 nutzt alle Optimierungstechniken, die DB2 zur Verfügung stehen In Oracle stehen die zwei Varianten regelbasierte Optimierung und kostenbasierte Optimierung zur Verfügung. Der Optimierer kann auf drei Arten beeinflußt werden: durch Angaben in der Initialisierungsdatei init.ora, durch Setzen von Parametern für einzelne Sitzungen mittels ALTER SESSION und durch Hints für Einzelanfragen. Die folgenden Modi können eingestellt werden: choose: Das System übernimmt die Auswahl zwischen regelbasierter und kostenbasierter Optimierung. Bei Vorliegen statistischer Angaben wird auf die kostenbasierte Optimierung zurückgegriffen. all rows: Optimiert wird bezüglich der Zeit der Bereitstellung des Gesamtergebnisses. first rows: Optimiert wird bezüglich der Zeit der Bereitstellung der ersten Tupel des Gesamtergebnisses. rule: Optimiert wird ausschließlich über regelbasierte Optimierung. KAPITEL 4. PHASE 2: HAUPTSPEICHEROPTIMIERUNG 11 Hints, dir nur bei der kostenbasierten Optimierung erkannt werden, beeinflussen den gewählten Optimierungsmodus, die Auswahl konkreter Algorithmen, die Auswahl von Indexen, die Reihenfolge der Berechnung und weitergehende Optimierungsparameter wie beispielsweise den Parallelisierungsgrad von Anfragen. 5 Phase 3: Eingabe-/Ausgabeoptimierung 5.1 Ziel Die Eingabe-/Ausgabeoptimierung bzw. Optimierung der Sekundärspeicherzugriffe soll die verbleibenden Zugriffe auf den Sekundärspeicher optimieren. Dies wird durch gezielte Beeinflussung der physischen Struktur des Speichers erwirkt, durch Verteilung der Eingabe/Ausgabelast auf verschiedene Festplatten sowie durch Umgehung gewisser Funktionen des Betriebssystems. 5.2 Betriebssystemfunktionen Für die Steigerung der Performance eines Datenbankmanagementsystems kann es sinnvoll sein, gewisse Betriebssystemfunktionen zu umgehen. Beim durch das Betriebssystem gesteuerten Schreiben von Daten durchlaufen die Daten den Datenbankpuffer, den Hauptspeicherpuffer und den Dateisystempuffer bevor sie in die Dateien der Datenbank geschrieben werden. Für das Schreiben großer Datenmengen bedeutet dies einen hohen Rechenaufwand. Durch den Einsatz eines Raw Devices 1 können diese Zwischenstationen umgangen werden, ein direkter Zugriff auf die Festplatte wird ermöglicht. Dem gegenüber steht allerdings ein dadurch bedingter erhöhter Administrationsaufwand bei der erforderlichen Datensicherung. 5.3 Lastverteilung Im Zuge der Sekundärspeicheroptimierung sollte eine geschickte Lastverteilung vorgenommen werden. Dazu werden beispielsweise die Blöcke auf unterschiedliche Datenträger verteilt, wodurch ein paralleler Zugriff auf die Daten ermöglicht wird. Ebenso ist eine Trennung von Tabellendaten und den zugehörigen Indexdateien sinnvoll. Dies macht sich 1 Ein Raw Device bzw. Raw Partition ist eine zeichenorientierte Gerätedatei, die den direkten Zugriff auf eine Festplattenpartition erlaubt. Das Raw Device abstrahiert die Daten nicht über ein Dateisystem. Beim Zugriff auf das Device wird die Datenträgerverwaltung des Betriebssystems weitgehend umgangen. 12 KAPITEL 5. PHASE 3: EINGABE-/AUSGABEOPTIMIERUNG 13 besonders bei Vorgängen wie Neuindexierung, Reindexierung sowie dem Schreiben von Datensätzen positiv bemerkbar. Ebenso wird dadurch der seriell ablaufende Datenimport optimiert, wenn die Daten nicht zwischendurch im Datenbankpuffer abgelegt werden können. Weiterhin sollte eine Partitionierung vorgenommen werden. Diese betrifft vor allem an Verbundoperationen beteiligte Daten, die auf verschiedene Datenträger abgelegt werden. Dadurch werden Selektionen parallelisierbar gemacht. Bei der Verwaltung großer Datenmengen empfiehlt sich eine horizontale Partionierung der Daten auf verschiedene Festplatten. Weiterhin sollten auch Datendateien und Protokolldateien auf verschiedenen Festplatten abgelegt werden. Abgesehen von der Verteilung der Daten und Verwaltungsdateien wird bezügliche der Hardware der Einsatz eines RAID-Verbundes empfohlen. Besonders die Kombination aus RAID 0, welches das Striping ermöglicht, sowie RAID 1, wodurch eine Spiegelung der Daten erreicht wird. Diese dient der Sicherung der Daten. 5.4 Optimierung der physischen Speicherstrukturen Bei Festlegung der Blockgröße, welche gleichfalls die Größe der Seite betrifft, sind folgende Aspekte relevant für eine effiziente Nutzung des Datenbankpuffers: Es sollte ein möglichst geringer Anteil an Verwaltungsinformationen enthalten sein, es sollten lediglich gewünschte Daten enthalten sein, es sollte möglichst wenig freier Platz bei Lesezugriffen und möglichst viel freier Platz bei Schreibzugriffen vorhanden sein. Da diese Aspekte jedoch nicht einfach umsetzbar sind, sollten besonders die Anforderungen der Anwendung berücksichtigt werden, da diese Aufschluß über die häufigsten Operationen geben können. Allgemein spricht für die Verwendung kleiner Blöcke, dass dadurch weniger Bedarf an Datenbankpufferplatz besteht und die Wahrscheinlichkeit nicht benötigter Daten sowie die Konfliktwahrscheinlichkeit minimiert werden. Nachteilig ist allerdings, dass Verwaltungsinformationen in einem schlechten Verhältnis zu den Nutzdaten stehen. Große Blöcke sind optimal bei Tabellen mit großen Datensätzen verbunden mit einer Minimierung der Anzahl der Blöcke. Weiterhin sind große Blöcke bei sortierten und geclusterten Datensätzen zu bevorzugen. Einen Nachteil stellt dabei jedoch die größere Höhe der Indexbäume dar. Clustertechniken ermöglichen einen effizienten und schnelleren Zugriff auf zusammenhängende Datensätze. Jedoch werden Anweisungen ohne Cluster Key langsam abgefertigt und es ist zu beachten, dass die Blockgröße ausreichend groß für Einfügeoperationen gewählt wird. KAPITEL 5. PHASE 3: EINGABE-/AUSGABEOPTIMIERUNG 14 Für eine Laufzeitverbesserung ist zuweilen eine Reorganisation der Speicherstrukturen unumgänglich. Dabei werden Datensätze, die durch den laufenden Betrieb über mehrere Blöcke verteilt wurden, wieder vereint. Auch Tabellen, die über mehrere Blöcke verteilt sind, werden defragementiert und wieder zusammengefügt. Ebenso wird mit Clustern verfahren. Diese Reorganisation, wie auch das Löschen von Datensätzen, zieht eine Neuberechnung der Indexe nach sich, so dass diese wieder schmalere Binärbäume darstellen. 6 Zusammenfassung Die Optimierung von Datenbanken umfasst 4 Phasen: die Optimierung des Datenbankschemas und der Anwendung, die Hauptspeicheroptimierung, die Eingabe-/Ausgabeoptimierung und die Konfliktoptimierung. Diese 4 Phasen berücksichtigen die theoretische Formierung der Datenbank ebenso wie die Anwendung an sich, die physichen Strukturen des Datenbankmanagementsystems sowie die SQL-Syntax. Ziel der Optimierung ist eine allgemeine Performancesteigerung des Datenbankmanagementsystems, welche sich durch eine Laufzeitverbesserung verbunden mit erhöhtem Datendurchsatz auszeichnet. Damit wird auch der Kauf zusätzlicher Hardware unterbunden und eine mittel- bis langfristig günstigere Wartung erreicht. Innerhalb der einzelnen Phasen der Optimierung wird die Anzahl der für die Anwendung der Datenbank benötigten Zugriffe auf die Datenbank minimiert sowie die verbleibenden Zugriffe in der Formulierung ihrer Anfragen optimiert. Dies erfolgt bereits in der ersten Phase, bei der Erstellung des Datenbankschemas, wobei auf allen drei Ebenen der DreiSchema-Architektur Möglichkeiten für die Optimierung des Datenbankschemas bestehen. Ebenso erfolgt eine tatsächliche Optimierung der Anwendung sowie eine Optimierung der Formulierung der SQL-Anweisungen. In Phase 2, der Hauptspeicheroptimierung, werden die unnützen physischen Zugriffe auf den Sekundärspeicher minimiert. Dies erfolgt durch eine Optimierung des Hauptspeichers bezüglich der Verteilung der Ressourcen auf die einzelnen Komponenten des Datenbankpuffers. Die Einhaltung optimaler Trefferraten für Datenpuffer, SQL-/Prozedurpuffer und Protokollpuffer erhöhen die Effizenz des Datenbankmanagementsystems. Nach der Minimierung der Sekundärspeicherzugriffe werden die verbleibenden Zugriffe in Phase 3, der Eingabe-/Ausgabeoptimierung, optimiert. Dies wird durch gezielte Beeinflussung der physischen Struktur des Speichers erwirkt, durch Verteilung der Eingabe/Ausgabelast auf verschiedene Festplatten sowie durch Umgehung gewisser Funktionen des Betriebssystems. In Phase 4, der Konfliktoptimierung, werden system- und anwendungsabhängig, verbleibende Zugriffskonflikte gelöst. 15 7 Quellenverzeichnis Kempler, A. und A. Eickler: Datenbanksysteme, 6. Auflage - München: Oldenbourg Wissenschaftsverlag GmbH, 2006. ISBN 978-3-486-57690-0 Kudraß, Thomas (Hrsg.): Taschenbuch Datenbanken - Leipzig: Carl Hanser Verlag, 2007. ISBN 978-3-446-40944-6 Saake, Gunter: Datenbanken: Implementierungstechniken / Gunter Saake; Andreas Heuer - Bonn: MITP-Verlag GmbH, 1999. ISBN 3-8266-0513-6 16
