vortrag_TEAM2

IBM DB2
Qiguang Yan & Stefan Lenschow
Seminar WS 2006/07:
Aktuelle Themen der
Datenbankforschung und -entwicklung
Gliederung
I.
Self – Healing
•
II.
Self – Configuring
•
•
III.
Configuration
Advisor
Design Advisor
Self – Optimizing
•
•
•
IV.
Health Monitor
Self-Tuning Memory
POP
LEO
Zusammenfassung
•
Ausblick / Quellen
I.Self – Healing Features
• Vorher:
– DBA betreut im Schnitt
über 20 Datenbanken
– 33% Zeit: Monitoring
– 22% Zeit: auf Probleme
reagieren
Quelle: DB2Mag : Continuous System Health Checking
Development
Support
33%
Tuning
12%
Monitoring
33%
Problem Solving
22%
• self-healing in DB2 (V8.1)
– kehrt Diagnosemodell des Gesundheitszustandes der DB um
• übernimmt Monitoring – Aufgaben
• DB überwacht sich selbst
• bietet Problemlösungen + Hilfe
• 2 Tools :
– Health Monitor(HM)
• Serverseitiges Tool
• Managed-by-Exeption Modell
• Überwacht komplettes
System während der
Ausführung (im Hintergrund)
– Health Center
• Dient als GUI - Tool des HM
• Erweitert Informationen des
HM um Lösungsstrategien
• Zur Veränderung der
Einstellungen
• DB2 Health Monitor:
– sammelt Systeminformationen per
Snapshot Monitor, was die Systemleistung
nur minimal beeinträchtigt
– nutzt sog. „Health Indicators“ für:
•
•
•
•
•
•
•
•
•
Instances
Databases
Logs
Tablespace storage
Sorting
Package and catalog caches
Workspaces
Memory
Application concurrency
– Die Indikatoren messen den „Gesundheitszustand“
eines Aspektes des ihm zugeordneten Objekts
• DB2 Health Indikatoren:
– Zustände:
» normal
» attention
» warning
» alert
– ausgelöst, wenn Objektaspekt kritischen Zustand
annimmt
– Kategorien:
• Schwellwert-basierte Indikatoren, die Statistiken des
Verhaltens des Objektes überwachen
• Zustandsbasierte Indikatoren, die 2 oder mehr eindeutige
Zustande überprüfen und damit Aussagen über kritisch
oder unkritisch liefern
• Sammelzustandsbasierte Indikatoren, sind Maße des
DB-Levels die angesammelte Zustände ein oder
mehrerer Objekte repräsentieren
• Meldet alle Alarminfos dem Journal
• Sendet diese via Email oder Pager zum DBA
• Führt vorkonfigurierte Aktionen aus (z.B. Ausführen
eines tasks, selbständiges REORG eines tables)
• Erkennt Situationen/ Veränderungen die
Performanceeinbußen nach sich ziehen könnten
•
Mittels
•
•
•
•
Health Center ( Diagnosezentrale in dt. Version )
Web Health Center
Command Line Prozessor ( CLP )
APIs
lassen sich
•
•
•
Informationen des Health Monitors abrufen
Healthindikatoren, Kontakte konfigurieren
Überblick aller bisherigen Alarme anzeigen
• Fügt Warnzeichen in alle anderen laufenden DB2 UDB
GUI Tools ein – mit Klick sofort zum Health Center
wechseln
Health Center (V8.1):
DB2 Health Center
– bei Problemen meldet DB2 sich und gibt auch
Lösungsvorschläge über den:
• Recommendation Advisor (RA) seit Ver.8.2
–
–
–
–
und gegebenes Problem zukünftig zu vermeiden
stellt dazu DBA Reihe von Fragen
basierend auf Antworten und aktuellem
Systemzustand
 RA liefert verschiedene Lösungswege
Entscheidung bestimmt wie der RA vorgeht
RA startet nötige Tools bzw. generiert automatisch
Scripts (z.B. Memory Visualizer)
Recommendation Advisor
II. Self – Configuring:
Configuration Advisor
– Das Problem:
• Fast 150 Konfigurationsparameter in DB2 UDB
• Anwender wissen nicht:
– Wie die richtigen Werte gewählt werden
– Welche möglichen Zusammenhänge zwischen Ihnen
bestehen
• Viele nicht online konfigurierbare Parameter zwang zum
Neustart von DB2 um bessere Konfigurationen zu
erstellen
• Aufgabe für erfahrene Spezialisten
• Configuration Advisor in DB2 UDB
(seit V.8.1) liefert Menge (~36) von
Parametereinstellungen zum
automatischen Konfigurieren und Tunen
der DB2 Umgebung in Bezug auf:
Speicherverteilung
Parallelität
I/O Optimierungen
Recovery
• Daten, die ConfigAdv.
automatisch erkennt :
– Systeminfos
• # CPUs, # HDDs
• Größe des
physikal.Speichers
• Betriebsystem
– DB Infos
• Größe, # Tables,
• # Indizes
• # Tablespaces
– Bufferpool Infos
• # Bufferpools
• Name, Größe für jeden
Bufferpool
• Daten, von User spezifiziert :
– Antworten zu 7 Fragen:
• Prozentsatz des
Speichers der DBMS
zugeordnet wird
• OLTP vs. Complex Query
vs. Mixed
• Rel. Verhältnis zwischen
Recovery  Query
Geschwindigkeit
• Lastprofil (Anzahl von
lokalen und entfernten
Nutzerverbindungen)
• Ist Datenbank befüllt oder
nicht
• Isolationsstufe
• Bufferpoolgröße
veränderlich
• Jede Systeminformation
wird nun mit einem
mathematischen Modell
kombiniert
• Basierend auf
Expertenheuristiken
• Ermittelt Trade-Offs
zwischen Memory Heaps,
Parallelität, Skalierbarkeit
die für Menschen schwer
zu abstrahieren sind
 Selbst-Konfigurations Fähigkeiten erlauben
ein Erkennen der Ausführungsumgebung
• Drei Ausführungsinterfaces
:
– Grafisches Interface ( Teil des DB2 Control
Center )
– Command Level Interface (Bsp:
„db2 autoconfigure 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“
– Über programmierbare APIs (auch für
Drittanbieter) oder Java Stored Procedures
Configuration Advisor: Grafisches Interface
Design Advisor
• Der Design Advisor generiert 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 der unbenutzten Indizes und
materialisierte Sichten (MQTs).
Architektur des Design
Advisors:
Workload für den
Design Advisor :
• Ein Workload ist eine Gruppe von
SQL-Anweisungen
User
Eine Textdatei
Graphical User Interface
Die vor kurzer Zeit
ausgeführten SQLAnweisungen im SQLCache
SQL-Cache
Statische SQL-Anweisugn
Package
1. Der Workload wird in der Tabelle
ADVISE WORKLOAD gespeichert
2. GUI führt das Programm db2advis aus
3. Für jede SQL-Anweisung in der Tabelle ADVISE
WORKLOAD ruft db2advis den DB2 UDB Optimizer
auf
4. Basierend auf statistischen Daten schlägt der
Optimizer einige Indizes vor.
5. Der Optimizer speichert die vorgeschlagenen Indizes
in die Tabelle ADVISE INDEX
6. Die vorgeschlagenen Indizes werden getestet und
dabei die beste Teilmenge von Indizes ausgewählt
7. Ergebnis ausgeben und bei Bedarf anwenden
• Jeder SQL-Anweisung kann eine
Frequenz zugewiesen werden
• SQL-Anweisung kann geändert oder
gelöscht werden
Experiment
• Der Design Advisor schlägt einen Entwurf
innerhalb von 10 Minuten vor. Der Entwurf enthält:
– 18 neue Indizes
– 2 MQTs (materialisierte Sichten)
– 6 MDC-Tabellen (mehrdimensionales
Clustering ),
– 4 Partitionsveränderungen,
– ….
Beispiel
Suchen nach den gemeinsamen Subexpressions bei der
Multi-query Optimierung
III.Self-Optimizing
Self – Tuning Memory
• Vorher:
– Es ist schwer, die maximale Größe eines
Speicherobjekts zu bestimmen.
– die maximale Größe kann nicht überschritten
werden
• Das führt dazu:
– Wenn z.B ein Bufferpool nicht groß genug für die
Datenspeicherung ist, werden die Daten aus dem
Bufferpool entfernt und beim nächsten Zugriff
wieder in den Bufferpool eingelesen. (Performance
sinkt)
• in DB2 UDB Version 9
– Heapgröße, Bufferpool, Cache etc.
dynamisch konfigurieren
– Garantierte Minimum für Heap, Bufferpool etc.
– nicht reservierte Speicherbereiche für Heap ,
Bufferpool etc. nach Bedarf allokieren
• Folgende Speicherressourcen können getunet werden
– Buffer pools
– Package cache
– Locking memory
– Sort memory
– Total database shared memory
Database memory
Self-Tuning Memory Manager
Cost-benefit Daten für
jeden Heap
Neue Größe für Heaps
und Databas_memory
•Bestimmt neue
Speicherallokation
•Legt die Frequenz des
Tunings fest
•…..
Beispiel
Wirkung von Memory-Tuning
auf Systemperformance
Automatisch wird mehr
Speicher DB2 zugewiesen
Systemleistung steigt sofort
um Faktor 10
Progressive OPtimization (POP)
• Problem:
– Sub-optimale QEPs( Query Execution Plan) durch Fehler in
Kardinalitätsabschätzungen des Optimierers
• POP
– liefert flexible Mechanismen zur Erstellung von QEPs
– erkennt suboptimale QEPs und liefert Optimierungen zur
Laufzeit
– robust gegen Fehlabschätzungen des Optimierers
– minimiert DBA Eingriffe
Vorher:
SQL Compilation
Statistics
Optimizer
Optimizer
• Pläne mit Hilfe von Statistiken erstellt
• Problem:
Best
Best
Plan
Plan
Plan
Execution
• nicht mehr aktuelle Statistiken
• falsche Vermutungen über
Attributsunabhängigkeiten
führen zu falschen Kardinalitätsabschätzungen und damit zu
suboptimalen Plänen
• POP vergleicht Kardinalitätsabschätzungen mit aktuellen
Werten zur Laufzeit
• geschieht mit Checkpoints (CHECK)
• haben Bedingung, die Kard.grenzen erkennt
in denen der Plan gültig ist = validity range für
jeden einzelnen Planoperator
• Wird CHECK Bedingung verletzt (validity
range überschritten)  Re-Optimization
ausgelöst
• erlaubt kontinuierliche Anpassungen des
Plans durch einen geschlossenen
Feedbackkreis zwischen Laufzeit und
Optimierer
Jetzt:
Statistics
SQL Compilation
Optimizer
Optimizer
3
4
New Best Plan
“MQT”with
Actual
Cardinality
Best Plan
Best
Plan
With
CHECK
5
2
New
Plan
Execution
6
Plan
Execution
with CHECK
Partial
Results
1
Re-optimize If
CHECK fails
Use feedback from
cardinality errors to
improve current plan
POP Monitor :
Beispiel:
Der LEarning
Optimizer (LEO)
• erkennt Fehler bei der
Kardinalitätsabschätzung
• korrigiert falsche Statistiken zur
Laufzeit
• „lernt“ mit Hilfe eines FeedbackMechanismus aus Fehlern
SQL Compilation
Optimizer
Optimizer
Best
Best
Plan
Plan
Plan
Execution
Statistics
Statistics
SQL Compilation
Optimizer
Optimizer
Best
Best
Plan
Plan
Plan
Plan
Execution
Execution
4. Anwendung
•
Adjustments
Adjustments
1. Planbewahrung
Estimated
Estimated
Cardinalities
Cardinalities
3. Analyse
2. Monitor
Actual
Actual
Cardinalities
Cardinalities
Beispiel
Berechnung des
Anpassungsfaktors
• Vergleiche geschätzte mit der tatsächlichen Selektivität
• Mit hoher Wahrscheinlichkeit liegt ein Fehler vor, wenn
gilt:
Berechnung des Anpassungsfaktors
Bestimme den Anpassungsfaktor für das
Prädikat (X.Price > 100)
IV. Zusammenfassung
• Seit Ver.8.1 stetige Erweiterung der autonomen
Fähigkeiten
• In Ver.9 neue adaptive, self-tuning memory
Features
• Ausblick:
– Weiterentwicklung bestehender Features für einen
höheren Autonomiegrad
– Einführung von self-protecting Features um DB
unverwundbarer zu machen bezüglich:
• Unauthorisiertem Zugriff und Nutzung
• Virus- / Denial-of-service Angriffen
• Und generellen Fehlern
Quellen:
•
•
•
•
•
•
•
Kwan,Lightstone,Schiefer,Storm,Wu (IBM Canada) : Automatic Database
Configuration for DB2 UDB: Compressing Years of Performance Expertise
into Seconds of Execution
Kache,Shin Han,Markl,Raman,EwenPOP/FED: Progressive Query
Optimization for Federated Queries in DB2
Javaid Rajmohamed for DB2Mag: Continuous System Health Checking
Markl,Raman,Simmen,Lohman,Pirahesh,Cilimdzic: Robust Query
Processing through Progressive Optimization
Gary Valentin, Michael Zuliani, Daniel C. Zilio: DB2 Advisor: An Optimizer
Smart Enough to Recommend Its Own Indexes
by V. Markl, G. M. Lohman, V. RamanLEO: An autonomic query optimizer
for DB2
Adam J. Storm, Christian Garcia-Arellano, Sam S. Lightstone, Yixin
Diao:Adaptive Self-Tuning Memory in DB2