Serviceklassen

Serviceklassen sind DB2-Objekte zur Definition einer Ablaufumgebung. Jedem Workload ist eine Serviceklasse zuzuordnen, über die sich der Ressourcenverbrauch steuern lässt. Zum Beispiel kann die Priorität der Ressourcennutzung als Agent Priority (CPU-Priorität von Agenten in einer Serviceklasse) oder als Prefetch Priority (Zuordnung von Vorauslese-Aktivitäten zu einer von drei Queues - high, medium, low) vorgegeben werden. Unter dem Betriebssystem AIX ist es möglich, die Steuerung an den AIX-Workload-Manager zu übergeben.

Ferner lassen sich Serviceklassen in Unterklassen (Service Subclasses) einteilen. Diese dienen der verfeinerten Zuteilung der Ressourcen. Jede Serviceklasse hat eine Standard-Unterklasse, in der alle Aktivitäten laufen, die nicht einer explizit definierten Serviceklasse zugeordnet werden können.

Zur Kontrolle des Ressourcenverbrauchs sind Schwellenwerte (Thresholds) zu definieren, bei deren Überschreitung eine Aktion ausgelöst wird. Damit lassen sich diejenigen Aktivitäten kontrollieren, die einen erwarteten Ressourcenverbrauch überschreiten. Als Schwellenwerte kann man Zeitvorgaben heranziehen, den Temporärspeicher, die Anzahl an Aktivitäten insgesamt oder je Workload und Serviceklasse, die Anzahl verarbeiteter Zeilen sowie präventiv die Überschreitung der vom Optimizer geschätzten Ausführungskosten. Mögliche Aktionen infolge des Überschreitens eines Schwellenwerts sind: die Sammlung detaillierter Daten anzustoßen, die Ausführung zu beenden oder die Aktivität in eine Warteschlange zu versetzen.

Monitoring und Statistiken

Zur Steuerung des Ressourcenverbrauchs gehört auch dessen Überwachung. Zum einen erlaubt WLM den Zugriff auf die aktuellen Daten wie laufende Workload-Ausprägungen, Aktivitäten einer Serviceklasse oder durchschnittliche Antwortzeiten. Zum anderen ermöglichen drei neue Ereignismonitore die Sammlung detaillierter Informationen nach Workload, Service- oder Work-Klasse sowie von Schwellwertüberschreitungen. Außerdem können aggregierte Statistiken für eine historische Analyse gesammelt werden.

Die drei neuen Ereignismonitore erlauben die weitergehende Aufzeichnung von Informationen über Aktivitäten:

• Der Statistikmonitor ist so ausgelegt, dass er nur minimalen Overhead verursacht. Er sammelt verdichtete Daten über die Aktivitäten und bietet Verteilungsstatistiken (Histogramme) über Kenndaten wie Antwortzeiten oder Ausführungszeiten.

• Der Schwellwertmonitor (Threshold Violation Event Monitor) zeichnet Informationen über Schwellwertüberschreitungen auf.

• Der Aktivitätsmonitor (Activity Event Monitor) sammelt Informationen über individuelle Aktivitäten in einer Serviceklasse, einem Workload in einer Work-Klasse oder über Aktivitäten, die einen Schwellwert überschritten haben.

Die Art und Menge der gesammelten Daten ist konfigurierbar und sollte unter Berücksichtigung von Plattenplatz und Überwachungszeitraum sorgfältig gewählt werden. Die Monitorergebnisse lassen sich in Werkzeugen wie "db2advis" (Design-Advisor / -Assistent) weiterverarbeiten.

Im Rahmen der Echtzeit-Überwachung ist es möglich, über Tabellenfunktionen (table functions) auf interne Informationen des WLM zuzugreifen. Diese enthalten Statistiken über die aktuellen Aktivitäten. Die Statistiken sind auf der Ebene der Workloads, Serviceklassen, Work Action Sets und WLM-Queues abgreifbar. Zusätzlich sind Informationen über laufende Aktivitäten per Tabellenfunktionen auf den Ebenen Workload, Serviceklasse und Aktivitäten verfügbar. Da es in DB2 V9.5 von vornherein die Standard-Workloads und Standard-Serviceklassen gibt, sind über die Tabellenfunktionen auch dann schon Informationen über das aktuelle Geschehen auf dem Server abfragbar, bevor explizit Workloads und Klassen definiert wurden. Hierin ist auch eine Unterstützung für den Entwurf eigener Workload-Objekte und Serviceklassen zu sehen.

Multithread-Architektur

Eine weitere, eher interne Verbesserung betrifft vor allem die Unix- und Linux-Plattformen. Die Konfiguration von DB2 wird durch die Einführung der Multithread-Architektur für Unix und Linux vereinfacht und weiter automatisiert. Bisher nutzte DB2 das Prozessmodell dieser Plattformen, bei dem jeder DB2-Agent als eigener Prozess lief. Version 9.5 kommt nun mit einer neuen Architektur, bei der Threads weniger Speicher und OS-Ressourcen verbrauchen als ein Prozess. Neben einer Reduzierung des Memory-Bedarfs ermöglicht die Umstellung eine vereinfachte Hauptspeicher-Konfiguration und weitere, sich automatisch einstellende Konfigurationsparameter. Nun ist auch auf allen Plattformen die Funktion des Self Tuning Memory (STM) nutzbar. Außerdem wird die Konfiguration von Agents und Prozessen vereinfacht. Insgesamt ergeben sich also neue Möglichkeiten für den Datenbankadministrator, das System automatisch zu optimieren.

Weitere Admin-Erleichterungen

Von Interesse bei der DB-Verwaltung dürfte auch die mit Version 9.5 eingeführte Realtime-Sammlung für Statistiken sein, wobei Tabellenstatistiken automatisch gesammelt werden, wenn man sie für die Optimierung und Ausführung einer Abfrage benötigt. Realtime Statistics werden durch den neuen dynamischen Konfigurationsparameter AUTO_STMT_STATS eingeschaltet und sind Standard für neue Datenbanken. Dies kommt dem Tablespace-Handling zugute, weil es die Wiederbenutzung freien Speichers erleichtert. Mit einer Registry-Variablen lässt sich die maximale Container-Größe für Automatic Storage Tablespaces vorgeben. Bei der Datenkomprimierung von Tabellen wird nun das Komprimierungs-Dictionary automatisch angelegt, wenn ein Schwellwert (1 bis 2 MB) erstmals überschritten wird (Automatic Dictionary Creation = ADC).