![Künstler Burgy Zapp [http://burgyzapp.de]](http://newsolutions.de/it/wp-content/uploads//b2_mö_Image-27_Z_fg_o_Negativ-300x300.jpg)
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.
Noch nicht Abonnent? Sonderaktion nutzen.
Ähnliche Artikel:
