DB2 V6R1 enthält zahlreiche Funktionen, mit denen sich neue Lösungen schnell und einfach erstellen lassen
von Kent Milligan
Über den Autor
Kent Milligan kmill (ät) us.ibm (punkt) com ist Senior DB2 for i5/OS Specialist im IBM ISV Enablement Team für System i.
Übersetzung
Übersetzt und für den deutschsprachigen Markt überarbeitet von Joachim Riener.
In den sich heute ständig verändernden geschäftlichen Umfeldern ist es von entscheidender Bedeutung, der Konkurrenz einen Schritt voraus zu sein. Aus IT- und Datenbankperspektive bedeutet dies, in der Lage zu sein, Unternehmensdaten auf neue, intelligente Weise abzufragen und darzustellen – und dies so kurzfristig wie möglich. Die Verbesserungen in DB2 für i5/OS V6R1 beinhalten diverse neue Funktionen, die der Datenbank eine gesteigerte Performance verleihen und eine schnelle und einfache Bereitstellung neuer Lösungen ermöglichen. In Teil 1 dieses Artikels – erschienen in der Ausgabe Juni 2008 – wurden Neuerungen und Verbesserungen bei der Anwendungsentwicklung vorgestellt. Der heutige 2. Teil behandelt die Bereiche Portabilität und Performance.
Ein großer Schritt nach vorne bei der Portabilität
IBM sieht sich zunehmend mit einem starken Interesse von Software-Anbietern konfrontiert, die ihre Anwendungen auf i5/OS portieren möchten. Diese Portierungs-Aktivitäten werden in erster Linie von Software-Anbietern betrieben, die sich den System i Markt erschließen wollen, aber auch von Kunden, die sich eine Verfügbarkeit der aktuellsten Anwendungen und Tools unter i5/OS wünschen. Um diese Portierungs-Projekte zu beschleunigen, hat IBM in V6R1 die SQL-Funktionalität von DB2 für i5/OS deutlich gesteigert.
Sowohl Microsoft SQL Server als auch MySQL Tabellen enthalten die Unterstützung für eine verborgene oder automatische Spalte, die einen Zeitstempel enthält. Die Emulation dieser Funktionen war bei der Portierung auf DB2 für i5/OS vor V6R1 mit einigen Schwierigkeiten verbunden. Enthält eine Tabelle in einem dieser Datenbankprodukte eine Zeitstempelspalte, aktualisiert die Datenbank-Engine diesen Zeitstempel jedes Mal, wenn eine Zeile eingefügt oder verändert wird. Diese Automatik bietet in Anwendungen einen einfachen Mechanismus, mit dessen Hilfe sich feststellen lässt, ob an einem zuvor gelesenen Datensatz Veränderungen vorgenommen wurden, bevor die Anwendung versucht, diesen Satz wieder zurückzuschreiben. Um eventuelle Veränderungen festzustellen, muss in den Anwendungen einfach nur der Zeitstempel des Lesezeitpunktes mit dem aktuellen Zeitstempel des Datensatzes verglichen werden. Dieser Zeitstempelvergleich ist von zentraler Wichtigkeit für Anwendungen, die einen so genannten optimistischen Locking-Ansatz verwenden. Dieser Zeitvergleich lässt sich nun unter V6R1 mit der neuen DB2 Unterstützung für eine verborgene Zeitstempelspalte auf einfache Weise implementieren. Abbildung 4a zeigt, wie eine verborgene Zeitstempelspalte definiert wird und wie die Verarbeitung während einer typischen I/O Operation abläuft.
Das Statement CREATE TABLE zeigt die neue Syntax zum Verbergen einer Spalte mit der Klausel IMPLICITLY HIDDEN in der Spaltendefinition ticket_ts. Diese Klausel legt fest, dass die Spalte bei keinem SQL Statement sichtbar ist, es sei denn, es wird – wie in Abbildung 4b dargestellt – explizit namentlich Bezug darauf genommen. Abbildung 4b enthält die Ausgabe für das erste SELECT Statement in Abbildung 4a (z. B. SELECT * FROM tickets). Die Spalte ticket_ts ist hier nicht Bestandteil des Ergebnisses, weil im SELECT Statement nicht explizit Bezug auf die Spalte genommen wurde.
Die Klausel FOR EACH ROW ON UPDATE AS ROW CHANGES TIMESTAMP bewirkt, dass DB2 den Wert in der Spalte ticket_ts immer dann aktualisiert, wenn eine Zeile eingefügt oder verändert wird. Abbildung 4c zeigt das Ergebnis des letzten SELECT Statements aus Abbildung 4a. Hier wird die Spalte ticket_ts zusammen mit den anderen nicht verdeckten Spalten explizit aus der Tabelle Tickets ausgewählt. Obwohl die INSERT und UPDATE Statements in Abbildung 4a keinerlei Referenzen zu der Spalte ticket_ts enthalten, werden dennoch die Werte automatisch von DB2 zugewiesen und verändert.
Mit der Verfügbarkeit diverser neuer Datentypen lassen sich die Tabellendefinitionen leichter auf DB2 für i5/OS portieren. Die Datentypen für nationale Zeichensätze (z. B. NCHAR, NVCHAR und NCLOB) bieten eine Standardmöglichkeit zur Definition von Unicode-Spalten mit UTF-16 Kodierung. Aus Kompatibilitätsgründen mit den anderen DB2 Produkten wurde der neue dezimale Gleitkomma-Datentyp DECFLOAT hinzugefügt. DECFLOAT kombiniert die Attribute dezimal und Gleitkomma mit erweiterter Genauigkeit.
Auch die Portierung von für andere Mitglieder der DB2 Familie entwickelten Datenbanken und Anwendungen wird durch Unterstützung der Full Outer Join Syntax und eine neue DB2 für i5/OS Funktion vereinfacht, die nicht unterstützte Syntax ignoriert. SQL Scripts für andere DB2 Datenbanken enthalten in den SQL Datendefinitions-Statements oft Konfigurations-Syntax der unteren Ebene (wie z. B. Optionen für den Tabellenplatz). Bisher verhinderte diese Syntax eine Ausführung der Scripts unter DB2 für i5/OS so lange, bis die nicht unterstützte Syntax aus den Datenbank-Scripts entfernt worden war. Ab V6R1 ignoriert DB2 für i5/OS nun Syntax und Optionen, die aktuell nicht unterstützt werden und für die auch zukünftig keine Unterstützung vorgesehen ist. Dies ist möglich, weil die DB2 für i5/OS Datenbank-Engine und das Betriebssystem viele Datenbank-Administrationsaufgaben der unteren Ebene automatisch erledigen, die bei den anderen DB2 Produkten eine manuelle Konfiguration erfordern. Abbildung 5 zeigt Syntaxbeispiele, bei denen die nicht unterstützte Syntax rot hervorgehoben ist. Es wird lediglich eine SQL Warnung ausgegeben, um auf die in DB2 für i5/OS nicht unterstützte Syntax hinzuweisen. Die Portierung wird beschleunigt, da nun ein Entfernen nicht unterstützter Syntax aus den Datenbank-Scripts nicht mehr erforderlich ist.
Noch nicht Abonnent? Sonderaktion nutzen.
Ähnliche Artikel:
