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 aber künftig nicht mehr 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 ver-teilen. Bestimmte Benutzergruppen werden über Workload-Definitionen voneinander getrennt, so dass eine spezifische Ressoucenzuteilung und überwachung möglich ist. So fällt es leicht, kurzlaufende Transak-tionen in einer hochgradig parallel arbeitenden Umgebung von langlaufenden Auswertungen mit unkritischen Antwortzei-ten zu trennen, nach unterschiedlichen Kriterien zu überwachen und, falls nötig, die Langläufer in Warteschlangen zu versetzen.

Statistik über Lastprofile

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.

Workload-Objekte

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 Work-load-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.

Die Arbeit mit Work-Klassen

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.

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-Work-load-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 Samm-lung 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 Work-loads, 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 Table-space-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).

Sicherheitserweiterungen

Wie in Version 9 von DB2 for z/OS bereits geschehen, sind nun auch in Version 9.5 von DB2 for LUW die Sicherheitskomponenten Trusted Context und Rolle eingeführt. Eine Datenbankrolle ist eine virtuelle Berechtigungs-ID, die einem Benutzer oder einer Gruppe zugeordnet ist. Sie ist ein Datenbankobjekt, in dem eine oder mehrere Berechtigungen zusammengefasst sind. Damit wird die Verwaltung von Berechtigungen vereinfacht. Es lassen sich für Benutzer mit gleichen Aufgaben Berechtigungsprofile erstellen, ohne dass Benutzergruppen außerhalb von DB2 zum Beispiel im Betriebssystem definiert werden müssen. Ein Trusted Context definiert eine gesicherte Verbindung zwischen einer DB2-Datenbank und einer externen Einheit wie einem Client oder einem Middleware- beziehungsweise Application-Server.

Das Problem bestand bislang darin, dass sich Application-Server mit einer DB2-Datenbank häufig über eine einzige User-ID verbinden, um darunter alle Anforderungen an DB2 zu stellen. Diese User-ID muss sämtliche administrativen Berechtigungen für den Server sowie diejenigen, die für die Ausführung der Anwendungen notwendig sind, besitzen. Die eigentliche Identifikation des Benutzers, der diese Anforderungen stellt, wird dabei nicht an DB2 weitergereicht. Eine Protokollierung oder Überwachung, welcher Benutzer welche Vorgänge in der Datenbank ausführt, ist also nicht möglich. Trusted Context erlaubt es nun, von der initiierenden User-ID des Servers auf die eigentliche User-ID des Endbenutzers umzuschalten.

(ue)