Home ORDIX AG             Dienstleistung             Trainingsshop    Kunden / Referenzen Aktuelles    Kontakt
Home  Pfeil  ORDIX News  Pfeil  3/2004  Pfeil  
suche: 

ORDIX News Archiv

Das IT-Magazin der ORDIX AG mit Fachbeiträgen zu Datenbanken, Unix und Java/XML.

Neue Reihe DB2 (Teil I):

DB2 UDB "Stinger" Beta

Seit Mai 2004 ist die neueste Version von DB2, die im Moment noch den Namen Stinger trägt, verfügbar. Als Teilnehmer am "DB2 Stinger Open Beta Program" haben wir die neue Version ausgiebig getestet und stellen in diesem Artikel die wichtigsten Neuerungen vor.

Die meisten Neuerungen gab es in den Bereichen Datenbankverwaltung, Performance, Anwendungsentwicklung, Hochverfügbarkeit und Sicherheit.

Datenbankadministration durch Self-Management

Eine Datenbank sieht, hört, schmeckt, riecht und fühlt man nicht. Sie ist einfach da, verrichtet ihre Arbeit und muss auch nicht administriert werden. Solche Versprechungen haben in der Vergangenheit schon viele Hersteller gemacht. In der Realität hat sich das bis heute allerdings noch nicht widergespiegelt.

IBM möchte diesem Ziel mit der neuen Version von DB2 wohl wieder etwas näher kommen und hat einige neue Werkzeuge entwickelt, die das Administrieren einer DB2 Datenbank vereinfachen und automatisieren sollen.

Der DB2 Design Advisor analysiert eine vorhandene Datenbank und gibt Hinweise zu Indizes, Materialized Query Tables (MQT), Multidimensional Clustering Tables (MDC) und der Partitionierung von Tabellen. Als Basis der Analyse dienen vom Benutzer zu definierende SQL-Statements, die dann gegenüber der Datenbank ausgeführt werden.

Neu: Der "Maintenance Wizard"

Um den Datenbankadministrator von periodischen Wartungsarbeiten zu befreien, gibt es jetzt den "Configure automatic maintenance wizard" ("Automatische Verwaltung konfigurieren"). In diesem Wizard können Wartungsfenster definiert werden, in denen es möglich ist, Wartungsarbeiten wie Sicherungen (BACKUP), Defragmentierungen (REORG) und das Aktualisieren der Statistiken (RUNSTAT) durchzuführen, ohne den laufenden Betrieb zu stören.

Ob es nötig ist, die Kommandos in den definierten Wartungsfenstern auch wirklich auszuführen, wird von DB2 ermittelt. Dadurch werden die entsprechenden Kommandos nur gestartet, wenn es wirklich notwendig ist.

Backup und Recovery

Im Bereich Backup und Recovery gibt es dazu eine weitere Neuerung. So werden die Anzahl der verwendeten Puffer, der Wert für die Parallelität und die Größe der verwendeten Puffer ganz automatisch von den Kommandos BACKUP DATABASE und RESTORE DATABASE ermittelt.

Neben den Verbesserungen im Bereich der Performance gibt es noch weitere Neuheiten beim Backup und Recovery. Mit der Option INCLUDE LOGS ist es möglich, bei einer Online-Sicherung die zum Wiederherstellen der Datenbank benötigten Logdateien in das Sicherungsimage zu integrieren.

Zu den bekannten Kommandos RESTORE DATABASE und ROLLFORWARD DATABASE kommt jetzt das Kommando RECOVER DATABASE hinzu. Mit diesem Kommando besteht die Möglichkeit, das Zurücksichern der Tablespaces und das Nachfahren der Logfiles in einem Schritt durchzuführen. Dabei kann sowohl ein Point in Time als auch ein Recovery bis zum Ende der Logfiles durchgeführt werden.

Diagnose und Analyse

Für die Diagnose und Analyse gibt es das neue Tool db2pd. Dabei handelt es sich im Prinzip um das Informix onstat Kommando für DB2, was man nun ganz besonders auch an den Ausgaben der beiden Programme sieht.

Mit db2pd gibt es nun die Möglichkeit, Informationen über Sperren, Bufferpools, Tablespaces, Container, dynamische SQL Kommandos, Anwendungen, Speicherbereiche, Transaktionen und Logdateien abzurufen, ohne dabei Snapshots verwenden zu müssen. Wie die beiden Abbildungen 1 und 2 zeigen, sind die Ausgaben von db2pd und onstat ziemlich ähnlich.

Abb. 1: Ausgabe von db2pd –tablespaces.

Abb. 2: Die Ausgabe von onstat –d im Vergleich zu db2pd.

Bei der Bedienung ist db2pd im Vergleich zu onstat etwas unhandlicher, da die Optionen als vollständige Worte und nicht wie bei onstat durch einen Buchstaben angegeben werden. Mit diesem Tool ist wohl der erste sichtbare Schritt zur Verschmelzung der beiden IBM Datenbanken erfolgt.

Schnellerer Zugriff durch bessere Statistiken

Um immer den besten Zugriffsplan zu erstellen, ist es notwendig, die Statistiken einer Datenbank aktuell zu halten. Da RUNSTATS, welches die Statistiken aktualisiert, sehr viele Systemressourcen, wie CPU und Platten benötigt, konnte man in der Vergangenheit dieses Tool nur starten, wenn wenig Last auf der Datenbank vorhanden war.

Durch das so genannte "Throttling" passt sich nun RUNSTATS der aktuellen Lastsituation des Rechners automatisch an. Wenn der Rechner unter Last steht, arbeitet RUNSTATS weniger aggressiv und nimmt nicht so viele Ressourcen in Anspruch. Sind hingegen mehr Ressourcen auf dem Rechner verfügbar, werden diese von RUNSTATS auch genutzt.

Weiterhin kann die Dauer eines RUNSTATS-Laufes über die Option TABLESAMPLE verkürzt werden. Die Statistiken werden dann nicht auf Basis aller Sätze einer Tabelle ermittelt, sondern nur anhand einiger Stichproben.

Mit dem "DB2 automatic statistic profiling" besteht die Möglichkeit, die Datenbank selbstständig das RUNSTATS Kommando ausführen zu lassen, wenn dies aufgrund von entsprechenden Aktivitäten auf der Datenbank notwendig ist. Dazu sammelt DB2 Informationen über die Aktivitäten der Datenbank. Aufgrund dieser Daten wird ein Statistikprofil erzeugt. Dadurch ist es DB2 möglich, das Aktualisieren der Statistiken nur für die Tabellen durchzuführen, für die es auch notwendig ist.

Erweiterungen für die Anwendungsentwicklung

Viele Neuerungen von DB2 "Stinger" sind im Bereich der Anwendungsentwicklung zu finden. So wurde z. B. die Integration in Microsoft .NET und J2EE/WebSphere erweitert. Für das Microsoft Visual Studio .NET gibt es DB2 Add-ins. Für die Java Entwicklung wird jetzt auch JDK 1.4 als Entwicklungsumgebung unterstützt.

Hochverfügbarkeitsreplikation mit Informix Technologie

Nach dem Prinzip der Informix Hochverfügbarkeitsreplikation (HDR) hat IBM für DB2 die High Availability Disaster Recovery (HADR) realisiert. Mit dieser neuen Art der Replikation werden alle Änderungen auf dem primären Datenbankserver und auf dem sekundären Datenbankserver nachgefahren.

Damit ist es möglich, beim Ausfall des primären Datenbankservers innerhalb von wenigen Sekunden mit dem aktuellen Datenbestand auf dem sekundären System weiter zu arbeiten. Die Aktualität der Daten auf dem sekundären Datenbankserver kann über den Synchronisationsmodus gesteuert werden (synchron, fast synchron und asynchron). Um auf der Clientseite die Ausfallzeit nach dem Abbruch der Verbindung zum primären System zu minimieren, kann ein automatisches Client Rerouting verwendet werden, welches die Verbindung zum sekundären System herstellt.

SQL Erweiterungen

Viele Neuerungen gibt es auch im Sprachumfang von SQL. Das ALTER TABLE Kommando wurde dahingehend erweitert, dass Defaultwerte für Spalten im Nachhinein geändert werden können. Auch die Definition von generierten Spalten kann jetzt mit dem Kommando geändert werden.

Mit dem SET CURRENT LOCK TIMEOUT Kommando ist es jetzt möglich, das Verhalten einer Session beim Warten auf eine Sperre einzustellen (der geübte Informix Nutzer erkennt die lange bekannten Möglichkeiten des "SET LOCK MODE "). Als mögliche Optionen stehen dabei zur Verfügung:

Erweiterungen gab es auch im Alter Table Notebook (siehe Abbildung 3). Damit sind jetzt folgende Änderungen möglich:

Abb. 3: Alter Table Notebook mit neuen Funktionen.

Resümee

Ob die Innovation im Bereich des Self-Managements ein wirklicher Fortschritt ist, muss die neue DB2 Version im praktischen Einsatz erst beweisen. Ansonsten erreicht DB2 mit "Stinger" den aktuellen technologischen Stand, was sicherlich auch ein Verdienst der gekauften Informix Technologie ist.

Holger Demuth (info@ordix.de).