UND ENTWICKLUNG Dipl.Inf. David Wiese

Verfasser :
Stefan Lenschow
Matrikelnummer :
53849
Studiengang : Informatik Diplom
[email protected]
Verfasser :
Qiguang Yan
Matrikelnummer :
51588
Studiengang : Informatik Diplom
[email protected]
Seminararbeit zum Thema
AKTUELLE THEMEN DER
DATENBANKFORSCHUNGUND ENTWICKLUNG
Wintersemester 2006/2007
S E L F-M A N A G E A B I L I T Y
IN
IBM DB2
vorgelegt bei
Dipl.Inf. David Wiese
Institut für Informatik
Lehrstuhl für Datenbanken und Informationssysteme
Fakultät für Mathematik und Informatik
FSU Jena
1
Abkürzungsverzeichnis
API
DBA
DBMS
GUI
OLTP
QEP
MGJN
MQT
NLJN
UDB
-
Application Programming Interface
Datenbankadministrator
Datenbankmanagementsystem
Grafisches User Interface
Online Transaction Processing
Query Execution Plan
Merge Join
Materialized Query Table
Nested Loop Join
Universal Database
2
Gliederung
Einleitung
.................
4
SELF – HEALING
.................
4
1.1
1.2
.................
.................
5
7
SELF – CONFIGURING
.................
9
2.1 Configuration Advisor
2.1.1 Architektur des Config. Advisors
2.1.2 Interfaces des Config. Advisors
2.1.3 Experiment
.................
.................
.................
.................
10
10
11
12
2.2 Design Advisor
2.2.1 Architektur des Design Advisors
2.2.2 Experiment
.................
.................
.................
13
14
17
SELF – OPTIMIZING
.................
17
3.1 Adaptive, Self-Tuning Memory
3.1.1 Self-Tuning Memory Manager
3.1.2 Beispiel
3.1.3 Experiment
.................
.................
.................
.................
17
19
19
20
3.2 Progressive OPtimization (POP)
3.2.1 Architektur von POP
3.2.2 Beispiel für eine Reoptimierung
.................
.................
.................
21
22
23
3.3 LEarning Optimizer (LEO)
3.3.1 Architektur von LEO
.................
.................
24
25
IV.
ZUSAMMENFASSUNG
.................
29
V.
QUELLEN
.................
30
I.
II.
III.
Health Monitor
Health Center
3
Einleitung
Mit der 2001 gestarteten Autonomic–Computing–Initiative [Horn+04]
wählte IBM eine eigene Einteilung (siehe Abbildung 1) der Selbstmanagement–Fähigkeiten in die Bereiche:
Selbstheilung (Self–Healing), Selbstkonfiguration (Self–Configuring),
Selbstoptimierung (Self–Optimizing) und Selbstschutz (Self–Protecting).
Da sich die englischen Schlagwörter auch in den deutschensprachigen
Versionen durchgesetzt haben, werden wir im Weiteren mit diesen arbeiten.
Seitdem bestreitet IBM das Autonomic Database Project, der Teil der Autonomic Computing Initiative, dessen Ziel es ist IBMs Vorzeigeprodukt
DB2 schrittweise mehr und mehr autonom zu machen.
Während die Bereiche Self-Healing, -Configuring, -Optimizing seit mehreren Versionen immer mehr erweitert und ausgebaut wurden, steckt der
Self–Protecting–Teil noch in den Kinderschuhen. Eigene Tools des DBMS
sind derzeit noch nicht implementiert, dieser Bereich wird daher zurzeit
nur über Betriebssysteme oder Drittanbietersoftware auf Betriebssystemebene berührt.
In der Gesamtbetrachtung liegt der Fokus der Initiative auf einer Entlastung der Anwender (insbesondere der Administratoren), welche mit steigender Komplexität der DBMS als auch mit immer größeren Datenbanken
zu kämpfen haben.
Gerade im Hinblick auf die Zahl der gut ausgebildeten DB–Administratoren
im Vergleich zum rasant wachsenden Gebrauch von DBMS in Unternehmen zeigt sich, dass zukünftige kommerzielle Datenbankprodukte ohne
weitreichende autonome Fähigkeiten zur Selbstüberwachung und Konfiguration deutliche Wettbewerbsnachteile haben dürften.
Ziel unserer Arbeit ist es die IBM DB2 auf ihre Selbstmanagement–
Fähigkeiten zu untersuchen und dabei die wichtigsten Tools aktueller Versionen vorzustellen.
I.
SELF – HEALING
Selbstheilung ist eines der wichtigsten Schlagworte von IBMs Autonomic-Computing-Initiative. Ziel dieser
Eigenschaft des Selbstmanagements
ist
Selbstüberwachung und –
reparatur des Datenbanksystems zur
Laufzeit um kritische Situationen
(z.B. Sort-Heap-Größe unterschätzt)
im täglichen Betrieb rechtzeitig zu
erkennen und adäquat zu reagieren.
4
Abbildung 1: Übersicht
„Self-Managing“Eigenschaften
Aus Quellen des DB2 Magazins [DB2MAG] erklärt sich die Notwendigkeit
dieser Entwicklung. Umfragen unter Datenbankexperten internationaler
Topunternehmungen zeigten einen 55%-igen Anteil von „Monitoring-„ und
„problem solving-“ Aufgaben an ihrem durchschnittlichen Tagespensum.
Da die Komplexität ebenso wie die Zahl der zu betreuenden DBMS stetig
steigt, ist es dringend nötig durch die Erhöhung des Autonomiegrades verschiedener Teilsysteme freie Ressourcen für den Administrator zu schaffen.
IBM führte hierzu in Version 8.1 ihres DBMS Produktes „IBM DB2 UDB“
erweiterte Self–Healing Features ein. Ziel war die Abkehr von der Überwachung des Systemzustandes durch den DBA hin zu einem selbstüberwachten System, welches die kompletten Monitoring-Funktionen autonom
durchführt und zusätzlich Problemlösungen anbietet.
Die zwei standardmäßig mitgelieferten Tools sind der Health Monitor und
sein grafisches Frontend, das Health Center.
1.1 Der Health Monitor
Der Health Monitor [DB2MAG] ist ein serverseitiges Tool, welches auf dem
„Managed-by-Exeption“–Modell beruht. Es läuft im Hintergrund und sammelt dabei in kurzen, definierbaren Abständen Informationen über den
aktuellen Systemzustand. Dazu wird der in DB2 schon länger verfügbare
Snapshot Monitor genutzt, was eine weitergehende Belastung der Systemperformance vermindert.
Vormals musste der Administrator in gewissen Abständen den Event- sowie den Snapshot Monitor bemühen, um deren Datenberge auf Inkonsistenzen und möglichen Fehlerquellen zu durchforsten. Solche Probleme
mögen vorzeitig erkannt werden, da sonst Einbußen der Systemperformance bis hin zum Ausfall ganzer Instanzen drohen.
Der Health Monitor erledigt dies selbständig, indem er so genannte
„Health Indicators“ einführt, die eine Aussage über den „Gesundheitszustand“ bestimmter Objekte erlauben.
Indikatoren gibt es für folgende Objekte:
•
•
•
•
•
•
•
•
•
•
•
DBMS (z.B. Arbeitszustand von Instanzen)
Datenbanken (z.B. Arbeitszustand der Datenbanken)
Database Maintenance (z.B. REORG nötig)
Logs
Tablespace-Speicherung (z.B. Table Space Utilization)
Sortierung (z.B. Prozentsatz von overflowed Sorts)
Package- und Catalog-Caches (z.B. Package Cache Hit Rate)
Workspaces
Speicher (z.B. Monitor Heap Utilization)
Konkurrenzgrad laufender Applikationen (z.B. Deadlock Rate)
High Availability Disaster Recovery (z.B. HADR log delay)
5
Den Objekten werden verschiedene Zustände zugewiesen, welche die Priorität ihrer Abarbeitung angeben sollen. Dies gilt für die Gefahrzustände,
welche durch einen steigenden Alarmlevel gekennzeichnet sind.
Neben dem Normalzustand, der die volle Funktionsfähigkeit des zugewiesenen Objektes anzeigt, gibt es in aufsteigender Reihenfolge die Zustände: warning , attention , alarm.
Die Indikatoren lassen sich folgenden Klassen zuordnen:
Die am häufigsten genutzte Klasse sind die:
Schwellwertbasierten Indikatoren (18), welche Statistiken über das Verhalten des Objektes überwachen. Für die verschiedenen Alarmlevels lassen sich unterschiedliche Schwellwerte konfigurieren, bei deren Übertreten
der jeweilige Alarm ausgelöst wird.
Es folgen die:
Zustandsbasierten Indikatoren (6), welche zwei oder mehr eindeutige Zustände des zugewiesenen Objekts überprüfen und damit eine Aussage über kritisch oder unkritisch liefern. Ein Beispiel für einen solchen Indikator
wäre ein Zustand der meldet, ob eine Instanz arbeitet oder eben ausgefallen ist.
Außerdem gibt es noch die:
Zustandsmengenbasierten Indikatoren (4), die Maßgrößen des Datenbanklevels sind, welche angesammelte Zustände ein oder mehrerer Objekte repräsentieren.
Der Health Monitor liefert noch weitere Funktionen neben dem Systemmonitoring. Er sammelt alle Alarminformationen und sendet sie an alle
vorkonfigurierten Kontakte per Email oder Pager. Auch das Ausführen voreingestellter Aktionen, wie ein selbständiges REORG eines Tables wird ermöglicht. Sollte ein Alarmlevel erreicht werden, zeigt der Health Monitor
dies an, indem er in alle laufenden grafischen Anwendungen des DBMS ein
blinkendes Warnzeichen in die untere Bildzeile einfügt. Ein Klick auf das
Zeichen genügt um sofort das Health Center zu starten.
Die Informationen des Health Monitors lassen sich über verschiedene Interfaces abrufen. Das übliche grafische Userinterface ist das bereits genannte Health Center (in der deutschen Version als Diagnosezentrale bezeichnet). Dieses erweitert die Informationen des Health Monitors um genauere Details zu den aufgetretenen Problemen und liefert sogar Lösungsstrategien.
In Form des Web Health Center gibt es eine Webanwendung für Standardbrowser, die eine Ferndiagnose samt Problemlösung erlaubt. Nötig ist nur,
sich mit den passenden Login-Daten auf der entsprechenden IBM-Seite
einzuwählen.
6
Daneben gibt es noch die Möglichkeit der Analyse und Intervention als
Kommandozeilenaufruf über den Command Line Prozessor, über SQLbasierten Funktionen oder über C-APIs.
Diese Interfaces dienen auch der Konfiguration der Health-Indikatoren
und Kontakte. So können für Schwellwertbasierte Indikatoren die „warning-“ und „alarm-“ Levels (untere und obere Grenze) eingestellt werden.
Neu in Version 8.2 ist der Parameter der Sensitivität, d.h. es wird festgelegt, wie lange ein Wert in einem „alarmierenden“ Zustand sein darf, bevor einer der Alarmzustände ausgelöst wird. Damit können kurzzeitige
Überschreitungen zugelassen werden, ohne einen Alarm zu provozieren.
Außerdem kann für jeden Indikator eines Objektaspektes ausgewählt werden, ob er ignoriert werden soll oder nicht.
Sämtliche aktuelle als auch vergangene Alarminformationen lassen sich in
den grafischen Interfaces nochmals betrachten.
1.2 Das Health Center
Seit Version 8.1 ist das Health Center (Abb.2) Teil der DB2 UDB. Es besteht aus zwei Fenstern, dem Objektfenster auf der linken Seite und dem
Inhaltsfenster auf der rechten. Das Objektfenster zeigt Objekte, sowie mit
kleinen Symbole den aktuellen Indikatorzustand direkt mit an. Ein grüner
Diamant steht für den Zustand „normal“, ein gelbes Dreieck für „warning“,
ein oranger Kreis für „attention“ und ein roter Kreis für „alarm“. Die Objekte lassen sich nach den vier Symbolen je nach Wunsch anordnen, wozu
die vierfach – Schaltfläche über dem Objektfenster dient. Somit lässt sich
von „nur Alarme“ bis „alle Alarmlevels“ schrittweise alles ein- bzw. ausblenden.
Abbildung 2 : Der Health Center
7
Das Inhaltsfenster liefert zu einem im Objektfenster ausgewählten Objekt
ergänzende Informationen, wie den betroffenen Indikator, die Kategorie,
den aktuellen Wert und Objekttyp, sowie den Zeitpunkt des Auftretens des
Problems.
Seit Version 8.2 wurde das Health Center um den so genannten „Recommendation Advisor“ erweitert. Dieser soll dem Administrator unter die Arme greifen, um die richtigen Einstellungen für bestimmte Aktionen (wie
z.B. die Vergrößerung des Sort-Heaps) zu treffen, damit aufgetretene
Probleme zukünftig vermieden werden.
Dazu stellt er dem DBA eine Reihe von Fragen und fasst diese Information
mit gewonnenen Daten über den aktuellen Systemzustand zusammen.
Basierend auf den Ergebnissen liefert der Recommendation Advisor verschiedene Lösungswege. Er ist in der Lage automatisch Scripts zu generieren bzw. benötigte Tools selbständig zu starten. Zum Beispiel startet er
den Memory Visualizer, wenn er um knapper werdende Speicherressourcen konkurrierende Anwendungen des DBMS erkennt. In den vorherigen
Versionen waren die empfohlenen Änderungen nicht gewichtet, so dass
keine Aussage getroffen wurde, welche der Änderungen denn am besten
wäre (siehe Abbildung 3).
Abb. 3: Mögliche Optionen für korrigierende Eingriffe
vor DB2 UDB V.8.2
Mit dem Recommandation Advisor wird nun eine Rangliste empfohlener
Eingriffe erzeugt, die auch Verfügbarkeits- und Nachtuningmaßnahmen berücksichtigen (siehe Abbildung 4).
8
Abbildung 4: Rangliste der Empfehlungen
II.
SELF – CONFIGURING
Der Sinn der Selbstkonfiguration des DBMS liegt in der Übernahme des
Wählens der Konfigurationsparameterwerte durch die Datenbank. Vorher
mussten die richtigen Parameterwerte aus einem Satz von 150 Konfigurationseinstellungen vom Administrator gewählt werden, was eine gewisse
Kenntnis des konkreten DB – Produkts als auch Erfahrung mit der Konfiguration komplexer Datenbanken voraussetzte.
Korrelationen zwischen verschiedenen Parameterkonfigurationen mussten
erkannt werden und schlecht gewählte Einstellungen konnten die Datenbank zukünftig ausbremsen, da ein großer Teil der Parameter nicht online
umgeändert und angepasst werden kann.
Schon seit Version 5 gibt es eine Entwicklung zur Unterstützung des Administrators bei der Konfiguration des DBMS. Doch seit Version 8.1 verrichten nun verschiedene Advisors (Configuration- und Design Advisor) in
der IBM DB2 UDB ihren Dienst und bringen weitreichende Verbesserungen, wie anwenderfreundlichere Interfaces und überarbeitete Algorithmen
für bessere Performance mit. Sie sollen vordergründig dem Anwender helfen die richtigen Konfigurationsparameterwerte zu wählen und das in wenigen Sekunden.
9
2.1 Der Configuration Advisor
Das „Configuration Advisor“ [KLS+03] genannte Tool führt den Anwender
Schrittweise durch ein Kontextmenü und gibt Informationen zu den gewählten Einstellungen.
Er liefert dafür eine Menge von rund 36 Parametereinstellungen, die das
automatische Tunen und Konfigurieren der DB2-Umgebung in Bezug auf:
• Speicherverteilung
• Parallelität
• I/O-Optimierungen
• Recovery
erlauben.
Am Beispiel der Speicherverteilung zeigt sich, dass diese Einstellungen
Einfluss auf die Performance des DBMS haben. da sie die Allokation des
Speichers für wichtige DB-Operationen wie z.Bsp. Daten-Caching, -Sorting
und Networking bestimmen.
2.1.1
Architektur des Configuration Advisors
Wie die Übersicht (Abb.5) zeigt,
teilen sich die Informationen, welche der Configuration Advisor
sammelt in drei Bereiche auf. Er
baut sein Konfigurationsmodell
zum Ersten aus Daten auf, die er
automatisch vom System erkennt.
Dazu gehören Informationen über
den physikalischen Aufbau der
Ausführungsplattform, wie die Anzahl von CPUs, Festplatten, die
Größe des physikalischen Hauptspeichers und das Betriebssystem. Auch Informationen über die
Datenbank werden automatisch
erkannt. Die Anzahl von Tables,
Indizes und Tablespaces werden
ebenso ermittelt, wie die Größe
der Datenbank(en).
Hinzu kommen noch die ermittelten Daten zur Anzahl, Name und
Größe der Bufferpools.
Abbildung 5: Übersicht Configuration Advisor
Der nächste große Schritt liegt in der Eingabe von Daten durch den Anwender. Ihm wird eine Reihe von Standardfragen gestellt, die Auskunft
über die Ausrichtung und Verwendung der Datenbank geben sollen.
10
Als erstes gilt es den Prozentsatz des physikalischen Speichers festzulegen, welcher dem DBMS zu Verfügung stehen soll. Dann wird die
Grobausrichtung der DB über den erwarteten Workload definiert. Dazu
wird zwischen den Optionen „OLTP“ (steht für Online Transaction Processing – Einem DB Benutzungsparadigma, welches hochfrequente Lese- und
Schreibzugriffe auf sich ständig verändernden Daten beschreibt),
„complex query“ für eine Ausrichtung auf komplexe (verkettete) Anfragen
und der Einstellung „mixed“ für eine Zwischenlösung gewählt. Auch wird
die Anzahl von entfernten und lokalen Nutzerverbindungen eingestellt.
Die Prioritätsanfrage erlaubt es, dass relative Verhältnis zwischen Recovery- und Querygeschwindigkeit festzulegen.
Eine weitere Frage zielt auf die Populationsstufe der Datenbank ab, es
wird eingestellt ob sie eher schwach oder stark befüllt ist.
Außerdem wird nach dem Isolationslevel und der Variabilität der Bufferpoolgröße gefragt.
Jede dieser gesammelten Informationen wird nun im dritten und letzen
Schritt mit einem mathematischen Modell kombiniert, welches aus den
Heuristiken der IBM-Forschung der letzten Jahrzehnte hervorgeht.
Damit werden zusätzlich die Trade-Offs zwischen den Einstellungen für
Memory Heaps, Parallelität und Skalierbarkeit ermittelt, was für den Menschen nur schwer zu bewerkstelligen wäre.
2.1.2
Interfaces des Configuration Advisors
Zur Ausführung des Configuration Advisors gibt es drei Interfaces.
Zum einen ein grafisches Interface als Teil des DB2 Control Centers (siehe
Abbildung 6).
Abbildung 6: Grafisches Interface des Configuration Advisor
11
Außerdem wird ein Command Line Interface angeboten, bei dem der Contiguration Advisor über den Befehl „db2 autoconfigure“ gestartet wird. Per
„using“-Parameter lassen sich z.B. folgende Konfigurationseinstellungen
festlegen:
“[using]
MEM_PERCENT 75
WORKLOAD_TYPE complex
IS_POPULATED yes
NUM_LOCAL_APPS 1
NUM_REMOTE_APPS 50
ISOLATION rr
BP_RESIZEABLE yes
APPLY db AND dbm“
Dabei wird das Schlüsselwort APPLY und die gültigen Token “db ONLY“,
„db AND dbm“, sowie „NONE“ genutzt, um den Grad anzugeben, zu dem
die Empfehlungen des Advisors angewendet werden.
Die dritte Möglichkeit besteht im Zugriff auf den Configuration Advisor über programmierbare APIs oder Java Stored Procedures, welche als Web
Services aufgefasst werden können, so dass andere Anwendungen leicht
auf sie zugreifen können.
Im Ergebnisfenster werden schließlich nochmals alle Parameter mit ihrem
aktuellen und ihrem empfohlenen Zustand angezeigt. Der Administrator
hat nun die Wahl die Änderungen auszuführen oder sie als Script für die
spätere Nutzung zu sichern.
2.1.3
Experiment
Die IBM Paper [KLS+03] zeigen einen starken Anstieg der Performance,
resultierend aus den Konfigurationseinstellungen des Configuration Advisors gegenüber den Default- Konfigurationswerten.
So erreichten Datenbanken mit den vorgeschlagenen Parametern in
Benchmarks (OLTP 32 bzw. 64 Bit) nahezu die Performance der von erfahrenen DB-Spezialisten von Hand getunten Systemen (siehe Abbildung 7).
Gerade im Hinblick auf einen sich während der Ausführung variabel verändernden Workload bietet es sich an, den Configuration Advisor in wenigen
Sekunden eine neue Konfiguration finden zu lassen.
12
Abbildung 7: Datenbank Performance: Hand-getunte Parameter vs.
Configuration Advisor Tuning
2.2 Der Design Advisor
Die Aufgabe ist sehr aufwändig, einen Index „von Hand“ zu erstellen und
durch Testanfragen oder den im normalen Datenbankbetrieb anfallenden
Anfragen auf seine Tauglichkeit zu testen. Erfahrene Datenbankadministratoren konnten aufgrund ihres Fachwissens meist noch relativ
gute Ergebnisse erzielen. Dennoch ist es notwendig dieses Problem zu automatisieren, um dauerhaft und konstant gute Ergebnisse zu erzielen.
In dem Datenbanksystem DB2 von IBM ist ab der Version 6.1 der DB2 Index Advisor [VZZ+00] im Einsatz. Dieser hat die Aufgabe eine geeignete
Menge von Indizes auszuwählen. Ab Version 8.2 ist der DB2 Index Advisor
im DB2 Design Advisor [ZRL+04] enthalten, welcher sich nicht ausschließlich um Indizes, sondern auch um andere wichtige Design-Entscheidungen
kümmert. Für einen gegebenen Satz von SQL-Anweisungen in einem
Workload generiert der Design Advisor Empfehlungen für folgende Objekte und Maßnahmen:
•
•
•
•
•
Neue Indizes
Neue materialisierte Sichten (MQTs)
Umwandlung in MDC-Tabellen (mit mehrdimensionalem Clustering)
Umpartitionierung von Tabellen
Löschen von Indizes und MQTs, die durch die angegebene Auslastung nicht genutzt werden (über das GUI-Tool)
13
Besondere Aufmerksamkeit wird in diesem Abschnitt der Empfehlung der
neuen Indizes gewidmet.
2.2.1
Architektur des Design Advisors
In der Abbildung 8 wird die grobe Architektur des Design Advisor
[IBM+00] gezeigt.
Abbildung 8: Architektur des Design Advisors
Der Design Advisor verhält sich wie eine Blackbox, die Empfehlungen für
Indizes, neue materialisierte Sichten usw. generieren kann. Die Blackbox
hat zwei Inputs, zum einen SQL-Anweisungen als Workload, zum anderen
statistische Daten aus dem DB2-Katalog. Die Blackbox hat einen Output,
die Empfehlungen. Der Design Advisor nutzt vier Komponenten:
•
ein grafisches Userinterface,
•
ein command-line tool „db2advis”
•
DB2 Optimizer
•
Advise Tables
Bei IBM wurde, um den DB2 Advisor zu realisieren, hauptsächlich der bereits bestehende Anfrageplan-Optimierer [SLV+01] erweitert. Der Optimierer berechnet den kostengünstigsten Anfrageplan für eine SQLAnfrage. Ein im System vorhandener Index kann die Kosten für einen Anfrageplan erheblich senken. Der Optimierer kann also beurteilen, ob ein
vorhandener Index eine Verbesserung für einen Anfrageplan bringt. Die
14
Erweiterung besteht nun darin, den Optimierer selbst entscheiden zu lassen, welche Indizes eine Verbesserung erzielen. Diese Indizes werden
dann dauerhaft in das System übernommen. Um während der Auswahl
keine echten Indizes anlegen zu müssen, wird dem Optimierer eine Menge
von virtuellen Indizes per Eintrag im Systemkatalog übergeben, aus denen
er dann die zu installierenden Indizes auswählt.
Die Advise Tables werden zum Kommunizieren zwischen Optimierer und
command tool db2advis verwendet. Die Tabelle ADVISE_INDEX enthält
den Wert USE_INDEX='Y' oder 'R' für Indexempfehlungen. Die Tabelle
ADVISE_TABLE enthält USE_TABLE='Y' für MQT- und MDC-Tabellen sowie
Empfehlungen zu Partitionierungsstrategien. Die Empfehlungen zu MQT
sind außerdem in der Tabelle ADVISE_MQT, die MDC-Empfehlungen in der
Tabelle ADVISE_TABLE und die Empfehlungen zu Partitionierungsstrategien in der Tabelle ADVISE_PARTITION zu finden.
Workload
Eine Workload [DB2WEB] ist eine Gruppe von SQL-Anweisungen, die der
Datenbankmanager in einem bestimmten Zeitraum verarbeiten muss.
Zum Beispiel könnte eine Aufgabe des Datenbankmanagers sein, in einem
Monat 1000 INSERT-, 10000 UPDATE-, 10000 SELECT- und 1000 DELETEAnweisungen zu verarbeiten. Der Design Advisor analysiert ein vorgegebenes Workload und zieht Faktoren, wie den Typ der Workloadanweisungen, die Häufigkeit, mit der eine bestimmte Anweisung auftritt, sowie
Merkmale der Datenbank in Betracht, um Empfehlungen zu generieren,
die den Gesamtaufwand zur Ausführung des Workloads minimieren.
Über die Seite "Workload" der grafischen Benutzerschnittstelle des Design
Advisor (Abbildung 9) kann eine neue Workloaddatei erstellt oder eine bereits vorhandene Datei modifiziert werden. Anweisungen können in die
Datei aus verschiedenen Quellen importiert werden:
•
•
•
•
•
Eine Textdatei
Eine Ereignismonitortabelle
Query Patroller-Protokolldatentabellen durch die Option -qp über die
Befehlszeile
Mit EXPLAIN bearbeitete Anweisungen in der Tabelle
EXPLAINED_STATEMENT
Neue SQL-Anweisungen, die mit einer DB2-Momentaufnahme
erfasst wurden
Nach dem Importieren der SQL-Anweisungen kann man Anweisungen hinzufügen, ändern, modifizieren oder entfernen sowie die Häufigkeit der
Anweisungen modifizieren.
15
Über die Befehlszeile wird der Design Advisor wie folgt ausgeführt:
•
Mit einer einzigen SQL-Anweisung, die in der Befehlzeile zusammen
mit dem Befehl angegeben wird
•
Mit einer Gruppe dynamischer SQL-Anweisungen, die in einem DB2Snapshot erfasst wurden
•
Mit einer Gruppe von SQL-Anweisungen, die in einer
Workloaddatei enthalten sind
Abbildung 9: die Seite "Workload" der grafischen Benutzerschnittstelle des Design Advisors
Ablauf der Indexempfehlung
Es gibt insgesamt sieben Schritte zur Indexempfehlung.
1.
Schritt: Der Workload wird in der Tabelle ADVISE WORKLOAD
gespeichert.
2.
Schritt: GUI führt das Programm db2advis aus.
3.
Schritt: Für jede SQL-Anweisung in der Tabelle ADVISE WORKLOAD
ruft db2advis den DB2 UDB Optimizer auf.
4.
Schritt: Basierend auf statistischen Daten schlägt der Optimizer
einige Indizes vor.
5.
Schritt: Der Optimizer speichert die vorgeschlagenen Indizes in die
Tabelle ADVISE INDEX.
6.
Schritt: Die vorgeschlagenen Indizes werden getestet, dabei werden
die beste Teilmenge von Indizes ausgewählt
7.
Schritt: Ergebnis kann ausgegeben und bei Bedarf angewandt
werden
16
2.2.2
Experiment
Wir zeigen jetzt durch ein Experiment [DB2MAG], dass der Design Advisor
leistungsfähige Empfehlungen generieren kann. Das Experiment wird auf
einem 8 CPU AIX(R) 5.2 System mit vier Partitionen ausgeführt. Die Größe der Datenbank beträgt 1 GB. Die Datenbank-Schemata sind aus dem
TPC-H Benchmark. Der Workload besteht aus 22 Anfragen aus ebenfalls
diesem Benchmark. Innerhalb von 10 Minuten schlägt der Design Advisor
einen Entwurf für das Experiment vor. Der Entwurf enthält
•
•
•
•
18 neue Indizes,
2 materialisierte Sichten,
6 mehrdimensionales Clustering-Tabellen,
4 Partitionsveränderungen usw.
In der Abbildung 10 ist Baseline der Basisentwurf. New Design ist das mit
Hilfe des Design Advisors erzeugte Design. Man kann sehen, dass die Ausführungszeit um 84% reduziert wird.
Abbildung 10: Leistungsverbesserung des neuen Designs
III.
SELF – OPTIMIZING
3.1 Self – Tuning Memory
Es war vormals eine schwierige Aufgabe, die maximale Größe eines Heaps
zu bestimmen. Hauptsächlich aus zwei Gründen. Zum einen ist es schwierig, die Größe bzw. Art eines gegebenen Workloads festzulegen. Damit ist
die Bestimmung der Speichergröße für ein gegebenes Workload auch nicht
einfach. Zum zweiten ändert sich der Workload zu unterschiedlichen Zeiten. Selbst wenn die maximale Größe von erfahrenen Datenbankadministratoren festgelegt wird, tritt ein anderes Problem auf, nämlich das die maximale Größe nicht überschritten werden kann. Das führt beispielsweise zu
folgendem Verhalten:
17
Bei der Ausführung des Backups wird eine große Menge von Daten in den
Bufferpool geladen. Wenn der Bufferpool sehr klein ist, werden die Daten
aus dem Bufferpool auf die Festplatte ausgelagert und müssen beim
nächsten Zugriff wieder in den Bufferpool geladen werden. Die Performance sinkt in dieser Situation erheblich.
In DB2 UDB Version 9 ist es möglich, für Heap, Bufferpool und Cache ein
garantiertes Minimum vorzugeben. Die nicht reservierten Speicherbereiche können von Heap, Bufferpool und Cache nach Bedarf allokiert werden.
Es ist in DB2 jetzt auch möglich, dass Heap, Bufferpool und Cache im laufenden Betrieb automatisch konfiguriert werden. Folgende Speicherressourcen lassen sich tunen:
•
•
•
•
•
•
Buffer Pools
Package Cache + Catalog Cache
Locking Memory
Sort Memory
Total Database Shared Memory
……
In der Abbildung 11 werden diese Speicherressourcen graphisch dargestellt. Man kann sehen, dass das blaue Gebiet für den gesamten Datenbankspeicher steht. Ein Teil davon wird von Bufferpool, Locklist, Sorts,
Hash Joins und Package Cache reserviert. Im Vergleich zu Oracle hat DB2
einen Vorteil. Wenn die Seitegröße für Sorts und Bufferpool in Oracle größer als 4KB ist, können diese beiden Speicherressourcen nicht getunt werden. [ASTM+06]
Abbildung 11: Database Memory
18
3.1.1
Self-Tuning Memory Manager
Die grundlegende Komponente des Self-Tuning Memory Managers (STMM)
ist der Memory-Controller (Abbildung 12). Sein Ablauf sieht so aus: Aus
dem Workload werden die kostenabgeschätzten Daten extrahiert. Diese
Daten fließen als Input in den Memory Controller ein. Basierend auf diesen
Daten wird eine neue Allokation des Datenbank Speichers vorgeschlagen.
Dann wird geprüft, ob die neue Allokation des Datenbank Speichers die
Systemleistung verbessern kann. Abschließend wird das Ergebnis nach
Bedarf angewandt. Es ist zu erwähnen, dass die Frequenz des Tunings
auch basierend auf den kostenabgeschätzten Daten durch den MemoryController festgelegt werden kann.
Abbildung 12: die Architektur des Self -Tuning Memory Managers
3.1.2
Beispiel
Die Abbildung 9 zeigt, wie ein Heap vom Self-Tuning Memory Manager getunt wird. Die gelben Teile sind die garantierten Minima. Die grünen Teile
sind die benutzten Speicherbereiche des Utilities Heaps. Die blauen Teile
sind die unbenutzten Speicherbereiche des Datenbank Speichers.
UTIL_HEAP_SZ gibt die maximale Speichergröße an, die gleichzeitig von
den Dienstprogrammen BACKUP, RESTORE und LOAD (einschließlich Wiederherstellung) verwendet werden kann. DBHEAP ist ein Datenbankzwischenspeicher für eine Datenbank, der vom Datenbankmanager für alle
Anwendungen, die auf die Datenbank zugreifen, verwendet wird. Der Package Cache wird aus dem gemeinsam benutzten Datenbankspeicher zugeordnet und für das Caching (Zwischenspeichern) von Abschnitten statischer und dynamischer SQL-Anweisungen in einer Datenbank verwendet.
19
Das obere Bild in der Abbildung 13 zeigt, dass die benutzten Speicher des
Utilities Heap kleiner sind als das garantierte Minimum. Das untere Bild
zeigt, was passiert, wenn z.B. Backup plötzlich mehr Speicher reservieren
will, als das garantierte Minimum bietet. Nicht benutzter Database Speicher wird vom Memory Controller nach Bedarf dem Utilities Heap zugewiesen.
Abbildung 13: Ein Beispiel von Heaptuning
3.1.3
Experiment
Die Abbildung 14 zeigt die Ergebnisse des getunten Speichers bei einem
Benchmark Test. [DB2STM] Das linke Bild zeigt, wenn der Workload in
diesem Benchmark Test steigt, wird kontinuierlich mehr Speicher automatisch DB2 zugewiesen. Das rechte Bild zeigt, wenn DB2 mehr Speicher
zugewiesen wird, steigt die Systemleistung kontinuierlich bis zu einem
gewissen Punkt.
Abbildung 14: Wirkung von Memory-Tuning auf Systemperformance
20
3.2 POP – Progressive OPtimization
Die Fähigkeit der Selbst-Optimierung wir zurzeit von zwei Strategien geprägt. Dem LEarning Optimizer (LEO) und der Progressive Query Optmization (POP) [KHE+06]. Zweiteres liefert flexible Mechanismen zur OnlineAnpassung von Query Execution Plans (QEP). Diese bildeten vormals eine
Fehlerquelle, da der Optimierer durch Fehlabschätzungen der Kardinalitäten suboptimale Pläne erzeugte. POP erkennt suboptimale Pläne und erlaubt Optimierungen zur Laufzeit. Damit wird die Robustheit des DBMS
gegenüber Fehlabschätzungen des Optimierers erhöht und gleichzeitig
Eingriffe des Administrators minimiert.
Die herkömmliche Struktur der
SQL-Kompilierung, dargestellt in
der nebenstehenden Übersicht
(Abb.15), zeigt gewisse Nachteile
auf. Die Ausführungspläne werden
nur mit Hilfe von statischen Statistiken erstellt.
Dies führt zu Problemen wegen
veralteten Plänen und falschen
Vermutungen
über
Abhängigkeiten von Attributen.
Suboptimale Pläne führen zu Performanceeinbußen.
Abbildung 15: klassische SQLOptimierung
POP erweitert diese klassische Form der SQL-Optimierung und erlaubt eine dynamische Reoptimierung zur Laufzeit.
Dazu vergleicht POP die Kardinalitätsabschätzungen mit den aktuellen
Werten zur Laufzeit. Es werden Checkpoints (CHECK – Operatoren) in den
QEP integriert. Diese besitzen eine Bedingung, die die Kardinalitätsgrenzen (sog. „Validity Range“) für jeden einzelnen Operator des Ausführungsplans erkennt, innerhalb denen der Plan gültig ist.
Wird diese Bedingung verletzt, d.h. die Validity Range über/unterschritten, kommt es sofort zur Ausführung einer Reoptimierung.
Dies erlaubt kontinuierliche Anpassungen des Plans durch einen geschlossenen Feedbackkreis zwischen Laufzeit und Optimierer (siehe Abbildung
16).
21
3.2.1
Architektur von POP
Abbildung 16: SQL-Optimierung mit POP
Wie man sieht hat sich an der Basis nicht viel verändert, der klassische
Aufbau der SQL-Kompilierung bleibt natürlich gleich. Neu sind lediglich die
CHECKpunkte, welche aber ein leistungsfähiges Werkzeug bilden, um Fehler in den Abschätzungen schon während der Laufzeit zu erkennen und vor
allem zu korrigieren [RMS+04].
Die grünen Pfeile gemeinsam mit Pfeil 1 sollen diesen um Checks erweiterten klassischen Ablauf beschreiben. Aus den mittels Statistiken und
Kostenmodell verglichenen Plänen wählt der Optimierer den besten Plan
und bringt ihn zur Ausführung. Pfeil 1 demonstriert die Zwischenspeicherung von Teilergebnissen, die durch Abarbeiten des aktuellen Planes entstanden sind bzw. entstehen solange keiner der Check-Operatoren verletzt
wird.
Der zweite Pfeil fügt nun genau jenen Fall hinzu. Durch das Verlassen des
Gültigkeitsbereiches für einen bestimmten Operator wird die CheckBedingung verletzt und die Reoptimierung getriggert.
Alle bisher angefallenen Zwischenergebnisse werden als materialisierte
Sichten (den sog. MQTs) gesichert.
Die ausgelöste Reoptimierung weist auf einen Fehler in den Kardinalitätsabschätzungen im aktuellen Ausführungsplan hin. Zum Beispiel könnte
die Ausgabe für eine bestimmte SCAN- und SORT- Anfrage unterschätzt
worden sein. (Pfeil 3)
22
Da in den materialisierten Sichten die aktuellen Kardinalitäten stehen (in
diesem Bsp. die viel größeren Werte für die Ausgabe, als in den geschätzten Werten), werden diese an den Optimierer weitergegeben, um bei der
Bestimmung des neuen besten Planes diese Informationen einfließen zu
lassen. In der Abbildung wird dies durch die Pfeile 4 und 5 dargestellt.
Weiterhin nutzt der Optimierer dabei durch den LEarning Optimizer (LEO)
aktualisierte Statistiken, der in Abschnitt 3.3 vorgestellt wird.
Schließlich werden die bisher gesammelten Teilergebnisse weiter genutzt,
was es erlaubt diesen Optimierungskreis während der Ausführung kontinuierlich laufen zu lassen.
Die Unterbrechung und Reoptimierung kostet zwar Zeit, doch der Nutzen
wiegt dies wieder auf - ein wirklicher Nachteil entsteht nicht.
Eher stellt sich mit laufender Reoptimierung eine immer stärkere Robustheit gegenüber Fehlabschätzungen des Optimierers ein, so dass Eingriffe
des Administrators überflüssig werden und gleichzeitig die Abarbeitungsgeschwindigkeit der Queries deutlich steigt [MRS+04].
3.2.2
Beispiel für eine Reoptimierung
Abbildung 17 zeigt noch einmal an einem Beispiel für eine SELECT Anfrage, wie der Initialplan durch den Optimierer nach einem verletzten
CHECKpoint verändert wurde und z.Bsp der Nested Loop Join (NLJN)
durch einen Merge Join (MGJN) ersetzt wird. Dieses Joinen bringt dahingehend Vorteile, da ein Teil des im Initialplan linken Astes ja bereits als
Zwischenergebnisse berechnet wurde und somit dem neuen Plan zur Verfügung steht.
23
Abbildung 17: Vergleich von Initialplan und Plan
nach Re-Optimierung bei POP
3.3
Der LEarning Optimizer (LEO)
Bei der Übersetzung von SQL-Befehlen wählt der klassische Optimizer
aufgrund der Katalogstatistiken die Zugriffspfade aus, die er als optimal
errechnet. Dennoch können die ausgeführten Zugriffe weit hinter den erwarteten Ergebnissen zurückbleiben. Bislang ist dann eine aufwändige Analyse durch den Spezialisten nötig, um den Grund dafür herauszufinden.
Nun übernimmt der Learning Optimizer wenigstens in einigen Teilen diese
Aufgabe.
Der Learning Optimizer, abgekürzt LEO, der bereits in die DB2 Universal
Database (seit Ver.9) integriert wurde, ist in der Lage, falsche Statistiken
und Kardinalitätsschätzungen während der Anfrageausführung zu erkennen und zu korrigieren. Dazu vergleicht LEO in jedem Schritt des Anfrageausführungsplans die Schätzwerte des Optimierers mit den aktuellen Werten. Stellt das System fest, dass sich die geschätzten Werte stark von den
tatsächlichen Werten unterscheiden, so werden die vom Optimierer verwendeten Werte für zukünftige Optimierungsvorgänge angepasst. Zusätz24
lich verfügt LEO über einen Feedback-Mechanismus (feedback loop), der
es dem System ermöglicht, aus früheren Fehlern zu lernen. LEO kann aus
jedem Fehler an jeder Stelle im Modell lernen. Dazu zählen insbesondere
Fehler bei der Selektivitätsabschätzung von Attributen, von benutzerdefinierten Funktionen, von Prädikaten mit Host-Variablen sowie von JoinPrädikaten. Zusätzlich kann LEO auch Informationen über die Pufferauslastung, den Speicherverbrauch beim Sort-Heap und das E/A-Verhalten
liefern.
3.3.1
Architektur
Abbildung 18: Architektur von LEO
Abbildung 18 zeigt, wie LEO in die Architektur von DB2 eingebunden ist.
Die linke Hälfte der Abbildung zeigt die klassischen Komponenten zur Anfrageverarbeitung (SQL-Compiler, Optimierer, Code-Generator und das
Laufzeitsystem). Die grau hervorgehobenen Komponenten stellen die Erweiterung der Architektur dar. LEO besteht aus vier Komponenten: Planaufbewahrung, Monitor, Analyse und Verwendung, diese sind in Abbildung
18 dargestellt.
Planaufbewahrungskomponente
Der Code-Generator liefert ein ausführbares Programm aus dem optimalen
Anfrageausführungsplan, welches als Section bezeichnet wird. Eine Sektion besteht aus Sequenzen von Operatoren (sog. threads), die zur Laufzeit
interpretiert werden. Deshalb wäre es im Prinzip möglich, daraus den Anfrageausführungsplan wieder zu rekonstruieren. Da dieses Vorgehen aber
in der Praxis zu teuer wäre, wird ein anderer Weg eingeschlagen: Wäh25
rend der Übersetzung einer Anfrage wird ein Skelett (Untermenge des optimalen Anfrageausführungsplans) in der Datenbank gespeichert, der
dann als Grundlage für die weitere Analyse dient. Ein solches Skelett für
die folgende Anfrage (Abbildung 19), ist in Abbildung 20 zu sehen. Es
wurde mit statistischen Informationen angereichert.
Abbildung 19: SQL-Anfrage
Abbildung 20: Skelett des optimalen Anfrageausführungsplans
für die gegebene Anfrage.
Dabei bezeichnet Stat die Anzahl der Tupel in der Relation, wie sie im System-Katalog gespeichert ist. Die Variable Est bezeichnet den Schätzwert
des Optimierers für die Kardinalität des Ergebnisses, das vom jeweiligen
Planoperator erzeugt wird. Schließlich wird mit Act die tatsächliche Kardinalität bezeichnet, das der Planoperator zur Laufzeit geliefert hat.
26
Monitorkomponente
Die Monitorkomponente ist dafür verantwortlich, dass die in Abbildung 16
dargestellten aktuellen Kardinalitäten (Act) berechnet werden. Zur Erfassung der tatsächlichen Anzahl der verarbeiteten Tupel, wird jeder Planoperator in der Sektion mit einem Zähler versehen. Dieser Zähler wird immer
dann inkrementiert, wenn der Planoperator ein Tupel verarbeitet hat. Für
LEO ist wichtig, dass die aktuellen Kardinalitäten für jede Anfrage bestimmt und später von der Analysekomponente zum Lernen verwendet
werden.
Analysekomponente
Die Analysekomponente ist die wichtigste Komponente von LEO, denn hier
kommt es zum Query Feedback. Es werden fehlerhafte Berechnungen erkannt, nach Ursachen dafür gesucht und Anpassungswerte gespeichert,
sodass bei später folgenden ähnlichen Anfragen, die Fehler nicht wieder
auftreten.
Die aktuellen Kardinalitäten, die von der Monitorkomponente gesammelt
wurden, werden mit dem Skelett des korrespondierenden QEP zusammengeführt (siehe Abbildung 20). Das Skelett des QEP wird nun rekursiv
analysiert. Durch den Vergleich der tatsächlichen Selektivität eines Prädikates mit den geschätzten Werten, die im Skelett gespeichert wurden,
kann LEO einen Anpassungsfaktor adj (engl. adjustment factor ) ableiten.
old est: geschätzte Selektivität des Optimierers
old adj: alter Anpassungswert, welcher möglicherweise benutzt wurde, um
old est zu berechnen
act: die tatsächliche Selektivität, geliefert von der Monitorkomponente
Wenn für ein Prädikat (z.B. col < x) ein Fehler (|old est − act|/act > 0,
05, d.h. eine 5%-ige Abweichung) festgestellt wird, berechnet LEO folgendermaßen einen Anpassungswert.
Wobei stat die geschätzte Selektivität aus dem Statistikkatalog des Systems ist. Da stat nicht im Skelett gespeichert wird, muss zur Berechnung
old est verwendet werden.
27
Aus (1) und (2) folgt:
Die Selektivität für ein Prädikat sel(col >= x) entspricht 1 − sel(col < x),
daher
wird die Berechnung der Selektivität für den >-Operator auf den <Operator
zurückgeführt. Aber zur Berechnung des Anpassungswertes wird der <Operator aus
dem >-Operator abgeleitet. Das Beispiel aus Abbildung 20 soll dies verdeutlichen. Der Anpassungswert für den Operator TBSCAN auf Tabelle X
mit dem Prädikat Price >= 100 wird wie folgt berechnet.
Für dieses Prädikat Price >= 100 erhält man für die Kardinalität der Relation den Anpassungsfaktor:
Die Selektivität des Prädikates Price >= 100 wurde hierbei vom Optimierer so geschätzt:
Tatsächlich war der Selektivitätswert des Prädikates Price >= 100 aber:
Anpassungswert adj für Price < 100:
Dieser Anpassungsfaktor für Price < 100 wird dann in der Datenbank gespeichert.
Verwendungskomponente
Bevor der Optimierer die verschiedenen Anfrageausführungspläne erzeugt,
werden für alle Basis-Tabellen der Anfrage die Selektivitätsfaktoren für
jedes Prädikat berechnet. Wenn das Lernen angeschaltet ist (LEARNING =
true), werden in den LEO Tabellen Anpassungswerte
28
gesucht und mit ihnen gegebenenfalls die Basis-Tabellen-Statistiken oder
Prädikat Selektivitäten angepasst. Die Selektivität und Kardinalität für Price >= 100 wird z.B. bei ausgeführter Anfrage mit Hilfe des Anpassungsfaktors für Price < 100 in der Datenbank wie folgt berechnet:
IV.
ZUSAMMENFASSUNG
IBM DB2 bietet – gerade im Hinblick auf die Mitwettbewerber – schon
zahlreiche teilautonome Werkzeuge, die eine Entlastung des Administrators erzielen. Ein hoher Anteil liegt bei den Advisors, welche dem
Anwender erweiterte Informationen zu jeweiligen Aufgaben oder Problemen liefern und zusätzlich meistens kostenoptimale Lösungen vorschlagen. Ziel von IBM ist es, den Autonomiegrad weiter zu steigern
und damit für die Administration komplexerer zukünftiger DBGenerationen gewachsen zu sein.
Der Großteil der in dieser Arbeit vorgestellten Tools sind Weiterentwicklungen von Ansätzen aus weit zurückliegenden Releases. Mit Version
8.1 wurde jedoch ein ganzer Schwung von Tools implementiert, die den
nächsten Schritt in Richtung Autonomie darstellten. Viele dieser Werkzeuge (z.B. der Configuration Advisor) werden seitdem als Defaulteinstellung ausgeführt.
Mit Version 9 (bzw.9.1) kamen neue „adaptive,self-tuning memory“
Features hinzu, als auch automatische Statistikerzeugung und Verbesserungen der automatischen Table- und Indexreorganisation.
Ausblick
Die IBM DB2 –Entwicklung schließt daran an und möchte weitere umfangreiche Tools hervorbringen, um die in Paul Horns Autonomic Computing Manifesto [Horn+04] gesteckten Ziele zu erreichen. Bis zum autonomen Datenbanksystem ist es aber noch ein weiter Weg.
29
V. Quellen:
Horn+04
Horn,Paul: Autonomic Computing Manifesto; IBM Research;
Oct.2001
VZZ+00
Valentin, G.; Zuliani, M.; Zilio, D. C.; Lohman, G.; Skelley, A.:
DB2 Advisor: An optimizer smart enough to recommend its
own indexes, Proceedings of the ICDE Conference, 2000
ZRL+04
Zilio, D. C.; Rao, J.; Lighstone, S.; Lohmann, G.; Storm, A.;
Garcia-Arellano, C.; Fadden, S.: DB2 Design Advisor: Integrated Automatic Physical Database Design, VLDB 2004
SLV+01
Stillger, M.; Lohman, G. M.; Markl, V.; Kandil, M.: LEO: DB2’s
LEarning Optimizer, VLDB Conf. 2001
IBM+00
Gary Valentin, Michael Zuliani, Daniel C. Zilio, Guy Lohman:
DB2 Advisor: An Optimizer Smart Enough to Recommend Its
Own Indexes IBM Toronto Lab; 2000
DB2WEB
http://publib.boulder.ibm.com/infocenter/db2luw/v8//index.jsp
(Zugriffsdatum: 15.01.2007)
DB2MAG
DB2 Magazine; LINK: http://www.db2mag.com
Ebook: The autonomic computing advantage; LINK:
http://i.cmpnet.com/db2mag/ebook/db2auto/ebookController.
swf (Zugriffsdatum: 15.01.2007)
ASTM+06 Adam J. Storm, Christian Garcia-Arellano, Sam S. Lightstone,
Yixin Diao, M. Surendra: Adaptive Self-Tuning Memory in DB2
IBM Canada; VLDB`06; September 2006
STM+06
Rav Ahuja: Introducing DB2 9, Part 3: Self-tuning memory in
DB2 9, DB2 Program Manager, IBM; Juni 2006
RMS+04
Raman,V.;Markl,V.;Simmen,D.;Lohman,G.;Pirahesh,H.:
Progressive Optimization in Action, Proceedings of the 30th VLDB
Conference,2004
KLS+03
Kwan,Lightstone,Schiefer,Storm,Wu (IBM Canada) : Automatic
Database Configuration for DB2 UDB: Compressing Years of
Performance Expertise into Seconds of Execution
KHE+06
Kache,Shin Han,Markl,Raman,EwenPOP/FED: Progressive
Query Optimization for Federated Queries in DB2; VLDB´06
MRS+04
Markl,Raman,Simmen,Lohman,Pirahesh: Robust Query Processing through Progressive Optimization; SIGMOD 2004
30