Künstler Burgy Zapp

DB2 UDB für iSeries und das Projekt eLiza

 

---

von Kent Milligan

Durch die DB2 UDB Funktionen zur Selbst-Konfiguration, Selbst-Heilung und Selbst-Optimierung erübrigen sich viele manuelle Verwaltungsaufgaben

Viele von uns befassen sich seit geraumer Zeit mit iSeries Systemen und ihren Vorgängern. Wenn man ein Produkt über so lange Zeit einsetzt, betrachtet man leicht einige der besonderen Stärken und Funktionen als selbstverständlich. Die unkomplizierte Handhabung und die geringen Betriebskosten der DB2 Universal Database für iSeries (DB2 UDB) sind zwei dieser Attribute, wobei dem hierin beinhalteten Wettbewerbsvorteil leicht zu wenig Beachtung geschenkt wird. Einfache Bedienbarkeit und geringe administrative Kosten sind Grundvoraussetzungen, um eine relationale Datenbanklösung (RDBMS) als „selbstverwaltendes System“ einstufen zu können. Während DB2 UDB einerseits grafische Schnittstellen zur Vereinfachung administrativer Aufgaben zur Verfügung stellt, automatisiert die unterliegende database-engine bereits heute eine Reihe von Aufgaben, um die Notwendigkeit manueller Eingriffe zu minimieren.

Aus Anlass des von IBM kürzlich angekündigten Projektes eLiza wollen wir uns etwas näher mit den Attributen selbstverwaltender Systeme befassen. Zielsetzung des Projektes eLiza ist eine Selbstverwaltung der e-business Infrastruktur (speziell auf IBM eServern), der Speicher-Ressourcen und der Software, wodurch ein Betrieb der gesamten Umgebung mit nur minimalen manuellen Eingriffen möglich wird. Die nachfolgend näher behandelten DB2 UDB Selbstverwaltungs-Funktionen passen sich hier nahtlos ein.

Selbst-Konfiguration

Zwei Aufgabenbereiche, die bei der Implementierung anderer Datenbankprodukte auf anderen Plattformen zwangsläufig anfallen, entfallen durch die Integration der DB2 UDB engine auf iSeries Systemen.

Erstens muss dort die Installation der eigentlichen Datenbank-Software vorgenommen werden, wobei zuvor überdies durch den Administrator sichergestellt werden muss, dass die zu installierende Version der Datenbank-Software mit der installierten Version des Betriebssystems kompatibel ist. Bei iSeries Systemen erübrigt sich diese Installationsaufgabe, da DB2 UDB bereits vorinstalliert auf jedem System vorhanden ist. Kompatibilitätsprobleme treten hier nicht auf, da die vorinstallierte DB2 UDB Version immer mit der OS/400 Version zusammenpasst.

Zweitens erübrigt sich beim Einsatz der DB2 UDB die manuelle Speicherzuordnung für Datenbankobjekte (wie z.B. Tabellen und Indizes). So ist hier beispielsweise lediglich die SQL-Anweisung Create Table erforderlich, um eine Tabelle incl. der Zuordnung entsprechender Speicher-Ressourcen auf einem iSeries System zu erstellen. Andere Datenbankprodukte hingegen erfordern die manuelle Zuordnung von Speicher-Ressourcen (z.B. für eine Tabelle), bevor eine Create Table Anweisung ausgeführt werden kann. Beim Hinzufügen von Daten in Tabellen- und Index-Objekte muss bei einigen Datenbanken fortwährend überprüft werden, ob eine (manuelle) Erhöhung der ursprünglich zugeordneten Speicher-Ressourcen erforderlich wird. Im Gegensatz hierzu ordnet DB2 UDB Datenbank-Objekten automatisch zusätzlich benötigte Speicher-Ressourcen zu, ohne dass hierzu ein Benutzereingriff erforderlich wird. DB2 UDB geht noch einen Schritt weiter, indem der Speicherbereich für ein einzelnes Datenbank-Objekt auf mehrere Plattenlaufwerke verteilt angelegt wird, was letztlich eine übermäßige Belastung einzelner Plattenarme vermeidet. Auf anderen Systemplattformen ist es die Aufgabe des Datenbank-Administrators, die Datenbank manuell so zu konfigurieren, dass eine gleichmäßige Verteilung der Daten auf mehrere Plattenlaufwerke erreicht wird.

Die für ODBC und JDBC middleware Zugriffe erforderlichen Datenbank-Kommunikations-Server werden auf iSeries Systemen bei der Aktivierung von TCP/IP automatisch gestartet. Auf diese Weise führt das System einen weiteren Konfigurations-Schritt eigenständig durch. Überdies fragt DB2 UDB die iSeries Einstellungen zur nationalen Sprachunterstützung (Englisch, Französisch etc.) selbständig ab und nimmt automatisch die erforderlichen Anpassungen (z.B. Zeichensatz, Datumsformat) vor, die für die jeweils aktuelle Spracheinstellung Gültigkeit haben.

Selbst-Heilung

Bei Datenveränderungen oder Löschungen in einer Datenbank werden auch die zugehörigen Indizes angepasst, um die Veränderungen in den Daten reflektieren zu können. Die Reihenfolge, in der Daten hinzugefügt oder verändert werden, kann zu einem Ungleichgewicht in der darunter liegenden Datenstruktur führen (die üblicherweise auf einem binary tree basiert). Auf anderen Systemen ist der Administrator genötigt, dieses Gleichgewicht manuell durch Reorganisation der Datenbank wiederherzustellen. Auf iSeries Systemen hingegen überwacht die database engine die basierende Indexstruktur fortwährend und stellt – sofern erforderlich – intern das Gleichgewicht wieder her. Dies macht ein Herunterfahren des Systems zur Index-Reorganisation überflüssig und erlaubt ununterbrochenes Betreiben der Anwendungen.

Datenbank-Wiederherstellung wird z.B. auch nach einer abnormalen Systembeendigung erforderlich. Obwohl Systemfehler auf iSeries System eher eine Seltenheit sind, verfügt DB2 UDB über eine vollständige Ausstattung, um solche Situationen zu meistern. Während des Neustarts nach einem Systemabbruch stellt DB2 UDB in der IPL Phase einen konsistenten Stand der Datenbank wieder her.

Um diese Datenbankwiederherstellung nach einer abnormalen Systembeendigung zu beschleunigen, bieten iSeries Systeme zusätzlich die Möglichkeit des Schutzes von Zugriffspfaden unter Systemverwaltung (system-managed access path protection – SMAPP). Zugriffspfade (z.B. Indizes, logische Dateien mit Schlüsseln) bedürfen zusätzlichen Schutzes. Wenn eine abnormale Systembeendigung zu einem Zeitpunkt eintritt, zu dem noch nicht alle Zugriffspfadmodifikationen auf die Magnetplatte zurückgeschrieben worden sind, wird nach dem Neustart des Systems ein vollständiger Neuaufbau der betroffenen Zugriffspfade erforderlich. Diese Wiederherstellung kann unter Umständen erhebliche Zeit in Anspruch nehmen, wenn z.B. einige Indizes über sehr große Tabellen (oder physische Dateien) betroffen sind. Obwohl die Möglichkeit besteht, einen vollständigen Neuaufbau von Zugriffspfaden im Fehlerfall durch explizite Journalisierung zu vermeiden, deckt dies die Anforderungen eines selbstverwaltenden Systems noch nicht ab.

Mit der Aktivierung von SMAPP übernimmt die database engine selektiv eine automatische Journalisierung nur jener Zugriffspfade, die sie für schützenswert oder einem Risiko unterliegend erachtet. Diese Risikoeinschätzung basiert auf einem vom Administrator vorgegebenen Wert, der mit der CL-Anweisung EDTRCYAP (Edit Recovery for Access Paths) gesetzt wird. Dieser Wert legt die Obergrenze für den Zeitraum fest, den die Zugriffspfadwiederherstellung bei einem System-Neustart (IPL) in Anspruch nehmen sollte. Um diese Entscheidung umzusetzen, überwacht die database engine fortwährend die Veränderungen aller Indizes auf dem System. Die database engine schützt alle Zugriffspfade mit hohem Veränderungsvolumen, die nicht bereits expliziter Journalisierung unterliegen, sofern ihre Größe den durch Journalisierung zusätzlich entstehenden Aufwand zur Ausführungszeit rechtfertigt. Das System schützt somit automatisch einem gewissen Risiko unterliegende Zugriffspfade, anstatt sich hier auf manuelle, explizite Journalisierung durch den Benutzer zu verlassen.

Journalisierung ist auf iSeries Systemen die primäre Methode, eine sichere und schnelle Datenbank-Wiederherstellung im Falle abnormaler Systembeendigung zu gewährleisten. iSeries Systeme verfügen mit den systemverwalteten Journal- Empfängern (system-managed journal receivers) über eine weitere Funktion zur Selbst-Heilung, die Verzögerungen in der Datenbankverarbeitung vermeidet und administrative Erfordernisse bei der Journalisierung senkt.

Ein Journal-Empfänger ist ein Objekt, das die Veränderungen in einer Datenbank protokolliert. Mit steigender Anzahl von Veränderungen in der Datenbank nimmt auch die Größe des Journal-Empfänger-Objekts zu. Wenn der Journal-Empfänger sich der maximalen Größe für Empfänger nähert, muss der Administrator dem Journal ein neues Empfänger-Objekt zuordnen. Geschieht dies nicht rechtzeitig, führt das zu einer Fehlerbedingung, die die weitere Datenbankverarbeitung stoppt. Die Angabe der Option für systemgesteuerte Verwaltung von Journal-Empfängern (MNGRCVR(*SYSTEM)) in den CL-Anweisungen CRTJRN (Create Journal) und CHGJRN (Change Journal) vermeidet diese Fehlerbedingung. Nähert sich ein Journal-Empfänger seiner maximal zulässigen Größe, wird dem Journal vom System automatisch ein neuer Journal-Empfänger zugeordnet. Eingriffe des Administrators zur Prüfung oder Zuordnung von neuen Journal-Empfängern sind somit nicht länger erforderlich.

Selbst-Optimierung

Query Optimizer zählt zu den Komponenten der Selbst-Optimierung der DB2 UDB engine. Die Integration der Kosten-Algorithmen des iSeries Query Optimizer erlaubt eine automatische Anpassung an Veränderungen der System-Ressourcen. Auf diese Weise ist die DB2 UDB engine in der Lage, neue System-Ressourcen, wie z.B. zusätzliche Prozessorleistung oder zusätzliche Speicherkapazität unmittelbar in vollem Umfang zu nutzen, um so die größtmögliche Performance zu erzielen. So erkennt z.B. der DB2 Optimizer bei Nutzung der iSeries Fähigkeiten zur Bereitstellung zusätzlicher Prozessoren (capacity on demand) zusätzlich zur Verfügung stehende Leistungs-Kapazität und versucht, sie sofort in vollem Umfang zu nutzen.

Zur Nutzung der Vorteile aus aktuellen Datenbankveränderungen (neue Indizes) oder Systemveränderungen (zusätzliche Speicher-Ressourcen) erfordern viele Datenbank-Implementierungen die Durchführung einer bind-Operation, um die Anpassung des Zugriffsplans für eine SQL-Anweisung zu erzwingen. Üblicherweise werden bind-Operationen bei höheren Programmiersprachen mit eingebetteten SQL-Anweisungen (embedded SQL) erforderlich. DB2 UDB benötigt hierzu keine bind-Utilities oder bind-Operationen, da die zuvor beschriebenen Veränderungen automatisch erkannt und Zugriffspläne automatisch angepasst werden, sofern dies erforderlich ist. Diese Vorgehensweise wird gelegentlich als late binding oder automatic binding bezeichnet und wird auf iSeries Systemen sowohl für embedded SQL als auch für dynamic SQL (z.B. ODBC, JDBC) eingesetzt. DB2 UDB bedient sich allerdings vor der Veränderung von Zugriffsplänen einer gewissen Intelligenz, um zu vermeiden, dass diese Zugriffspläne ständig verändert werden. Da davon ausgegangen werden kann, dass z.B. die Veränderung eines Speicher-Pools von 1,2 GB auf 1,4 GB nicht zu signifikanten Performance-Verbesserungen bei der Ausführung einer SQL-Anweisung führen wird, würde DB2 UDB in diesem Fall keine Änderungen an existierenden Zugriffsplänen vornehmen.

Bei der Ausführung einer SQL-Anweisung auf einem iSeries System wird sowohl ein Zugriffsplan als auch ein offener Datenpfad (open data path – ODP) benötigt. Der Zugriffsplan enthält Informationen über die Implementierung der SQL-Anweisung (z.B. table scan), der ODP ist die Schnittstelle zum Transport der Daten. Die iSeries SQL engine versucht automatisch, die Performance häufig ausgeführter SQL-Anweisungen durch Zwischenspeicherung (caching) von Zugriffsplan und ODP zu steigern. Anstelle System-Ressourcen einzusetzen, um Zugriffsplan und ODP bei wiederholter Ausführung erneut aufzubauen, werden die zwischengespeicherten Objekte verwendet. Offene Datenpfade werden auf Job-Ebene (Verbindungs-Ebene) zwischengespeichert. Zugriffspläne für dynamische SQL-Schnittstellen werden auf Job- (Verbindungs-) Ebene und auf System-Ebene zwischengespeichert. Die zur Zwischenspeicherung verwendeten Speicherbereiche werden von DB2 UDB automatisch zugeordnet und bekannt gemacht. Die meisten anderen Datenbankimplementierungen erfordern eine manuelle Zuweisung dieser zur Zwischenspeicherung benötigten Speicherbereiche durch den Datenbank-Administrator.

Die Erzeugung und Verwaltung von Statistiken ist ein weiterer Aufgabenbereich, den DB2 UDB zur Steigerung der Datenbank-Performance automatisch durchführt. Die Erstellung und Aktualisierung von Statistiken erfordert bei den meisten anderen Datenbankimplementierungen manuelle Eingriffe. Kostenbasierte Optimizer verwenden Tabellen- und Indexstatistiken als Grundlage für intelligente Entscheidungen, um den schnellsten und somit günstigsten Weg zur Implementierung einer Query ermitteln zu können. Cardinality (Anzahl unterschiedlicher Werte) ist eine Statistik, die der Query Optimizer als Grundlage zur besseren Einschätzung von Daten einsetzt. Existiert z.B. ein Index über die Spalte „Staat“, kann der Query Optimizer die Cardinality Statistik verwenden, um festzustellen, wie viele unterschiedliche Staaten in der Datenbank gespeichert sind. Abhängig davon, ob nun alle 50 Staaten oder eine kleinere Menge (z.B. fünf) in der Datenbank vorkommen, kann diese Information den Query Optimizer beeinflussen, die Tabellenspalte in spezieller Weise zu durchsuchen.

DB2 UDB ist die einzige Datenbankimplementierung, die bei Hinzufügungen, Änderungen und Löschungen von Sätzen in der Datenbank automatisch alle aktuellen Tabellen- und Indexstatistiken pflegt. Andere Datenbankimplementierungen vertrauen hier auf diverse Dienstprogramme zum Aufbau und zur Pflege von Statistikwerten. Versäumt ein Administrator, diese Statistiken zu erstellen oder nimmt er die Pflege nur selten vor, kann die Performance signifikant beeinträchtigt werden. In einem solchen Fall trifft der Query Optimizer zwangsläufig Entscheidungen, die auf veralteten Informationen basieren. Enthielt die Spalte „Staat“ z.B. vor sechs Monaten nur fünf unterschiedliche Werte, mittlerweile jedoch vierzig, kann dies leicht zu einer falschen Entscheidung des Optimizers bei der Wahl der Implementierung führen. Die kontinuierliche Pflege der Statistiken durch DB2 UDB stellt sicher, dass der Query Optimizer – ohne Unterstützung durch einen Administrator – immer über aktuelle Informationen verfügt.

Wie bereits zuvor schon erwähnt, ist DB2 UDB in der Lage, zur Steigerung der Performance automatisch auf veränderte System-Ressourcen, wie z.B. Bereitstellung eines zusätzlichen Prozessors, zu reagieren. Weiterhin kann DB2 UDB dynamisch entscheiden, auf welche Weise eine existierende System-Ressource, wie z.B. Speicher, zur Steigerung der Performance eingesetzt wird. Diese selbst-optimierende Funktion ist unter der Bezeichnung expert cache bekannt. Diese Funktion lässt sich durch Änderung der paging Option für einen Speicherpool von *FIXED auf *CALC(CHGSHGRPOOL…PAGING(*CALC) aktivieren. Wurde die Option expert cache aktiviert, protokolliert und analysiert die DB2 UDB engine die Zugriffe auf Datenbankobjekte. Wird dabei z.B. erkannt, dass alle Sätze einer Tabelle in sequentieller Folge gelesen werden sollen, wird die interne Blockungsgröße erhöht, um mit einem Zugriff größere Teile der Tabelle in den Speicher übertragen zu können und damit letztlich die Gesamtanzahl der Plattenzugriffe zu reduzieren.

Die DB2 UDB engine ist ebenfalls in der Lage zu erkennen, wenn Benutzer öfter auf einen bestimmten Bereich innerhalb einer Tabelle zugreifen. Wird eine Häufung solcher Zugriffe erkannt, werden die Speicherseiten mit diesen Sätzen länger im Speicher vorgehalten. Auch diese Aktion reduziert die Anzahl der Plattenzugriffe, was gewöhnlich wiederum zu einer gesteigerten Performance führt. Die einzige administrative Anforderung hierfür ist die Aktivierung des expert cache – DB2 UDB unternimmt daraufhin eine Analyse und Anpassung der Datenbank I/O Muster zur Steigerung der Gesamt-Performance des iSeries Systems.

DB2 UDB übertrifft den Rest

DB2 UDB unterscheidet sich von anderen Datenbank-Servern durch eine Architektur und ein Design, das eher um sich selbst bemüht ist, als auf den Glanz aufwendiger grafischer Schnittstellen zu bauen. Dieser Artikel soll Ihnen ein neues Gefühl von Anerkennung für die Arbeit geben, die DB2 UDB im Hintergrund für Sie erledigt. Genau dieses Stück Arbeit macht einen großen Teil des IBM eLiza Projektes aus. DB2 UDB bringt durch die unterliegenden Strukturen der iSeries Systeme einen gewaltigen Vorteil für die Unterstützung des eLiza Projektes mit sich. IBM plant überdies für die Zukunft, weitere selbstkonfigurierende, selbstheilende und selbstoptimierende DB2 UDB Funktionen auf iSeries Systemen zu implementieren.

Weitere Informationen

Im Oktober 2002 haben wir bereits im Internet veröffentlicht: „Projekt eLiza Initiative“ und „Zukünftige DB2 eLiza Erweiterungen“