Die zweitschönste Nebensache der Welt

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.

Ein Papier mit diesem Titel wurde auf der diesjährigen Informix Infobahn verteilt. Ich habe bereits daraus zitiert. Aber nicht nur deshalb ist der Vergleich von Jacques Roy so interessant, dass ich das "Papier" als PDF hier abgelegt habe.

Als Verantwortlicher ("Technical Leader, WorldWide Data Services") für die IDS-Entwicklung gibt Jacques Roy einen tieferen Einblick in das Zusammenspiel von Hardware, Betriebssystem und Datenbankserver-Architektur. Besondere Freude scheint es ihm bereitet zu haben, mit einigen Mythen um Oracles RAC aufzuräumen.

Zwei parallel laufende DB2-Exemplare auf einem kleinen, alten Thinkpad, und keine Probleme. Bisher zumindest und auch nur fast. Schließlich handelt es sich ja auch um eine Experiment. Aber es war schon knapp, wie ein Blick auf den Taskmanager zeigt.

Da sieht man als erstes, dass dieser arme T30 namens Number9 nur mit einem halben GB RAM ausgestattet wurde. Zur Zeit seiner Anschaffung war das recht komfortabel. Mein aktuelles System hat dagegen schon 2 GB, VMware sei Dank.

Nach Neustart von Number9 und ohne auch nur ein gestartetes DB2 sind dort ca. 255 MB RAM belegt. Starte ich nun die DB2 Version 9.1 sind schon 412 MB weg. Kommt noch die Version 8.1 dazu ist das RAM mit ca. 479 MB fast vollständig belegt.

Nach Stoppen beider DB2-Exemplare sind nur noch 267 MB belegt (die ca. 10 MB Differenz zu oben sind wohl normaler Schwund unter Windows). Starte ich nun das DB2 v8.1 Exemplar, komme ich auf 333 MB RAM-Belegung. Nehme ich dann die 9.1 hinzu, sind es wieder 499 MB.

Tatsächlich war es kein Problem, auf Number9 ein zweites DB2-Exemplar zu installieren.

Dazu sollte das erste Exemplar bereits gestartet sein. Denn so kann kann das Installationsprogramm einen anderen Instanznamen (hier: DB2_01) und eine andere Portnummer (hier: 50001) für die Kommunikation vorgeschlagen. Die Portnummer sollte man sich merken, die wird später noch gebraucht.

Damit ich mit dem neuen DB2-Exemplar was anfangen kann, habe ich per "Erste Schritte" die Sample-Datenbank inklusive XML-Daten installieren lassen.

Bleibt also die Aufgabe, die Sample-Datenbank als entfernte Datenbank an mein aktuelles Notebook anzubinden, damit ich auf sie später mit der hier installierten DWE zugreifen kann. Dazu verwende ich den Befehlszeilenprozessor, um die notwendigen Kommandos abzusetzen. Das geht irgendwie schneller und problemloser als mit dem GUI der Steuerzentrale.

DB2 9 bringt viele spannende und teilweise einzigartige Neuerungen in die Datenbankwelt: den XML-Datentyp, Table Compression Zeilenkomprimierung, Range Partition, Self Tuning Memory u.v.m. Natürlich wollte ich meine DB2 sobald wie möglich auf die neue Version 9.1 upgraden. Das alleine sollte kein Problem sein.

Die Data Warehouse Edition (DWE), die ich vor kurzem installierte, wird zur Zeit noch standardmäßig mit DB2 Version 8.2 ausgeliefert. Ich wäre mutig genug gewesen, die DWE mit DB2 9.1 laufen zu lassen. Doch Martin riet mir zur Vorsicht: Lieber erst mal die 9.1 auf einem anderen Rechner installieren und sie als entferntes DBMS in der DWE zu nutzen.

Das klang vernünftig, obwohl ich mir immer noch nicht vorstellen kann, warum sich die DWE nicht mit DB2 9 vertragen sollte.

Egal, sicher ist sicher, also verfolge ich Plan B: Ich habe da noch Number9, einen alten Thinkpad mit altem Windows XP (Service Pack 1) und einer DB2 Workgroup Server Edition (WSE) Version 8.1, genauer: 8.1.0.34. Alles recht alt.

Diese "Empfehlung" kann man in Oracles SQL-Referenz finden:

VARCHAR Datatype

Do not use the VARCHAR datatype. Use the VARCHAR2 datatype instead. Although the VARCHAR datatype is currently synonymous with VARCHAR2, the VARCHAR datatype is scheduled to be redefined as a separate datatype used for variable-length character strings compared with different comparison semantics.

Leider wird ihr mehr oder weniger fröhlich gefolgt. Man gebe nur "VARCHAR2" als Google-Suchbegriff ein und staune.

Glücklicherweise ist SQL eine standardisierte Sprache. Dazu gehört die Definition von Standard-Datentypen. VARCHAR ist einer. VARCHAR2 ist Oracles Erfindung und hat nichts mit dem Standard zu tun.

Was könnte Oracle veranlassen, seine zahlenden Kunden aufzufordern vom Standard abzuweichen? Der angegebene Grund kling doch sehr ominös. Will Oracle in Sachen VARCHAR auch vom Standard abrücken? Warum wird VARCHAR2 nicht für die geplanten Erweiterungen verwendet?

Jacques Roy zitierte am 19.10.2005 aus Oracles "Oracle Database 10g: The Self-Managing Database". Dieses Papier ist nicht mehr aktuell. Es gibt nun seit Juni dieses Jahres "Oracle Database 10g Release 2: The Self-Managing Database". Dort heißt es im Original:

"The Oracle database server provides a number of initialization parameters to optimize its operation in diverse environments. Only a few of these parameters need to be explicitly set as the default values for the rest of them are adequate in vast majority of cases. In Oracle Database 10g the parameters have been categorized into basic and advanced categories. Administrators will be able to restrict their day-to-day interaction with about 30 basic parameters. ..."

Mit Release 2 sind also 2 Parameter dazugekommen. So sieht Fortschritt a la Oracle aus.

"In Oracle Database 10g wurden die Parameter in Basiskategorien und erweiterte Kategorien unterteilt. Die Administratoren können sich bei ihren täglichen Interaktionen auf 28 Basisparameter beschränken. Die erweiterten Parameter sind speziell geschulten Datenbankadministratoren vorbehalten und dienen dazu, das Verhalten der Oracle Datenbank an besondere Anforderungen anzupassen ..."
(aus "Oracle Database 10g: The Self-Managing Database", zitiert nach Jacques Roy: "IDS 10.0 und Oracle 10g im Vergleich, 19.Oktober 2005)

Dazu Jacques Roy:

"Dass Datenbankadministratoren jeden Tag Interaktionen mit 28 Basisparametern ausführen müssen, klingt nicht gerade nach einer verwaltungsfreundlichen Datenbank, die obendrein noch als "selbstverwaltend" angepriesen wird, doch für Oracle 10g ist dies bereits eine große Verbesserung"
(Jacques Roy: "IDS 10.0 und Oracle 10g im Vergleich, 19.Oktober 2005)

Dem ist nichts hinzuzufügen außer diese kleine, wahre Geschichte, die mir Dirk gestern erzählte: