Bisher übernahmen in Viper Werkzeuge wie der "Governor" oder der "Query Patroller" Aufgaben aus dem Workload-Management (WLM). Version 9.5 integriert nun WLM in den Data-Server und erweitert seine Funktionen deutlich. Die beiden genannten Werkzeuge existieren zwar weiterhin, werden von IBM aber künftig nicht länger als strategisch angesehen und deshalb auch nicht mehr ausgebaut.
Die Gründe für die Neugestaltung des Workload-Managements liegen auf der Hand. Leistungsfähigere Hardware (Server) und Betriebssysteme haben dazu geführt, dass Anwendungen zunehmend auf gemeinsame Server statt auf dedizierte Rechner gelegt werden, um etwa Personalkosten im Bereich der Bedienung und Administration einzusparen. Bei einer solchen Konsolidierung sind die unterschiedlichen Anforderungen und Lastprofile der bis dahin getrennt betrachteten Nutzergruppen zu berücksichtigen und zu koordinieren.
Der Ressourcenverbrauch (CPU, Hauptspeicher, I/O) lässt sich nun über Workload-Definitionen und Serviceklassen besser verteilen. Bestimmte Benutzergruppen werden über Workload-Definitionen voneinander getrennt, so dass eine spezifische Ressoucenzuteilung und –überwachung möglich ist. So fällt es leicht, kurzlaufende Transaktionen in einer hochgradig parallel arbeitenden Umgebung von langlaufenden Auswertungen mit unkritischen Antwortzeiten zu trennen, nach unterschiedlichen Kriterien zu überwachen und falls nötig die Langläufer in Warteschlangen zu versetzen.
Die Überwachungsfunktionen (Monitoring) in WLM geben Auskunft über die aktuelle Last oder über aggregierte Lastprofile. Die verdichteten Statistikdaten erlauben zum Beispiel eine Beurteilung der Antwortzeiten eines Systems und den Vergleich mit den Vorgaben eines Service Level Agreements (SLA).
Durch die Integration von WLM in DB2 lässt sich jede Datenbankaktivität ohne explizite Definitionen dem Standard-Workload (SYSDEFAULTUSERWORKLOAD) und der Standard-Serviceklasse (SYSDEFAULTUSERCLASS) zuordnen. Die Definitionen für Workloads, Serviceklassen und weitere zugehörige Objekte werden über die speziellen Erweiterungen bekannter SQL-Befehle getroffen, geändert oder gelöscht (CREATE, ALTER, DROP). Es ist möglich, die Last nach ihrer Herkunft (Anwendung, Benutzer, Clients) zu klassifizieren und Serviceklassen zuzuordnen. Auf diesem Weg kann man bestimmte Anwendungen oder Nutzergruppen in der Ressourcennutzung hervorheben oder beschränken. Eine Alternative ist es, die Last nach ihrer Charakteristik (Lesen, Schreiben, DDL, LOAD) einzuteilen.
Unter Workload wird ein DB2-Objekt verstanden, das Aktivitäten nach ihrer Quelle identifiziert. Als Quellen sind dabei der Anwendungsname, Autorisierungs-IDs, deren Gruppenzugehörigkeit, eine Rolle oder ein Kennzeichen des Clients (User-ID, Workstation-Name, Abrechnungskennung) festlegbar: Die Zuordnung zu einem Workload-Objekt gilt jeweils nur für eine Transaktion und wird zu Beginn jeder Transaktion neu bestimmt. Überschneiden sich die Workload-Definitionen, so dass eine Aktivität zu mehreren Workloads gehören könnte, wird der erstdefinierte gewählt.
Mit Workload-Definitionen lässt sich die Last in verwaltbare Gruppen logisch einteilen und so den Serviceklassen und darüber wiederum den Ressourcen zuteilen. Auf dieser Basis ist es möglich, den Ressourcenverbrauch, die Kosten und die konkurrierende Verarbeitung detaillierter zu kontrollieren. Insbesondere bei Datenbanken mit sehr unterschiedlichen Benutzergruppen ist dies ein wichtiger Vorteil.
Ein anderer Weg, Datenbankaktivitäten zu identifizieren, führt über die Art der Aktivität. Dazu dienen Work-Klassen (WORK CLASSes). Beispiele für solche Aktivitäten sind READ für reine Lese-Aktivitäten (SELECT, XQUERY), WRITE für INSERT, UPDATE, DELETE und MERGE mit eingestreuten SELECTs sowie CALL für Prozeduraufrufe. LOAD für das LOAD-Dienstprogramm und ALL für alle Arten von Aktivitäten gehören ebenfalls dazu. Work-Klassen erlauben auch die vorhersagende Kontrolle der Aktivitäten (predictive) bezogen auf den Ressourcenverbrauch, der bei der Ausführung eines Befehls erwartet wird. Die zwei Kenngrößen sind Estimated Cost als Aufwandsschätzung des DB2-Optimizer und Estimated Cardinality als geschätzte Anzahl von Ergebniszeilen.
Work Action Sets werden dazu benutzt, eine Operation für eine Aktivität zu definieren, basierend auf der Art der Aktivität - im Gegensatz zu Workloads, die nach der Herkunft klassifizieren. So lassen sich Work Action Sets dazu nutzen, Informationen über alle Aktivitäten einer bestimmten Art zu sammeln, einen Schwellenwert für Aktivitäten einer bestimmten Art zu setzen oder Aktivitäten einer Art dadurch zu isolieren, dass sie einer speziellen Serviceklasse zugeordnet werden.
