Die zweitschönste Nebensache der Welt

... einige Tage vor dem 11.11. wurde auf der GSE-Tagung der Service Level 11 für APL2 mit 11 Neuerungen und Verbesserungen vorgestellt. Wie jede CSD enthält auch diese einige Bug-Fixes, möglicherweise sogar 11 an der Zahl, ich habe sie aber nicht gezählt. Hier die 11 Neuerungen kurz gefasst:

SQL:2003 sei Dank für eine Menge Zeit, die ich letzte Woche sparen konnte. Schuld daran waren vor allen "MERGE", aber auch eine mit "GENERATED ALWAYS AS IDENTITY" definierte Identitätsspalte.

Es wäre schon viel Schreib- und Testarbeit gewesen ohne "Merge" eine Tabelle mit Daten aus einer anderen zu aktualisieren. Das Einfügen neuer Zeilen wäre ja noch eine leichte Übung gewesen, aber für die Modifikation bereits vorhandener Zeilen habe ich bisher stets ein Programm schreiben müssen.

Das hat sich mit der aktuellen Version des SQL-Standards geändert: Nun ist es mit einer SQL-Anweisung möglich Daten in bestehenden Zeilen zu aktualisieren bei gleichzeitiger Erweiterung der Tabelle um neue Datensätze. Ich verwende "Merge" auch dann, wenn ich nur Daten zu bestehenden Schlüsseln ändern will.

Nun ist das so eine Sache mit den SQL-Standards: Viele sinnvolle Vorschläge sind in den aktuellen Versionen der gängigen Datenbanksystemen nicht umgesetzt. Das betrifft SQL:1999 und auch SQL:2003. Andererseits versuchen einige DBMS-Hersteller durch proprietäre Ergänzungen der Datenbankfunktionalität Kunden an sich zu binden. Das betrifft vor allem Oracle, aber leider auch MySQL.

Wie gesehen kann der AP127 noch nicht mit dem XML-Datentyp umgehen, er kennt ihn schlicht und ergreifend nicht.

Das bedeutet aber nicht, dass jedes SQL-Statement, in dem XML-Daten angefasst werden, zwangsläufig zu einem AP127-Fehler führt. Solange das Ergebnis einer Query keine Daten vom Typ XML (988) enthält, ist alles gut.

Hierzu ein Beispiel mit der Tabelle XMLCUSTOMER:

select c.cid from xmlcustomer c where xmlexists(''$i/customerinfo[name = "Kathy Smith"]' passing c.info as "i")

XMLEXISTS ist ein neues Prädikat. Es prüft, ob ein XQuery-Ausdruck ein nicht-leeres Ergebnis bringt. Im Ergebnis der Query selbst tauchen dagegen nur die Integer-Werte der Spalte CID auf.

Auch diese Query verleitet den AP127 nicht zu einer Fehlermeldung:

select X.* FROM XMLCUSTOMER C, XMLTable(''$cu/customerinfo'' PASSING C.INFO as "cu" COLUMNS "NAME" CHAR(20) PATH ''name'', "STREET" CHAR(20) PATH ''addr/street'', "CITY" CHAR(20) PATH ''addr/city'') AS X

Denn die Tabelle X enthält nur dem AP127 bekannte Datentypen. Dass in der Query irgendwo XML-Dokumente verarbeitet werden, bekommt er nicht mit. Gut so!

Nichtdestotrotz wäre es mehr als sinnvoll, den AP127 mit dem Datentyp 988 vertraut zu machen.

Eines der herausragenden neuen Features der neuen DB2-Version ist der XML-Datentyp und die daraus resultierende Möglichkeit, komfortabel mit XML-Dokumenten in DB2 zu arbeiten.

Nun besitzt APL2 mit dem AP127 eine direkte Schnittstelle zu DB2, ohne Umwege über Interfaces wie ODBC. Nachdem ich auch auf diesem Rechner DB2 9 installiert habe, hat es mich geradezu in den Fingern gejuckt, mal auf XML-Daten von APL2 aus zuzugreifen.

Das Ergebnis zeigt, dass noch Einiges zu tun ist. Dazu ein erstes Beispiel:

Ich nehme die Tabelle XMLCUSTOMER aus der DB2 Sample-Datenbank. Sie hat zwei Spalten, CID und INFO. CID ist vom Typ Integer, INFO vom Typ XML.

Ein einfaches 'Select * from XMLCUSTOMER' mittels AP127 ergibt einen AP2X127105 "SQL DATATYPE 989 (COLUMN INFO) NOT SUPPORTED BY AP 127". Das ist nicht wirklich überraschend.

Der neue Datentyp muss also dem AP127 noch vorgestellt werden.

Eigentlich sollte ich mich nicht durch Oracle's Marketinggetue provozieren lassen. Performance als das Thema der Oracle 11g, erstmals schneller als spezialisierte Dateisysteme? Beeindruckend?

Sicher nicht, solange Oracle mit seinem Vergleich mehr Fragen aufwirft als Antworten gibt. Gegen welches Filesystem wurde gemessen? Woher kamen die Daten aus der Datenbank? Von einem Raw Device oder gar aus dem Cache? Letzteres wäre schon fast Betrug.

Trotzdem: Es ist ja bekannt, dass Oracle Marketing schon oft mehr versprochen hat, als Oracle Software halten konnte.

Also: Abwarten und auf die Details zu den versprochenen Performance-Verbesserungen abwarten. Und dann gibt es ja noch TPC.

Das Gleiche gilt für die Aussagen zur verbesserten Kompression in der 11g.

Und wie sieht es mit insgesamt 482 neuen Features aus? Beeindruckend? "Mit wie vielen kann man wirklich was anfangen?" fragte Bernd.

Also: Abwarten und auf die Liste der Neuerungen warten.

Eine Neuerung scheint aber zu fehlen: Die konsequente Integration von XML so, wie es DB2 9 vermag. Es sieht also so aus, dass die armen, unschuldigen XML-Dokumente weiterhin vor der Speicherung in eine Oracle-Datenbank zerrissen und zerfetzt werden.

Diese Ankündigung habe ich noch nicht bei ibm.com gefunden. Daher gibt es hier auch keinen Link, und daher konnte ich keine Details nachsehen. Einige Fragen bleiben also offen, spätestens bis ich die Version 9.1.1 installiert habe.

Das wird dann auch nicht mehr solange auf sich warten lassen: am 1.12. steht der Refresh zum Download bereit, also noch im 4.Quartal, so wie prognostiziert.

Die wesentliche Neuerung dieser Hundertstel-Version ist die Einbindung der aktuellen DB2-Version 9.1. Dies hätte möglicherweise auch mit der DWE 9.1 funktioniert, aber mit der 9.1.1 ist es nun offiziell. Und man weiß ja nie, was so passieren kann.

Damit stehen nun der DWE alle neuen Features der DB2 9 wie

• Self-Tuning Memory Management
• Table (Range) Partitioning und
• Table (Row) Compression

zur Verfügung. So zu lesen in der Ankündigung. Mal sehen, wie sich dies im SQW niederschlägt.

Es ist tatsächlich nicht so, dass die IT-Presse nicht lernfähig wäre. Einige Monate nach dem katastrophalen Ausrutscher des CW-Ressortleiters ue, hat die CW indirekt die Aussagen ihrer "Kenner der Datenbankszene" revidiert.

Die CW-Muttergesellschaft IDG hatte die neue DB2-Version in ihrem Labor getestet und für hervorragend befunden.

So purzeln nun wie selbstverständlich folgende absolut korrekte Erkenntnisse aus der CW-Feder:

"Statt wie bisher XML als Blob (Binary Large Object) zu speichern oder XML-Struktur auf relationale Strukturen abzubilden, speichert pureXML die XML-Datei selbst - mit all ihren Eigenschaften und ihrer hierarchischen Struktur."

Na also, das habe ich ja schon immer gesagt.

Als erstes Resultat seiner Zusammenfassung der IDG-Testergebnisse kommt der Autor (ba) zu einem erfreulichen Ergebnis:

"Alles in allem ist die neue DB2 technisch imposant. Sie ist voll gestopft mit Funktionen, die Administratoren und Entwickler gleichermaßen freuen."

Aber das ist noch nicht alles ...

DB2 9 bietet viele Verbesserungen gegenüber den Vorversionen und auch gegenüber konkurrierenden DBMS, vor allem in Sachen Performance und TCO. Diese Neuerungen werden ausführlich in einem Bloor Research "White Paper" von Philip Howard beschrieben.

Immer wieder dieser PH. Dass er nicht nur Gutes über DB2 9 schreibt, sondern auch schon mal über Oracle Elaborate (warum bloss) zeigt sein Artikel "Oracle rebuilds Warehouse".

Doch zurück zu DB2 9 mit einigen Kernaussagen aus dem White Paper:

"First, I think this leaves Oracle and Sybase (as the two vendors with the best current handle on XML) well behind the curve, with Microsoft and the others more or less out of sight. What this release will allow you to do is to build applications that handle both XML and relational data much more easily, without losing any of the richness that this implies, and without degrading performance."

Dies schrieb Philip Howard in "The Register" bereits im Dezember 2004 zur XML-Unterstützung in DB2 Viper im Vergleich zu anderen DBMS. Daran hat sich bis heute nichts geändert, weder Oracle noch Microsoft haben bisher nachgezogen.

Geändert hat sich nur der Name, die Viper hat nun Produktstatus und heißt DB2 9. Apropos Namensgebung, dazu schreibt Howard in seinem White Paper "The business benefits of DB2 9"

"The “Viper” release of IBM DB2, which is officially version 9, is the most important release of this database for many years. Indeed, IBM regards Viper as so significant that, at one time, it considered calling it DB3, on the basis that this represents the third generation of databases from IBM, following IMS and DB2."

Die "2" macht schon Sinn wegen der zwei zugrundeliegenden Paradigmen: hier das relationale Modell, dort der XML-Standard.

... ist ein weitreichendes und komplexes Unterfangen. Deshalb habe ich bisher tunlichst nur handverlesene Teilbereiche betrachtet.

Man suche z.B. einige Funktionen aus, die eine Datenbank bieten sollte, und vergleiche die Qualität der Unterstützung für ausgesuchte Datenbanken. So geschehen in "Die zweitbeste Datenbank der Welt". Man sollte auch die verglichenen Funktionen nennen, was ich dort offensichtlich nicht getan habe.

Das hole ich hier nach, nicht vollständig und auch nicht in der Reihenfolge des Vergleichs: Partitionierung, XML-Unterstützung, "Self Tuning" und Komprimierung.

Es müssen ja nicht nur Funktionen oder Features sein, es können auch Lizenzbedingungen sein. Das ist oft nicht weniger interessant, wie "Freie Datenbanken von unfreien Anbietern" zeigt.

Aber alles beleuchtet nur einen kleinen Ausschnitt. Ich denke, man kann ... wo ich das gerade schreibe, kommt auf meinem Rechner der RSS zu einem CW-Artikel zu einem DB-Benchmark-Tools herein. So ein Zufall.

Bernd hat den zweiten Vergleich getrackbackt. Dort wünschte sich ein Kommentator einen Vergleich der "Performance und Leistungsfähigkeit". Das ist nun ein schwierigeres Unterfangen, dem ich auch hier nicht nachkommen werde.

Doch einige Bemerkungen zu diesem Thema möchte ich hier loswerden:

Auch ich habe meine "Kenner der Datenbankszene", die ich hier zu Wort kommen lasse.

Korrektur: nicht zu Wort, sondern zu Tabelle:

DB2 9 Oracle10g R2 MS SQL Server 2005 Best Good Good Best Good Worst Good Best Good Best Good Worst Good Worst Best Best Good Best Best Good Worst

Zugegeben, die erste Spalte habe ich nicht mitgenommen. Hier stehen normalerweise Kategorien mit Datenbank-Eigenschaften, die in den folgenden Spalten pro DBMS wie zu sehen bewertet wurden.

Man kann dem Autor nicht unterstellen, dass er alles nur durch die blaue Brille sieht. Ich halte ihn daher für objektiver, also vertrauenswürdiger als anderer Leute "Kenner der Datenbankszene". Außerdem:

Durch Zufall bin ich auf einen inzwischen recht alten Artikel im "The Register" gestoßen. Am 9. Dezember 2004 tat Philip Howard von Bloor Research seine Meinung zur damals frischen Ankündigung der nächsten DB2 Datenbankgeneration kund: "IBM moves the database goalposts". Damals schon sehr vorausschauend in Hinblick auf die am Freitag beginnende WM.

Aber eben nicht nur in diesem Sinne vorausschauend: Einige Dinge, die ich hier über DB2 Viper und auch über die Reaktionen darauf, geschrieben habe, hat der Autor bereits Ende 2004 in besagtem Artikel zusammengefasst. Zu der Zeit konnte ich es noch nicht tun, weil dieser Blog noch nicht existierte.

Aber nun ernsthaft zum Thema "Schaum vorm Mund", das, was nach Philip Howard Oracle nun schon eine Weile mit sich rumträgt. Zu Beginn lade ich ihn als Zeuge für mein "Ceterum Censeo":

"IBM has concluded, rightly in my view, that using a relational approach is not adequate for processing XML. Either you store it in relational format, in which case you get a major performance hit because you have to convert it to and from tabular format whenever you store or retrieve it, or you have to store it as a binary large object, in which case you can’t do any processing with it."

Im Nachhinein lasse ich mir von Howard des weiteren bestätigen, dass der XML-Unterstützung durch Viper die direkten Konkurrenten zur Zeit nichts entgegen zu setzen haben: