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.

Immer wieder kann man lesen oder hören, dass Beörden oder andere öffentliche Organisationen ihre Daten in Oracle Datenbanken speichern und verwalten.

Als braver Steuerzahler (und das nicht zu knapp) stört mich das erheblich!

Das stört mich seitdem ich weiß, dass hier unnötig Steuergelder mit der aufwändigen Administration von Oracles DBMS verschleudert werden. Beim Einsatz effizienterer und performanterer Datenbanksysteme kann man schon mal bis zu einem Drittel der Administratorenkosten sparen. Und das ist noch nicht alles.

Darum sollten sich mal die diversen Rechnungshöfe kümmern.

Das habe ich nun davon, dass ich mich nicht an eine sinnvolle Empfehlung zur Benutzung von Windows gehalten habe. Hätte ich mich aber daran gehalten, wäre ich nicht auf dieses seltsame Verhalten von DB2 gestoßen.

Meinen vorherigen Rechner "Number9" habe ich ausschließlich den User "Administrator" benutzt. Dies habe ich inzwischen für meinen aktuellen Rechner geändert. Auf unseren Linux-Systemen arbeite ich schließlich auch nicht standardmäßig als "root". Number9 hat natürlich auch ein DB2, seit Kurzem sogar in zwei unterschiedlichen Versionen. Da ich mich normalerweise unter meiner Windows UserID auch bei DB2 anmelde, habe ich mich wohl nie explizit mit UserID und Passwort mit einer Datenbank verbunden ("connect to ...") - weder über das DB2-Befehlsfenster, noch über den AP127 mit APL2. Ich bin nun mal schreibfaul.

Nun geschah es aber letzte Woche, dass DB2 von mir UserID und Passwort haben wollte (da ich mich mit dem zweiten DB2-Exemplar als entfernte Instanz verbinden wollte). Der

connect to apl2lib9 user Administrator

im Befehlszeilenprozessor funktionierte klaglos. Aber der Connect über AP127 zickte: Nach

CTL127←'CONNECT' 'APL2LIB9' 'Administrator' PASSW

beschwert sich AP127 mit einem(1 0 0 1 162): "THE USERID ARGUMENT TO CONNECT MUST BE A CHARACTER VECTOR OF LENGTH 1 TO 8".

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.

... und wieder neue Gerüchte.

Die Software-Branche ist ein Haifischbecken. Die Großen fressen die Kleineren und lassen sich das viel kosten.

Und immer wieder tauchen die Namen IBM und Oracle auf. Die balgen sich auf dem Transfermarkt für Software-Hersteller immer wieder um kaufwillige Kandidaten. Noch sieht es so aus, dass IBM den Kampf um Filenet gewonnen hat. Ich nehme allerdings an, dass Larry Ellison hier noch nicht aufgegeben hat. Eine kleine Chance hat er ja noch.

Nachdem Cognos immer noch eigenständig ist, geht es nun offensichtlich um Business Objects. Beide würden mit dem Kauf ihre Marktposition in Bereich "Business Intelligence" (mir leuchtet immer noch nicht ein, wie Unternehmen intelligent sein können) vor allem gegenüber Microsoft stark verbessern.

Bei IBM würde ein Kauf von BO eine Änderung ihrer bisherigen Middleware-only Strategie bedeuten. Cognos oder Microstrategy wären dann nicht mehr Partner, sondern Konkurrenten.

Sowohl IBM als auch Oracle würden mit der BO-Software ihre BI-Produktpalette zum Frontend hin komplettieren.

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.

Ich habe von meinem Sohn ein Stöckchen zugeworfen bekommen. Bis gestern wusste ich noch gar nicht, dass es so etwas gibt. Ich muss zugeben, dass ich heute immer noch nicht genau weiß, was das soll.

Nichtsdestotrotz, ich hebe es mal auf, wenn auch spät, aber immerhin.

1. Wann stehst Du zur Arbeit auf?

Meist gegen 8 Uhr. Manchmal schon kurz nach 5 Uhr, wenn ich weit weg einen frühen Termin habe.

2. Stehst Du rechtzeitig auf oder bleibst Du bis zur letzten Minute liegen?

Manchmal genehmige ich mir eine Verlängerung.

3. Wie viele Wecker hast Du?

Einen, den ich aber nicht benutze. Unterwegs zweckentfremde ich manchmal mein Handy.

4. Machst Du Frühsport?

Ja, es wird aber nicht verraten was und wie lange. Die Dauer ist eher vernachlässigbar. Für ernsthaften Frühsport müsste ich eine halbe Stunde früher aufstehen.

5. Frühstückst Du? Wenn ja, was?

Joghurt oder ein Käsebrötchen, was eben da ist.

6. Wie fährst Du zur Arbeit?

Mit dem Auto zum Büro, zum Bahnhof oder zum Flughafen. Mit dem Taxi oder öffentlichen Verkehrsmitteln zu auswärtigen Terminen oder ähnlichem.


Wohin soll ich bloß das Stöckchen hinwerfen. In meinem engeren Freundes-, Verwandten- und Bekanntenkreis gibt es nur einen Blogger - soweit ich weiß: meinen Sohn. Und zwei hoffnungsvolle Neublogger mit jeweils einem Beitrag: Unseren Geheimratsvorsitzenden, dem magenta Panther Bernd P, und die Frau Dr.

Ob die das Stöckchen überhaupt sehen?

... verlässt das Microsoft-Schiff. Nicht, weil es sinkt, es sinkt nämlich nicht. Einige würden hier schreiben "leider". Aber bleiben wir realistisch und auch fair.

Apropos "fair". Den Beitrag zu Gates' Abschied von Microsoft im CW Notizblog halte ich für angemessen und auch fair. Dazu zwei Zitate aus dem Blog:

"Ohne die Produkte seines Hauses würden wahrscheinlich nur ein Bruchteil der heutigen Nutzer mit IT und Internet umgehen. Was auch bedeutet, dass die IT-Industrie eine kleinere Rolle einnehmen würde als sie heute spielt"

Natürlich ist das reine Spekulation, aber man kann das so sehen. Das waren dann die Good News.

"Die Monopole in den Bereichen Betriebssysteme und Büroanwendungen hat Gates rücksichtslos ausgenutzt, um für sein Unternehmen neue Märkte zu erobern. Das hält er heute noch so, kaum gebremst von den Kartell-wächtern dieser Welt."

Das sind offensichtlich die Bad News. Das gehört sich auch so bei einer ausgewogenen Berichterstattung.

Gates und Microsoft haben möglicherweise tatsächlich einen beträchtlichen Anteil am Erfolg der IT in der näheren Vergangenheit. Inzwischen erweist sich Microsoft eher als Bremser des IT-Fortschritts.

Das ist typisch für ein Monopol.

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: