Statistiken in DB2 UDB - Friedrich-Schiller

Friedrich – Schiller – Universität Jena
Lehrstuhl für Datenbanken und Informationssysteme
Institut für Informatik
Prof. Dr. Klaus Küspert
Aspekte und Werkzeuge der
Datenbankadministration und deren
Automatisierung
–
„Automated Statistics Collection“
Seminar Siegmundsburg im Sommersemester 2006
Betreuer: David Wiese
Robert Fleischer
Stauffenberg Straße 2a/112, 07747 Jena
Tel.: 03641 / 234803
E-Mail: [email protected]
Inhaltsverzeichnis
1. Autonomic Computing und dessen Motivation ............................................... 3
2. Statistiken in DB2 UDB .................................................................................. 4
2.1 Das Runstats Tool .................................................................................... 4
2.2 Beispiel für fehlerhafte Statistiken ............................................................. 5
3. Die „Automated Statistics Collection“ Architektur ........................................... 6
3.1 Der UDI Prozess im Detail ........................................................................ 8
3.2 Der QF Prozess im Detail ......................................................................... 9
3.3 Der Scheduler ......................................................................................... 12
3.3.1 Datenfluss zum Scheduler ............................................................... 12
3.3.2 Regeln zur Prioritätslisten Erstellung................................................ 13
3.3.3 Der Scheduling Algorithmus ............................................................. 14
4. Performance Messungen mit und ohne ASC ............................................... 15
5. Zusammenfassung ....................................................................................... 17
Literaturverzeichnis .......................................................................................... 19
Abbildungsverzeichnis ...................................................................................... 20
Tabellenverzeichnis .......................................................................................... 21
2
1. Autonomic Computing und dessen Motivation
In einem im Jahr 2001 von IBM veröffentlichten Dokument [4] wurde
herausgestellt das eines der größten Hindernisse für die IT - Industrie in naher
Zukunft eine als „Complexity Crisis“ oder Komplexitätskrise beschriebenes
Problem sei. Die Basis für diese Erkenntnis stellte die Tatsache dar das heutige
Softwaresysteme nicht länger durch die Entwicklungsmöglichkeiten, diese sind
durch
Weiterentwicklungen
von
Designmöglichkeiten
Programmiersprachen nicht mehr das primäre Problem,
und
der Programmierer
begrenzt sind, sondern vielmehr durch ihre eigene Komplexität. Es gilt eine
Vielzahl heterogener Softwareprodukte zu Unternehmensweiten Anwendungen
zu verschmelzen und darüber hinaus so zu gestalten das Dienste über das
Internet angeboten werden können. Das Administrieren und Konfigurieren
dieser komplexen Systeme wird in Zukunft die menschlichen Kapazitäten und
Möglichkeiten überschreiten. Hier setzt die Idee des „Autonomic Computing“ an.
Die Idee ist denkbar einfach, Systeme die sich anhand grober Richtlinien selbst
managen und konfigurieren. Hier bietet sich der Vergleich mit dem autonomen
Nervensystem des menschlichen Körpers an, was zum Beispiel die
Körpertemperatur konstant auf 37 Grad Celsius hält. Diese Idee wird auch als
Self-Management bezeichnet und gliedert sich in vier Teilkonzepte. Das Erste
stellt das Self-Configuration dar. Bisher ist das installieren, konfigurieren und
integrieren
verschiedener
Systeme
in
einem
Unternehmen
ein
sehr
zeitaufwändiges Unterfangen. Das installieren komplexer Ecommerce- oder
ERP-Systeme zum Beispiel, vor allem da diese meist von verschiedensten
Anbieter stammen, in Systemumgebungen großer Ebusiness-Unternehmen
kann ganze Teams von Programmierern Monate beschäftigen. Mit SelfConfiguration soll festgelegt werden was zu geschehen hat und in welchen
Grenzen, jedoch ohne wie bei herkömmlichen Systemen exakt festzulegen wie
es zu geschehen hat.
Ein weiterer Bereich wird durch das Self-Optimization Konzept abgedeckt.
Hierbei geht es primär darum Administratoren dahingehend zu entlasten, das
es nicht mehr von Nöten sein soll eine nahezu unüberschaubare Anzahl an
Performance beeinflussenden Parametern manuell zu überblicken und justieren
3
zu müssen. Dies gestaltet sich vor allem deswegen schwierig, da Änderungen
an Subsystemen komplexer Systeme ungeahnte Rückwirkungen auf andere
Subsysteme haben können. Der Hauptteil dieser Arbeit, die Automatische
Statistiksammlung oder „Automatic Statistics Collection“, fällt in diesen Bereich
des Self-Management.
Das
dritte
Teilkonzept,
Self-Healing,
soll
das
aufwändige
erkenne,
diagnostizieren und beheben von Fehlern weitestgehend automatisieren. Im
konkreten Fall von DB2 geschieht dies mit Hilfe des Health Monitors und des
Health Centers, welche Zustände verschiedener Datenbankobjekte aufzeichnen
und anschließend analysieren um daraufhin vom Administrator festgelegte
Aktionen auszuführen. Diese reichen von einfachen Log – Einträgen bis hin zu
direkten Manipulationen am entsprechenden Datenbankobjekt.
Das vierte und letzte Teilkonzept bildet das Self-Protection. Dieser Bereich
widmet sich dem entdecken und verhindern von Angriffe auf das System
sowohl von außen als auch aus dem Inneren des Systems heraus.
Diese Arbeit wird sich im Folgenden wie Bereits erwähnt mit dem Bereich des
Self-Optimization befassen und im speziellen mit Statistiken in DB2.
2. Statistiken in DB2 UDB
2.1 Das Runstats Tool
DB2 speichert Statistiken zu einzelnen Tabellen im Systemkatalog (SYSTAT
Schema) in verschiedenen Statistiktabellen. Einen Überblick über einen Teil der
im Katalog zu Statistiksammlung verwendeten Tabellen ist in Tabelle 1 zu
sehen. In diesem Katalog werden Statistiken zu Tabellen bezüglich allgemeiner
Eigenschaften, detaillierter Informationen zu einzelnen Spalten und Indizes, die
für Tabellen existieren, abgelegt. Der DB2 Optimizer nutzt diese Informationen
um einen optimalen Anfrageplan zu erstellen bzw. auszuwählen. Existieren für
eine Tabelle keine Statistiken oder keine aktuellen ist es möglich, dass der
Optimizer
einen
falschen
Anfrageplan
auswählt
und
somit
die
Ausführungsperformance einer Anfrage negativ beeinflusst wird.
Tabellenname Inhalt
4
Für
das
sammeln
der Tables
Statistiken ist das Runstats-Tool Columns
zuständig. Dabei handelt es
sich
um ein Tool, welches Indexes
Statistiken neu anlegen aber
Coldinst
auch veraltete Statistiken im
Systemkatalog
aktualisieren Colgroups
Anzahlt Spalten einer Tabelle
Anzahl eingetragener Werter
einer Spalte
Anzahl existierender Index
Schlüssel
Quantile und häufig verwendete
Werte einer Spalte
Gruppen eingetragener Werte für
eine Spaltengruppe
kann. Die Ausführung findet
tabellenspezifisch statt, d.h.
das
Runstats
auf
jede
Tabelle 1, Auszug verwendeter Tabellen
[1]
gewünschte Tabelle einzeln
ausgeführt werden muss. Vor der Ausführung kann durch Parameter festgelegt
werden welche einzelnen Spalten und Indizes in die Statistikerfassung
einbezogen werden sollen. Zusätzlich wird der Zeitpunkt der letzen Erfassung
im Systemkatalog festgehalten. Die genauen Parameter bezüglich zu
überprüfender Spaltengruppen, häufig aufgerufener Werte und Quantile etc.
werden in Runstatsprofilen abgelegt. Gespeichert werden diese in der Tabelle
SYSTAT.PROFILE.
2.2 Beispiel für fehlerhafte Statistiken
In Abbildung 1 sind drei
einfache
Anfragepläne
abgebildet.
resultieren
Sie
aus
einer
relationalen
Beispieldatenbank
Fahrzeugdaten.
sind
unter
mit
Hierin
anderem
Tabellen
über
Fahrzeughalter,
Abbildung 1, Beispiel für Schätzfehler [2]
Fahrzeugdaten
und
Unfälle enthalten. Jede einzelne Anfrage besteht aus einer Select-Anfrage auf
5
die nicht indizierte Tabelle Car mit mehreren Milliarden Tupeln, die genaue
Anfrage kann im unteren Bereich der Abbildung abgelesen werden, welche die
Zeilenanzahl liefern soll. Die ersten beiden enthalten jeweils ein einfaches
Prädikat („model“ bzw. „make“), die Dritte ein kombiniertes Prädikat („model“
und „make“). Im mittleren Bereich sieht man oben jeweils die vom DB2
Optimizer geschätzten Kardinalitäten und unten die tatsächlich aufgetretenen.
Im Falle der einfachen Prädikate stimmen aufgetretene und geschätzte
Kardinalitäten mit 101443 vs. 84496 bzw. 64353 vs. 55853 nahezu überein oder
sind zumindest in einem akzeptablen Verhältnis zueinander. Im dritten Fall mit
kombinierten Prädikaten fallen die Werte jedoch weit auseinander, 64353 vs.
3295,34. Dies kann damit begründet werden, dass der Optimizer aufgrund nicht
vorhandener oder aktueller Statistiken davon ausgeht das zwischen den
Prädikaten Unabhängigkeit vorliegt. Somit wird fälschlicherweise von einer
zusätzlichen Selektivität („model“ vs. „make“ und „model“) ausgegangen.
Jedoch liefert die Automarke zusätzlich zum Modell keinerlei Zusatzinformation
und somit keine höhere Selektivität, was ebenfalls anhand der identischen
aufgetretenen Kardinalitäten im zweiten und dritten Fall von 64353 abgelesen
werden kann.
Somit zeigt dieses Beispiel eindeutig das vorhandene bzw. aktuelle Statistiken
von Nöten sind und in Bezug zur Auswahl des Anfrageplans gesetzt einen nicht
unerheblichen Einfluss auf die Performance von DB2 haben können. Mit dieser
Tatsache befasst sich das im Folgenden behandelte „Automated Statistics
Collection“.
3. Die „Automated Statistics Collection“ Architektur
Die „Automated Statistics Collection“-Komponente (ASC-Komponente)
ist
bereits in DB2 UDB Version 8.2 integriert. Sie besteht aus zwei Prozessen,
dem UDI – Prozess und dem QF – Prozess, sowie aus ein Scheduler
Komponente.
Der UDI – Prozess befasst sich grundsätzlich mit dem
überwachen der Aktivität von Tabellen indem er UDI- (Update, Delete, Insert)
sowie
Load-Statements
aufzeichnet
und
empfiehlt
gegebenenfalls
die
Ausführung von Runstats wenn die Statistiken nicht mehr aktuell genug sind.
6
Der Zweite Prozess versucht anhand von Anfrageaktivitäten auf bestimmte
Tabellen deren Runstats-Profile möglichst optimal zu halten und wenn nötig
eine Runstats Ausführung zu empfehlen. Die Scheduler-Komponente stellt das
eigentlich „entscheidende“ Glied in der ASC Architektur dar, da sie die
Ergebnisse der beiden Eingangs erwähnten Prozesse kombiniert und
Abbildung 2, Die ASC Architektur [1]
letztendlich
die
Runstats
Ausführung
auf
einzelne
Tabellen
oder
Tabellengruppen anstößt. Diese Ausführungen finden jedoch grundsätzlich nur
in einem vorher vom Datenbankadministrator definierten Wartungsfenster oder
–intervall statt.
Einen Gesamtüberblick über die ASC Architektur liefert Abbildung 2. Im linken
Bereich der Abbildung sind Standardkomponenten und –schritte der DB2
Implementierung dargestellt. Darunter der Anfrageprozessor, der DMLProzessor, der DB2-Optimizer sowie die Anfrageplanausführung. Des Weiteren
sind verschiedene Monitoring-Komponenten integriert, welche neben der ASC
Architektur noch weitere den Autonomiegrad erhöhende Komponenten in DB2
unterstützen. Als Beispiel dafür wäre der learning- und der progressive
Optimzer von DB2 (LEO bzw. POP) zu nennen. Im oberen Bereich ist der UDIProzess zu sehen und die dazugehörigen Bestandteile, der Activity Monitor, der
UDI-Counter sowie der Activity Analyzer. Unten ist der zweite Prozess mit Planund Runtime-Monitor, Query-Feedback-Warehouse und Query Feedback
7
Analyzer zu erkennen. Abschließend sei noch der rechte Bereich erwähnt,
welcher mit dem Scheduler und den Analyzern aus beiden Prozessen eine
Erweiterung des Health-Centers darstellt um die automatische Statistik
Sammlung zu realisieren.
3.1 Der UDI Prozess im Detail
Dieser Prozess befasst sich wie bereits erwähnt mit Fragen der Datenaktivität.
In Abbildung 3 ist der Prozess im Detail abgebildet. Er besteht aus einer
Monitoring-Komponente, die sich aus dem Activity Monitor und dem UDI
Counter zusammensetzt und einer Analysekomponente, dem Activity Analyzer
der noch einmal in den Data Activity Checker (DAC) und den Change Analyzer
(CA) aufgeteilt werden kann.
Der Activity Monitor (AM)
bezieht seine Informationen
direkt vom DML-Prozessor,
der
bei
Anfragen
entsprechenden
nicht
Datenbestand
nur
den
manipuliert,
sondern auch Informationen
Abbildung 3, Der UDI Prozess [1]
an den AM schickt. Dieser
zeichnet mit Hilfe dieser Daten jeden Zugriff auf und speichert die Anzahl dieser
im UDI-Counter. Dieser wird mit jeder überwachten Tabelle abgelegt und bei
jedem um eins erhöht wenn eine existierende Spalte einer Tabelle verändert
bzw. gelöscht wird oder eine neue eingefügt wird. Der Counter wird auf null
zurückgesetzt wenn eine Tabelle neu angelegt wird oder Runstats ausgeführt
wurde.
Die Analyse der Tabellenstatistiken auf nicht aktuelle Statistiken beginnt mit
dem DAC, da Datenaktivität benötigt wird damit Statistiken an Aktualität
verlieren. Dies prüft der DAC auf zwei Arten. Zuerst wird geprüft ob die
Tabellendaten im Cache (Bufferpools) vorgehalten werden, ist dies nicht der
Fall, kann davon ausgegangen werden das eher wenig Datenaktivität vorliegt
und somit
keine Aktualisierung erforderlich ist, da DB2 häufig verwendete
8
Daten automatisch im Cache ablegt. Wurden die entsprechenden Daten
hingegen im Cache gefunden ist die Tabelle möglicherweise ein Kandidat zur
Statistikaktualisierung und es wird anhand des UDI-Counters geprüft ob ein
bestimmter prozentualer Schwellwert  überschritten wurde und daraus folgend
genügend
Datenaktivität
vorliegt.
Dieser
Wert
ist
gewöhnlich
auf
  10% eingestellt.
Vom DAC werden potentielle Tabellen an den CA weitergegeben. Dieser stellt
für
jede
Spalte
der
eingegebenen
Tabellen
zwei
statistische
Zusammenfassungen auf. Zum einen auf Basis einer Stichprobe aus der
Tabelle und zum anderen auf Basis der im Systemkatalog abgelegten und
möglicherweise falschen Statistiken. Aufgrund dieser Zusammenfassungen
werden für jede Spalte zwei Histogramme bezüglich der Datenaktivität erstellt.
Ist der Abstand zwischen den Histogrammen für jede Spalte einer Tabelle unter
einem bestimmten Grenzwert, werden die Statistiken für aktuell erklärt und nicht
zur Aktualisierung empfohlen. Wird dieser Grenzwert jedoch auch nur bei einer
Spalte überschritten, werden die Statistiken für nicht aktuell erklärt.
Diese Vorgänge sind gut anhand von Mengen zu erläutern. Es wird eine
Tabellenmenge G an den UDI-Prozess gegeben. Der DAC streicht anhand der
Kriterien „Ablage im Cache“ und  eine Menge X 1 aus dieser Menge heraus.
Der CA entfernt wiederum einige Tabellen anhand der Abstände zwischen den
Histogrammen aus der Menge, dies sei die Menge X 2 . Der UDI-Prozess liefert
also an den Scheduler am Ende eine mit Prioritäten versehene Menge
D  G  X1  X 2 .
3.2 Der QF Prozess im Detail
Der Query Feedback Prozess (Abbildung 4) hingegen wertet Informationen
bezüglich der Ausführung von Anfragen aus, das heißt es werden bereits
aufgetretene
Fehler,
konkret
Schätzfehler
des
Optimzers
bezüglich
Kardinalitäten, untersucht. Der Prozess besteht ähnlich dem UDI Prozess aus
einer Monitoring- und einer Analysekomponente. Die Monitoring-Komponente
besteht in diesem Fall jedoch aus zwei Monitoren, dem Plan-Monitor (PM) und
9
dem Runtime-Monitor (RM) und einem Query-Feedback-Warehouse (QFW).
Der PM zeichnet während dem kompilieren die Prädikate der betroffenen
Anfrage auf, zum Beispiel Spaltennamen, relationale Operatoren und Werte,
Abbildung 4, Der QF Prozess [1]
sowie die für jedes Prädikat durch den Optimizer geschätzten Kardinalitäten.
Der
RM
hingegen
zeichnet
die
bei
Anfrageplanausführung
wirklich
aufgetretenen Kardinalitäten für Prädikate und Tabellen auf. All diese Daten
werden im QFW zur weiteren Verwendung abgelegt.
Das QFW besitzt eine relationale Tabellenstruktur, die aus fünf
Tabellen
besteht, siehe Abbildung 5. Unterteilt wird das QFW in einen Feedback, drei
Tabellen, und einen Empfehlungsteil mit zwei Tabellen. An dieser Stelle wird
bereits sichtbar, das nicht nur aus einer Richtung Informationen in das QFW
geschrieben werden, sondern auch aus Richtung des Analyzers, welcher sein
Empfehlungen
bezüglich
Statistikaktualisierungen
darin
ablegt.
Der
Feedbackteil enthält eine Query_Tabelle, welche die einzelnen Anfragen und
dazugehörige Anfragepläne (in grober Form, „skeleton query plan“) enthält, eine
Predicate-Tabelle,
welche
von
Anfragen
verwendete
Prädikate
bzw.
Prädikatgruppen und statistische Informationen dazu enthält und eine ColumnTabelle die zu den Prädikaten den Spaltenname, den verwendeten Operator
und den gesuchten Wert enthalten. Der Empfehlungsteil enthält in der
jeweiligen Tabelle Empfehlungen zu Spalten und Spaltengruppen bezüglich
abgelaufener Statistiken, häufig aufgerufenen Werten und Korrelationen
10
zwischen einzelnen Spalten. Diese Empfehlungen stammen vom QueryFeedback-Analyzer (QFA) auf den ich im Folgenden eingehen möchte.
Der QFA verarbeit jene Informationen die von PM und RM im QFW abgelegt
worden sind. Dabei befasst er sich
vor allem mit Fehlern in Optimizer
basierenden
Kardinalitätsschätzungen und liefert
dabei nicht nur eine mit Prioritäten
versehene
Tabellenliste
an
den
Abbildung 5, Das QFW [1]
Scheduler sondern aktualisiert im
Gegensatz zum UDI Prozess auch die im Kapitel 2.1
erläuterten Runstats
Profile. Der QFA kann dabei, wie im rechten Teil von Abbildung 4 zu erkennen,
nocheinmal in drei Bestandteile zerlegt werden. Diese sind der TableCardinality-Analyzer (TCA), der Simple-Predicate-Analyzer (SPA) sowie der
Correlation-Analyzer (COA). Vom TCA werden dabei die aktuellen mit den vom
Optimizer aufgrund der im Systemkatalog abgelegten Statistiken geschätzten
Kardinalitäten verglichen und der Schätzfehler ermittelt. Der SPA verwertet
geschätzte und aktuelle Kardinalitäten von einfachen Prädikaten um daraus die
Anzahl von häufig genutzten Werten abzuleiten. Als letztes Element des QFA
leitet der COA aus den gesammelten Kardinalitäten und Prädikaten
Korrelationen zwischen Spalten innerhalb einzelner Tabellen ab. All diese
Informationen werden abschließend dazu genutzt auf der einen Seite die
Runstats-Profile möglichst optimal zu halten und auf der anderen Seite wird auf
Basis der erstellten Daten wie schon beim UDI Prozess eine mit Prioritäten
versehene Liste an den Scheduler übergeben.
11
3.3 Der Scheduler
Der Scheduler stellt die Hauptkomponente in der ASC Architektur dar. ER
verarbeitet die Prioritätslisten von UDI- und QF-Prozess indem daraus eine
einzelne Lister erstellt wird (siehe Kapitel 3.3.2). Des Weiteren wird durch den
Scheduling-Algorithmus die eigentliche Runstats Ausführung initiiert (siehe
Kapitel 3.3.3).
3.3.1 Datenfluss zum Scheduler
An dieser Stelle soll noch einmal eine kurze Zusammenfassung über alle
Abläufe innerhalb der ASC-Architektur gegeben werden. Grundsätzlich finden
diese nur zwischen UDI- bzw. QF-Prozess und Scheduler statt. Der Scheduler
kann jeden Prozess einzeln aufrufen oder auch beide gleichzeitig. Bei einem
Aufruf des UDI-Prozesses ist es nötig dem Prozess bereits eine Tabellenmenge
zu übergeben, der Rückgabewert ergibt sich dann auf Basis dieser Menge,
jedoch reduziert um jene Tabellen welche die Kriterien der UDI-Komponenten
nich erfüllt haben.
Ein Aufruf des QF-Prozesses hingegen ist ohne übergabe einer Tabellenmenge
möglich. Der Prozess liefert in jedem Fall aufgrund der im QFW gesammelten
Daten eine Prioritätsliste zurück. Gleichzeitig werden nur vom QF-Prozess bei
Bedarf die Runstats-Profile aktualisiert. Bei einem Runstats Aufruf nutzt das
Tool automatisch diese Profile.
Aufgrund dieser Daten bildet der Scheduler eine Liste mit abzuarbeitenden
Tabellen. Dazu mehr in den beiden folgenden Kapiteln.
Abbildung 6, Beispiel für eine Prioritätsliste[1]
12
3.3.2 Regeln zur Prioritätslisten Erstellung
Das erstellen der vom Scheduling-Algorithmus genutzten mit Prioritäten
versehenen Tabellenmenge geschieht anhand festgelegter Vorgaben. Der
Scheduler teilt die Tabellen aus den beiden ASC Prozessen in fünf Klassen
ein, je nach Wichtigkeit (siehe Error! Reference source not found.). Diese
fünf Klassen sind im Einzelnen:

Useful: Zwischen  und 50 Prozent der Datensätze einer Tabelle
müssen verändert worden sein damit eine Tabelle in diese Klasse
eingeteilt wird. D.h. das die Einteilung aufgrund der Daten aus dem UDIProzess geschieht.

Needed: Um in diese Klasse eingeteilt zu werden ist es nötig das eine
Tabelle vom QF-Prozess empfohlen worden ist.

Pressing: Mehr als 50 Prozent der Datensätze in einer Tabelle müssen
verändert worden sein, das heißt es findet wiederum eine Einteilung
aufgrund von Daten des UDI-Prozesses statt.

Urgent: Diese Klasse ergibt sich aus der Needed Klasse und der Useful
oder Pressing Klasse. Dies bedeutet das eine Empfehlung des QFProzesses vorliegen muss und mehr als  Prozent der Datensätze der
entsprechenden Tabelle seit der letzten Statistikaktualisierung verändert
worden sind.

Critical: Diese Klasse nimmt eine Sonderstellung ein. Es werden
Tabellen dieser Klasse zugeordnet für die entweder noch nie Runstats
ausgeführt wurde oder die schon häufig aufgrund einer niedrigen
Kasseneinstufung zurückgestellt wurden.
Die nach diesen Regeln aufgestellte Prioritätsregel wird nun innerhalb der
Wartungsintervalle nach und nach abgearbeitet. Ein Überblick über den
Aufbau einer nach diesen Regeln erstellten Liste ist in Abbildung 6 gegeben.
Der zugrunde liegende Algorithmus wird im nächsten Kapitel erläutert.
13
3.3.3 Der Scheduling Algorithmus
Abschließend
zur
ASC
Architektur soll nun das
Kernelement
des
Schedulers
werden,
erläutert
der
Scheduling
Algorithmus,
welcher
regelt wann eine Runstats
Ausführung
stattfindet.
Abhängig
ist
Algorithmus
der
primär
von
zwei Dingen. Zum einen
von
der
vom
Datenbankadministrator
festgelegten
Menge
zu
überwachenender
Tabellen und zum anderen
vom
Zeitfenster,
dem
Wartungsintervall, in dem
der
Algorithmus
Abbildung 7, der Scheduling Algorithmus[1]
Runstats
ausführen
darf.
Auch
dieses
wird
vom
Datenbankadministrator festgelegt. Die Menge der zu überwachenden Tabellen
entspricht der Menge G in Abbildung 7 und kann alle Tabellen einer Datenbank
umfassen oder auch nur einen geringen Teil. Alle weiteren angegebenen
Mengen sind vor Beginn der ersten Ausführung leer. Den Rahmen für den
Algorithmus stecken zwei ineinander geschachtelte While-Schleifen ab. Die
Erste befasst sich mit dem Sammeln der benötigten Daten von den beiden
ASC, dies geschieht mit den Befehlen D:=AA(G) und Q:=QFA(), sowie mit dem
erstellen der endgültigen Prioritätsliste für das aktuelle Wartungsintervall. Die
Liste wird aus den drei Mengen D, Q und C gebildet. C entspricht dabei der
Menge der kritischen Tabellen bzw. der Klasse Critical. Gebildet wird die Liste
mit dem Befehl P:=prioritizeMerge(D,Q,C).
Die zweite Schleife ist für das ausführen von Runstats zuständig. Mit T:=Pop(P)
wird die Tabelle mit der höchsten Priorität in P ermittelt um danach auf diese
14
Tabelle Runstats auszuführen. Für jede abgehandelte Tabelle wird nach der
Ausführung die Datenänderungsrate geschätzt um festzulegen wann eine
erneute Runstats Ausführung einzuplanen ist. Diese Schleife läuft solange wie
es möglich ist im aktuellen Wartungsintervall noch eine Runstats Ausführung
durchzuführen.
Ist
dies
nicht
mehr
möglich
werden
mit
(G,C):=costructDueTables() der Mengen G und C für die nächste Iteration neu
erstellt. Ab diesem Zeitpunkt ist der Algorithmus bis zum nächsten Zeitfenster
inaktiv.
4. Performance Messungen mit und ohne ASC
Zum Abschluss dieser Arbeit soll anhand des bereits Eingangs verwendeten
Beispiels über Autostatistiken aufgezeigt werden inwiefern durch den Einsatz
von ASC Performancevorteile zu erwarten sind. Das Beispiel hat folgende
Eckdaten:

Untersucht wird eine Datenbank mit vier Tabellen (Car, Owner,
Demographics, Accident)

Es werden 11 Select-Anfragen nach verschieden Schitten (A-E, in den
Abbildungen zu erkennen) ausgeführt

Schritt C führt als einziger Schritt neue Datensätze ein

Anfrage 10 enthält abhängige Attribute der Tabellen Car und Owner
(Make, Model und City, Country3)
In den beiden folgenden Abbildungen wurden auf der X-Achse jeweils die
Anfragen abgetragen und auf der Y-Achse die dazugehörigen Antwortzeiten. In
Abbildung wurden die Schritte A und B ausgeführt und nach jedem Schritt der
Anfragenkomplex abgearbeitet. Schritt A beinhaltet nur das initiierende Laden
der Datenbank und Schritt B wurde nach verwenden von ASC ausgeführt, dem
jedoch nur der UDI-Prozess zur Verfügung stand. Wie zu sehen verkürzen sich
alle Antwortzeiten, wenn auch nur marginal, bis auf die der Anfrage 10. Deren
Antwortzeiten verlängern sich extrem, was auf das nicht beachten der
Abhängigkeit zwischen den Prädikaten zurückgeführt werden kann.
15
Abbildung 8, Schritte A und B [2]
In Abbildung werden nun drei weitere Schritte durchgeführt. Schritt C führt
lediglich neue Datensätze ein, was dazu führt das die Antwortzeiten dieser
Abbildung nicht mit denen der vorigen verglichen werden können. In Schritt D
Abbildung 9, Schritte C, D und E [2]
16
werden sämtliche Anfragen analog zu Schritt B ausgeführt, nachdem ASC
gestartet wurde, jedoch wieder mit der Einschränkung, dass nur der UDI
Prozess verwendet wurde. Es ist wiederum zu erkennen, dass die
Antwortzeiten der Anfrage 10 sich zwar in diesem Fall nicht verlängern, aber
sich auch nur minimal verbessern und weiterhin auf schlechtem Niveau bleiben.
Im abschließenden Schritt E werden von ASC beide Prozesse verwendet.
Dadurch verbessert sich die Antwortzeit von Anfrage 10 extrem bei
gleichzeitigem verbleiben aller anderen Zeiten auf gutem Niveau.
5. Zusammenfassung
Ziel der Einführung der „Automated Statistic Collection“ ist es, drei primäre Ziele
zu erreichen. Es soll sichergestellt werden das relevante Statistiken existieren,
das diese aktuelle sind und dies, ohne eine merkliche Zusatzbelastung des
Systems hervorzurufen. Das erste Ziel, das anlegen relevanter Statistiken wird
durch die beiden Prozesse der ASC
Architektur(UDI und QF) erreicht.
Dasselbe gilt für die Überwachung der Aktualität dieser. Das dritte und
wichtigste Ziel, da es sozusagen ein KO-Kriterium darstellt wird konnte
ebenfalls erreicht werden. Dies ist durch zwei Schritte möglich. Zum einen
verursachen
die
Monitoring-Komponenten
der
Prozesse,
die
einzigen
Bestandteile von ASC die permanent betrieben werden, nur eine zusätzliche
Systembelastung von 1-2 %, je nach Systemaustattung. Der eigentliche
Scheduling Algorithmus läuft nur während den vom Datenbankadministrator
vorgegebenen Wartungsintervallen.
Zum anderen wurde das Runstats Tool dahingehend verbessert, dass es nur
noch mit niedriger Priorität läuft und somit nur die Systemressourcen verwendet
die auch wirklich frei sind. Somit konnten die drei primären Ziele der
Entwicklung der ASC-Komponenten erfüllt werden. Zusätzlich dazu ist eine
teilweise recht deutliche Performancesteigerung messbar, was auf besser an
die
aktuellen
Anforderungen
an
das
DBMS
angepasste
Statistiken
zurückzuführen ist.
Ziele für zukünftige Weiterentwicklungen der Architektur sind eine automatische
Festlegung Wartungsintervalle um den Datenbankadministrator noch weiter zu
17
entlasten und eine allgemeine Verfeinerung der Statistiken, um Anfragepläne in
Zukunft noch näher am Optimum gestalten zu können ( ein möglicher Ansatz ist
in Quelle [3] zu finden).
18
Literaturverzeichnis
Aboulnaga, A; P. Haas, M. Kandil, S. Lightstone, G. Lohman, V. Markl, I.
Popivanov, V. Raman (2004): Automated Statistics Collection in DB2 UDB.
IBM Almaden Research Center / IBM Toronto Development Lab. [1]
Haas, P; M. Kandil, A. Lerner, V. Markl, I. Popivanov, V. Raman, D. Zilio
(2005): Automated Statistics Collection in Action. IBM Almaden Research
Center / IBM Toronto Development Lab. [2]
FIlyas, I;V. Markl, P. Haas, P. Brown, A. Aboulnaga (2004):
CORDS:Automatic Discovery of Correlations
and Soft Functional Dependencies. Purdue University / IBM Almaden
Research Center [3]
IBM(2001): Autonomic Computing: IBM’s Perspective on the State of
Information Technology.
http://www1.ibm.com/industries/government/doc/content/resource/
thought/278606109.html. [4]
Kephart, J. O. und D. M.Chess (2003): The Vision of Autonomic
Computing. IBM Thomas J. Watson Research Center. [5]
Lightstone, S. S.; G. Lohman, D. Zilio(2002):Toward Autonomic Computing
with DB2 Universal Database. IBM Canada. [6]
Markl, V.; V. Raman, D. Simmen, G. Lohman, H. Pirahesh, M. Cilimdzic (2004):
Robust Query Processing through Progressive Optimization. IBM Almaden
Research Center / IBM Silicon Valley Lab / IBM Toronto Lab. [7]
Raman V.; V. Markl, D. Simmen, G. Lohman, H. Pirahesh (2004): Progressive
Optimization in Action. IBM Almaden Research Center. [8]
19
Abbildungsverzeichnis
Abbildung 1:
Beispiel für Schätzfehler
S. 5
Abbildung 2:
Die ASC Architektur
S. 7
Abbildung 3:
Der UDI Prozess
S. 8
Abbildung 4:
Der QF Prozess
S. 10
Abbildung 5:
Das QFW
S. 11
Abbildung 6:
Beispiel für eine Prioritätsliste
S. 12
Abbildung 7:
Der Scheduling Algorithmus
S. 12
Abbildung 8:
Schritte A und B
S. 16
Abbildung 9:
Schritte C, D und E
S. 16
20
Tabellenverzeichnis
Tabelle 1:
Auszug verwendeter Tabellen
S. 5
21