Vortrag im Rahmen der Siegmundsburger Vortragsreihe 2006 zum Thema ASC und Self-Healing gehalten von Robert Fleischer

Inhalt des Vortrages 1.Self-optimization / ASC Motivation Beispiel für Notwendigkeit von ASC Die ASC Architektur Performance Beispiel 2.Self-healing Kurzüberblick Health Monitor Kurzüberblick Health Center

??? Self-management 3.Self-healing 2.Self-optimization 1.Self-configuration 4.Self-protection LEO+POP ASC Motivation und Aspekte des Self-management

Was ist ASC? Automated Statistics Collection Komponente in IBM DB2 UDB ver.8.2 im Rahmen des Self-management Konzeptes Automatisierung des in DB2 integrierten Runstats Tools Kein tiefgehendes eingreifen des DBAs Hält Statistiken des Systemkataloges aktuell, wenn kostenmäßig sinnvoll

Motivation für ASC? Manuelles pflegen der Statistiken zeitaufwändig und kompliziert Ziel jedes DBMS: Anfragen möglichst schnell und kostengünstig abzuarbeiten Nicht vorhandene bzw. aktuelle Statistiken resultieren in Fehleinschätzungen des Optimizers Schlechte Gesamtperformance und hohe Systembelastung

Beispiel für Fehleinschätzungen Gegeben: Relativ umfangreiche Tabelle (~ Datensätze) Nicht indiziert einfache Anfragen und dazugehörige Anfragepläne

Beispiel für Fehleinschätzungen x20

Lösung des Problems? Sicherstellen das relevante Statistiken existieren Überwachung der Aktualität Dieser Ohne übermäßigen Anstieg des Rechenaufwands Möglich durch Automatic Statistics Collection

Die ASC-Architektur Basiert auf zwei autonomen Prozessen Diese münden in Scheduler Scheduler Query-Feedback- Prozess UDI-Prozess

Der Update-Delete-Insert-Prozess Tabellenmenge G -X 1 -X 2 D = G – X 1 – X 2

Die ASC-Architektur Scheduler Query-Feedback- Prozess UDI-Prozess

Der Query-Feedback-Prozess Besteht aus zwei Monitoren Ablage aller generierten Daten im QFW Dem QFA als Analysekomponente

Aufbau des Query-Feedback-Warehouse Besteht aus 5 Tabellen Gegliedert in Feedback- und Empfehlungsteil Unabhängige Komponente in DB2

Der QF-Prozess im Detail QF-Analyzer

Gesamtüberblick ASC-Architektur

Datenfluss zum Scheduler Scheduler UDI-Prozess QF-Prozess Runstats Profile Aufruf AA mit einer Tabellenmenge Rückgabe einer Teilmenge Aufruf des QFA Rückgabe einer P-Liste ggf. Aktualisierung Aufruf

Erstellen der Aufrufliste durch den Scheduler Einteilung in fünf Klassen: Useful: 10-50% der Werte der Zeilen verändert Needed: Empfehlung durch QFA Pressing: >50% der Zeilenwerte verändert Urgent: needed + >10% veränderte Zeilenwerte Critical: stark vernachlässigte Tabellen

Der Scheduling Algorithmus // G, P, D, Q, C Listen mit Tabellen, T sei eine Tabelle G := Durch ASC abzuhandelnde Tabellen in erster Iterration P, D, Q, C := {} while(true) { D := AA(G);// Aufruf AA für Tabellen in G Q := QFA();// Starten QFA P := prioritizeMerge(D, Q, C); while (Zeit in aktuellem Wartungsintervall) { T := Pop(P); // T ist top priority Tabelle Runstats+dcr } (G, C) := constructDueTables()//Listen für nächstes //Intervall erstellen warte bis zum nächsten Intervall; }

Was bleibt manuell zu tun? Einstellung der zu überwachenden Tabellen Zeitfenster für das Wartungsintervall angeben (siehe nächste Folie) Festlegen der Menge G für die erste Iteration Angabe der Maximalgröße für das QFW Konfigurieren des Schedulers hinsichtlich Einbindung von AA, QFA oder beidem

Einstellung des Wartungsintervalls / Dialog Festlegen des Zeitpunktes und der Länge Einstellung der Wiederholungsintervalle

Sicherstellen das relevante Statistiken existieren Überwachung der Aktualität Dieser Ohne übermäßigen Anstieg des Rechenaufwands Probleme gelöst? Entlastung beim verwalten eines DBS

Beispiel zur Performance Gegeben: Datenbank mit fünf Tabellen (Car, Owner, Demographics, Accident) 11 Select-Anfragen, nach verschiedenen Schritten (A-E) ausgeführt Schritt C führt neue Datensätze ein Anfrage 10 enthält abhängige Attribute der Tabellen Car und Owner ( Make, Model und City, Country3)

Beispiel zur Performance / Schritt A und B

Beispiel zur Performance / Schritt C - E

??? Self-management 3.Self-healing 2.Self-optimization 1.Self-configuration 4.Self-protection Motivation und Aspekte des Self-management Health Monitor Health Center

Der Health-monitor Serverseitiges Tool Läuft im Hintergrund Überwacht den Zustand von an verschieden Komponenten gemessenen Indikatoren Drei mögliche Meldungen / Indikatoren zustände: Warnung Achtung Alarm Je nach Einstellung Ausführung vordefinierter Aktionen

Das Health-Center Ein grafische Oberfläche zum Health-Monitor Einstellung des Health-Monitor möglich

Danke für Ihre Aufmerksamkeit!