DB2 V6R1 enthält zahlreiche Funktionen, mit denen sich neue Lösungen schnell und einfach erstellen lassen

von Kent Milligan

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.

Bei Portierungen auf DB2 für i5/OS werden Sie feststellen, dass Anwendungen häufig SQL CLI als Programmierschnittstelle für den Datenzugriff verwenden. Die Portabilität solcher SQL CLI Anwendungen wird mit V6R1 durch Unterstützung der CLI wide-character API ermöglicht. Die CLI wide-character Funktionen werden in Anwendungen eingesetzt, die Unicode oder Double-Byte Zeichensätze verwenden.

Ein großer Schritt nach vorne bei der Performance

Die mit V5R2 eingeführte SQL Query Engine (SQE) war eine der wesentlichsten IBM Initiativen, durch die sich die SQL Performance von DB2 für i5/OS in neue Höhen aufgeschwungen hat. Diese Performance-Steigerung für SQL Aufgaben setzt sich in V6R1 mit der Eliminierung der beiden hauptsächlichen Hinderungsgründe für den Einsatz von SQE fort: Funktionen, die auf Übersetzungsfunktionen der unteren Ebene beruhen sowie besondere nationalsprachliche Sortierreihenfolgen (NLSS – National Language Sort Sequences). Die Übersetzungsfähigkeiten der unteren Ebene werden von häufig eingesetzten SQL BiFs (Built-In Functions) wie beispielsweise Upper und Lower verwandt. Die NLSS Unterstützung von i5/OS wird häufig in überseeischen Märkten genutzt, wo in Anwendungen oft eine Sortierfolge gefordert wird, die anstelle der standardmäßigen (eng an das englische Alphabet angelehnten) Sortierfolge *HEX den lokalen Spracherfordernissen folgt. Da diese beiden Funktionen nun von SQE unterstützt werden, verbleiben als häufigste Hinderungsgründe für den Einsatz von SQE noch:

• select/omit und abgeleitete logische Dateien, die in der zugrunde liegenden Tabelle definiert sind
• logische Dateireferenzen in einer FROM Klausel
• SQL-fremde Schnittstellen (z. B. OPNQRYF, Query/400)

Anmerkung: Da SQL die strategische Schnittstelle für den System i Datenzugriff und überdies Industriestandard ist, nehmen SQL-fremde Schnittstellen aus Sicht der SQE nur eine sehr geringe Priorität ein. Die SQE wird SQL-basierte Schnittstellen nur noch für absehbare Zeit unterstützen.

Um die Nutzung der SQE weiter zu fördern, hat IBM mit V6R1weitere Veränderungen vorgenommen, so hat z. B. der Ignore_Derived_Index Parameter QAQQINI einen neuen Standardwert erhalten. Dieser Parameter wurde mit V5R3 hinzugefügt, damit die SQE in Umgebungen verwendet werden konnte, in denen SQL Statements sich auf DDS-erstellte DB2 Objekte beziehen. Vor V6R1 wurde standardmäßig immer dann, wenn während des Query Optmierungsprozesses eine abgeleitete logische Datei erkannt wurde, die Verarbeitung der SQL Requests an die CQE (Classic Query Engine) weitergeleitet. Dieses Standardverhalten lässt sich durch Setzen des Parameters QAQQINI auf *YES ändern. Durch diesen Wert wird der SQE Query Optimizer veranlasst, während der Optimierung jegliche mit Schlüssel versehene logische Datei zu ignorieren, die select/omit Kriterien oder Schlüsselfeldableitungen enthält. Mit V6R1 lautet der Standardwert für den Parameters QAQQINI nun *YES anstelle von *NO (in früheren Releases).

SQL Query Engine Verbesserungen

Obwohl das Ausräumen von Hindernissen für den SQE Einsatz wichtig ist, sind die wohl interessantesten V6R1 Verbesserungen die neuen Möglichkeiten, die sich der erweiterbaren SQE Architektur bedienen. Ein ausgezeichnetes Beispiel hierfür ist der erste Schritt von DB2 für i5/OS in Richtung selbst lernender Query Optimierung. Ein selbst lernender Query Optimizer ist in der Lage, einen schlecht performenden Query-Plan zu analysieren, den internen Algorithmus dynamisch – basierend auf gewonnenen Erkenntnissen – anzupassen und für zukünftige Ausführungen einen besseren Query-Plan zu selektieren. In V6R1 analysiert der SQE Optimizer automatisch schlecht performende Query-Pläne, um die I/O Charakteristika zu überprüfen und sie mit den während der Optimierung der Query verwendeten Werten zu vergleichen. Entdeckt der Query Optimizer signifikante Abweichungen, ändert er seine Annahmen und Algorithmen während der nächsten Ausführung dieses SQL Requests, um einen besseren Plan zu generieren. Zur Ergänzung des lernenden Optimizer ist die DB2 Runtime Engine mit adaptiven Technologien ausgestattet, die es gestatten, den Plan einer aktuell ablaufenden Query im Fluge zu ändern, um die Effizienz der Query für den noch verbleibenden Rest der Laufzeit zu steigern.

Zusätzlich zu den selbst lernenden Plan-Optimierungen kann der SQE Optimizer die SQL Performance auch mittels neuer Indexierungstechnologien steigern. Zunächst einmal kann der SQE Query Optimizer mit EVI (Encoded Vector Indexes) die Verarbeitungsgeschwindigkeit von Summen- und Durchschnittsbildung signifikant erhöhen, sofern ein EVI über die im Funktionsaufruf angesprochenen Spalten vorhanden ist. Der zweite wesentliche Fortschritt in der Indizierungstechnologie von DB2 für i5/OS ist eine Funktion namens SQL Derived Indexes (abgeleitete Indizes). In gewisser Weise kann man diese Funktion als i5/OS SQL Schnittstelle betrachten, die mit DDS aufschließt, da sich hier SQL Indizes mit Ausdrücken und Selektionskriterien erstellen lassen, so wie i5/OS und OS/400 Entwickler es von jeher bei indizierten logischen Dateidefinitionen angewandt haben. Die Möglichkeiten der SQL Derived Indexes allerdings gehen mit der Fähigkeit, SQL BIFs als Teil des Schlüsselbegriffs zu spezifizieren – wie das nachfolgende Beispiel zeigt – noch darüber hinaus.

CREATE INDEX upper_cname ON
  customers(UPPER(company_name))

Die Funktion Upper ist vermutlich eine der populäreren SQL BIFs, die in Verbindung mit SQL Derived Indexes Verwendung finden. Die Funktion Upper wird von Anwendungsentwicklern oft genutzt, um Suchbegriffe in Groß- und Kleinschreibung zu implementieren:

SELECT customer_ID, customer_phone FROM
customers
 WHERE UPPER(company_name)= 'ACME'

Durch die Umsetzung aller Firmennamen in Großbuchstaben liefert die Query sämtliche Vorkommen von ACME, gleichgültig, ob Mitarbeiter den Firmennamen unterschiedlich eingegeben haben (z. B. Acme oder acme).

Wenn diese Art der Suche mit Unterscheidung nach Groß- und Kleinbuchstaben unter DB2 für i5/OS auch keine funktionalen Probleme aufwarf, so konnten doch Performance-Probleme auftreten, weil die Funktion Upper den Query Optimizer daran hinderte, zur Beschleunigung der Suche einen Index einzusetzen. Die neue SQL Derived Index Unterstützung erlaubt nun für den schnellen Datenzugriff die Erstellung eines solchen Schlüsselbegriffs und seine Nutzung durch den SQE Query Optimizer. Das wird möglich, weil der Schlüsselbegriff im Index sich nun exakt mit dem Spaltenausdruck in der Query (in Groß- und Kleinschreibung) deckt.

Einige Kunden haben erfolgreich spezielle, gewichtete Sortierreihenfolgen eingesetzt, um die Performance-Probleme zu lösen, die sich aus Suchbegriffen in Groß- und Kleinschreibung ergeben. Dieser Ansatz erfordert jedoch eine komplexere Konfiguration bei der Erstellung der Datenbank und der Anwendungen. Überdies lassen sich solche speziellen Sortierreihenfolgen nicht in Verbindung mit komplexeren Ausdrücken (wie im nachfolgenden Beispiel) einsetzen.

WHERE UPPER(CONCAT(FirstName,LastName)) 
 = 'ALBERTYOUNG'

Im Grunde kann jede beliebige SQL BIF in die Definition eines SQL Derived Index eingeschlossen werden. Das nachfolgende Beispiel zeigt einen solchen abgeleiteten Index, der Selektionskriterien enthält.

CREATE INDEX cust_ix1 ON
  customers(customer_id) WHERE activefld='A'

Dieser Index wird auch als reduzierter Index (sparse index) bezeichnet, da er nicht für jede Zeile der Tabelle einen Schlüsselwert enthält. Solche Indizes lassen sich unter V6R1 zwar erstellen, der SQE Query Optimizer verfügt aber gegenwärtig noch nicht über die Fähigkeit, reduzierte Indizes in einer Query Implementierung zu verwenden. Der SQE Query Optimizer kann vorerst nur SQL Derived Indexes mit Schlüsselausdrücken verwenden. IBM plant für die Zukunft Erweiterungen des SQE Query Optimizers, die dann auch die Verarbeitung reduzierter Indizes erlauben.

SQL Workloads sollten unter V6R1 auch aufgrund der Verbesserung des SQL Full Open Code-Pfades schneller ablaufen. Full Open ist die Verarbeitung, die DB2 bei der ersten und zweiten Ausführung eines SQL Statements in einer Verbindung oder in einem Job vornehmen muss. Einige Tests haben hier Performance-Zuwächse von ca. 10 % gezeigt. Auch Anwendungen, die Aufrufe von Stored Procedures beinhalten, erfahren eine Performance-Steigerung durch verbesserte Caching-Algorithmen bei wiederholtem Stored Procedure Aufruf.

Dieser Artikel wird in einer der nächsten NEWSolutions Ausgaben mit Informationen zur vereinfachten Handhabung fortgesetzt.
#