Datenbanken

Es ist wie eine Sucht. Aber die Wahrheit muss nun mal raus.

Auch in Russland weiß man, welches die schnellste Datenbank ist. Folgendes Zitat stammt aus einer Konversation mit einem russischen Software-Entwickler (danke, Alexei):

"As for IBM DB2, we're familiar with it. It's probably the fastest database, very reliable."

Ja, DB2 ist nicht nur möglicherweise die schnellste Datenbank, sondern auch noch extrem zuverlässig. Das kann nicht jeder Anbieter von seinem Elaborat sagen.

"As I suppose, here in Russia Oracle is used more often for now, but for the time-critical tasks, for large companies (of course it can be used for companies of any size), DB2 is the best choice."

Der Mann sollte wissen, was er schreibt. Er und seine Leute arbeiten hauptsächlich mit Oracle.

"Of course I should tell about usage of static SQL and possibilities to optimize the database in the very flexible way. Plus Information Integrator, enhanced XML support in its latest edition, DB2 Viper."

Genau, ich denke gerade die beiden letzten Punkte bringen das DB2 Angebot eindeutig vor Oracle an die Tabellenspitze.

Eigentlich wollte ich jetzt über meine Sudoku-Hilfsfunktionen schreiben. Stattdessen stieß ich auf die heutige Computerwoche Topmeldung:

"Security-Panne bei Oracle?"

Es macht Spaß über Oracle zu meckern. Gute Menschen aus Redwood, CA sorgen stets für Bestätigung.

Man könnte nun meinen, die CW hat etwas gegen Oracle wie seinerzeit gegen IBM. Man könnte vielleicht sogar meinen, ich könne Oracle nicht leiden. Iwo! Oracle liefert ja freiwillig die Lachnummern:

"Wie Sicherheitsexperten berichten, hat das Unternehmen in seinem Support-System "Metalink" vergangene Woche Code-Beispiele veröffentlicht, mit denen man ein bislang ungepatchtes Sicherheitsloch in seiner Datenbank ausnutzen kann."

Nett, diese Offenheit. Wenn schon nicht Open Source Datenbank, dann wenigstens Oracle, die Offene Datenbank.

Danke, Oracle, für die amüsanten Unterbrechungen.

Ich bin ja kein Oracle-Experte. Ich habe nicht mal eine Oracle-Datenbank auf meinem Rechner installiert. Ich möchte dies diesem armen, unschuldigem Ding auch nicht zumuten.

Daher muss ich mich auf anderer Leute Erfahrungen verlassen. Auf Leute also, die es wissen müssen, da sie mit beiden Datenbanken - Oracle und DB2 - arbeiten.

Gestern traf ich so jemanden: Thomas Ruf. Ein alter Profi mit reichlich praktischer Erfahrung mit beiden Datenbanken.

Und der sagte, dass eine Anwendung, die er betreute, mit DB2 wesentlich besser performte als mit einer Oracle-Datenbank - um 80%. Eigentlich kaum zu glauben. So etwas sagt man nicht vor Publikum, wenn da überhaupt nichts dran ist.

Ludger hat schon vor ungefähr 10 Jahren ähnliche Erfahrungen gemacht, vielleicht nicht gerade in der Größenordnung von 80%.

Mast- und Schotenbruch für alle Oracle-Looser, äh, -User!

Ich habe mein Bestes getan, um Alan davon zu überzeugen, seine MySQL-Datenbank nach DB2 Express-C zu migrieren. Das hat auch fast geklappt, bis er fragte, ob DB2 Indizes auf BLOBs legen kann. Natürlich geht das nicht! Aber macht das überhaupt Sinn?

Hat Alan hier möglicherweise etwas falsch verstanden? Meinte er vielleicht, dass MySQL die Möglichkeit bietet in LOBs zu suchen?

Also mal sehen, was MySQL dazu sagt ...

Dabei stoße ich auf einen Link zu einem Migration Tool Kit. Das ist spannend! Für DB2 gibt es das ja auch.

Nur MySQL und DB2 scheinen sich geflissentlich zu ignorieren: Beide bieten Migrationshilfen vom MS-SQL Server oder von Oracle an, aber nicht von DB2 (oder Informix) bzw. MySQL.

Zumindest ist dies jeweils nicht dokumentiert. Denn mit Hilfe des DB2 Migration Toolkits wurde bereits testweise mindestens eine MySQL-Datenbank nach DB2 portiert. Das geht also, ist aber nur nicht dokumentiert.

Alans Frage beantwortet das alles nicht.

Diese Kategorie war in letzter Zeit so frei von den tieferen Wahrheiten unseres Universums. Es ging nur noch um böse Orakel. Ich wende mich nun wieder mit Freuden den schönen Dingen des Lebens zu: APL2 und die Viper. Dies habe ich u.a. auch Nancy geschrieben (allerdings in Englisch):

IBM wird eine neue DB2-Version ankündigen, die auf der DB2-Weiterentwicklung unter dem Namen Viper basiert. Ich bin sicher, dass besonders die Erweiterungen zu XML für AP127-Nutzer von großem Interesse sind. Es handelt sich hierbei um die Möglichkeit auf gespeicherte XML-Dokumente mittels XQUERY zuzugreifen.

Wird Nancy Gefallen an XQUERY finden? Und überhaupt: Habe ich recht in der Annahme, dass eine Erweiterung des AP127 um die XQUERY Syntax außer mir irgendeinen APL2-Nutzer interessiert?

Und dann noch mein Cetero Censeo: Ich denke, die DB2 Express-C könnte wirklich interessant für APL2-Entwickler sein. Ja sicher, aber was soll Nancy damit?

Das ging schnell!

Ich hatte gerade einen Link zu meinem Blog-Eintrag mit dem schönen Oracle-Mastbruch-Gif (Vielen Dank, Dirk) verschickt, und prompt wurde er weiterverraten:

"... ein interessamter Blog Eintrag eines true blue BP´s"

Damit musste ich natürlich rechnen. Also für alle, die es wissen oder auch nicht wissen wollen:

Dies ist mein großer grauer Notizzettel, da kommt alles rein, was ich mir merken will, und was in meinen Kopf nicht mehr reinpasst. Da ich offensichtlich kein DB2-Spezialist bin, kommen hier also auch simple Anmerkungen rein.

Dirk hat mich damit auch enttarnt:

Ja, ich gestehe, ich bin sehr einseitig, was Datenbanken angeht. Ich mag aus mehr als einem Grunde Oracle nicht (wie überraschend!), und präferiere definitiv DB2, aber auch Informix. Nicht nur, weil dies die weltbesten Datenbanken mit ihren spezifischen Stärken sind. Einen weiteren Grund verrate ich hier nicht.

Die IDS muss man alleine schon deshalb mögen, weil von dort all die schönen Fußball-Statistiken kommen.

Und wohin?



Wir haben ja gelernt, dass Oracle-Software - und dazu gehört nun mal auch die Datenbank - ein Sicherheitsrisiko darstellt. Also weg mit diesem DBMS.

Aber nicht mit den Daten! Diese können z.B. nach DB2 übernommen werden. Dazu gibt es das DB2 Migration Toolkit.

Als Quell-DBMS für das Toolkit kommen außer Oracle auch andere Plattformen in Frage. Auch MySQL!

Im DB2 Befehlsfenster kann man sich ganz einfach die Struktur einer Datenbank als Sequenz von DDL-Statements erstellen:

db2look -d [Datenbankname] -e -l -x -c

Was die einzelnen Parameter bedeuten, schaue man sich mit db2look ? an.

Abgespeichert in einer Datei können diese Anweisungen wie gewohnt mit

db2 -tf [Dateiname]

ausgeführt werden. Vorher können natürlich einzelne Statements in der Datei geändert werden, z.B. kann als erstes mit einer anderen Datenbank verbunden werden.

Disclaimer: Folgendes gilt offensichtlich nur für DB2. Ähnlichkeiten mit Befehlen anderer DBMS sind wahrscheinlich rein zufällig.

Für diese triviale Frage hatte ich keine triviale Antwort parat:

Wie kann ich eine Datenbank (samt Inhalt) von einem System auf ein anderes transportieren? Auf dem Zielsystem ist noch keine Datenbank bzw. Struktur zur Aufnahme der Quelldatenbank angelegt.

Unter DB2 gibt es einen Befehl der diese Aufgabe fast komplett erledigt.

Da war ich doch der Meinung, dass Oracle nirgends die Nummer 1 ist: Nicht bei Datenbanken, nicht bei ERP-Software, auch nicht beim Segeln. Das war ein Irrtum:

Oracle ist auf dem besten Wege dieses Jahr Microsoft, den bisher ungeschlagenen Champ, in seiner Domäne zu schlagen. Nein, nicht beim Abzocken mit Betriebssystemen oder Office-Software. Es sieht so aus, dass Oracle-Produkte mehr Sicherheitsprobleme erzeugen als die Software des üblichen Verdächtigen auf diesem Spielfeld.

"Oracle hat ein Sicherheitsproblem" titelte die Computerwoche in ihrer Ausgabe von 06.03.2006.

Noch bevor der CW-Artikel über die Ankündigung der Oracle Suchmaschine erschien, haben sich schon einige Leute über ihre Positionierung in dem nicht mehr jungfräulichen Markt der Unternehmenssuchmaschinen Gedanken gemacht. Uns interessierte vor allem ein Vergleich mit IBMs Omnifind (korrekt: Websphere Information Integration - OmniFind Edition). Christian wird mir hoffentlich verzeihen, wenn ich hier seine Mail zitiere:

Hallo Axel,

ich habe mir inzwischen die verschiedenen White Paper angeschaut und ebenso ein wenig im Admin Tutorial herum gestöbert und muss sagen, dass das Produkt Enterprise Search von Oracle nicht ganz uninteressant ist.

Das ist doch nicht zu fassen ...

Da stellt sich doch der Egomane Larry Ellison hin und kündigt irgendwo eine öde Enterprise Search Engine an und die Computerwoche hat nichts besseres zu tun, als das groß rauszubringen - mit Bild von meiner Lieblings-Nr.2. Doch dazu später.

Es wurden schon bessere Suchmaschinen angekündigt. Nur wurde darum nicht so ein Marketingbrimborium gemacht:

"Das ist eine unserer wichtigsten Ankündigungen seit vielen, vielen Jahren" (Ellison, gemäß CW). Herzlichen Glückwunsch dazu. Warum nur diese übertriebene Aufmerksamkeit? Es wird wohl an Larry liegen. zugegeben, Larry hat wohl Ausstrahlung, ist aber auch ein herrlicher Laberkopp:

Vor Kurzem bin ich zu DB2 und Performance befragt worden. Leider konnte ich nicht alles vollständig und zu meiner Zufriedenheit beantworten. Ab morgen gibt es auf der CeBit die Gelegenheit, all die offen gebliebenen Themen kompetent schließen zu lassen. Hier ein Auszug der Fragen (Q) und Antworten (A).

Q: Kann man bei der DB2 auch Datenbanken komprimieren?
A: Auf jeden Fall bei der neuen Version. Ich bin nicht sicher, was die aktuelle Version 8.2 angeht.
AA: "Row Compression" ist ein neues Feature der DB2 Viper und nicht zu verwechseln mit der Komprimierung von Nullen und Standardwerten (VALUE COMPRESSION) der aktuellen Version.

Q: Sind die dann Read-only oder noch schreibbar?
A: (zensiert)
AA: Da in der "Ankündigung" keine Einschränkung hierzu gemacht wurde, werden komprimierte Tabellen wohl auch beschreibbar sein.

Q: Hab heute extra mal nen Benchmark laufen lassen. Approx 10k Records pro Stunde... Ist das gut?
A: Kommt natürlich darauf an ... (die übliche Antwort bei solchen Fragen nach HW, SW, Größe der Tabelle, Indizes, Schuhgröße des Benutzers usw.)
AA: Das klingt immer noch nach keiner guten Performance. Das sollte aber besser am lebenden Objekt, soll heißen an der Tabelle, getestet werden.

Q: Macht es eigentlich mehr Sinn 1 mil. Records mit einem Select abzurufen oder anhand des prim. key in 10 Selects aufzuspalten?
A: Hast du genug RAM sollte, das egal sein.
AA: Das ist wieder so eine "Das kommt darauf an"-Frage: wie will der geneigte Frager die selektierten Daten weiterverarbeiten?

An dieser Stelle ist es wieder notwendig, etwas zu APL zu schreiben: Seit ich ihn kenne vertritt Axel G. die Auffassung, dass es stets schneller ist, APL soviel RAM wie möglich zu geben, alle zu verarbeitende Daten in den APL-Workspace zu laden, um dann darauf rumzufuhrwerken. Ich habe dazu stets gemäß Radio Eriwan "Im Prizip ja" gesagt. Letztlich habe ich die Performance einer APL-Anwendung, die viele Inserts und Updates absetzte, um Faktoren verbessert, indem ich der Anwendung weniger RAM gelassen habe. Warum wohl? Da haben sich zwei um all meinen schönen Speicher geprügelt.

Zum letzten Q hatte ich dann noch ein
A: Du kannst die DB2 so konfigurieren, dass große Resultsets am besten mit viel Speicher performen.
AA: Das macht die DB2 inzwischen auch selbst. Per Advisor schlägt sie für eine konkrete Datenbank eine optimale Konfiguration vor. Dem bin ich dann gefolgt und habe nun überraschend gute Antwortzeiten auch bei komplexen bei Selects.

Mal sehen was BB dazu auf der CeBit meint.

Da APL2-Entwickler nun ohne Kosten DB2 für APL-Anwendungen verwenden können, wird das Thema Datenbanken für uns immer interessanten. Und das noch mehr, wenn es sich nicht nur um relationales Datenbanken handelt, die auch noch XML "können".

Ich habe letzte Woche an einer Veranstaltung teilgenommen, in der die kommende Version von DB2 - DB2 Viper - vorgestellt wurde. Hier aus meiner Sicht die Highlights:

DB2 Viper ist eine hybride Datenbank. Sie verarbeitet Daten nicht nur in Tabellen nach dem relationalen Modell, sondern auch hierarchisch mit XML beschriebene Daten. Dazu gibt es einen neuen Datentyp XML, d.h. ich kann in Tabellen Spalten anlegen, deren Elemente XML-Daten enthalten.

In Gegensatz zu anderen Datenbanksystemen, die XML-Dokumente speichern können (Oracle, MS-SQL oder DB2 8.x), werden die Daten nicht als langer, unstrukturierten String als CLOB gespeichert, sondern bereits "geparst" als hierarchisch strukturiertes Objekt. Das bringt gravierende Vorteile für die Verarbeitung sowie die Performance.

Neben SQL ist nun auch XQUERY als zweite standardisierte Zugriffssprache implementiert. Mehr noch: Ich kann mit SQL auf XML-Daten zugreifen und umgekehrt mit XQUERY auch relationale Daten selektieren.

Ich werde also meine Java-, Windows- oder APL-XML-Parser beiseite legen und XML-Dokumente gleich in der Datenbank zu speichern. Das bedeutet einmal Parsen beim Speichern und nie mehr Parsen beim Lesen und Weiterverarbeiten.

Für Leute, die mit APL2 arbeiten geht das dann alles mit dem AP127. Nancy muss dann AP127 Refenence Manual umschreiben. Der Titel kann dann eigentlich nicht mehr nur "Using SQL" heißen. Es könnte dann mit "Using SQL and XQUERY" betitelt werden.

Im Dezember habe ich damit begonnen, alle meine APL2-Elaborate zu katalogisieren. Was und wie ist schon mehr als ein Thema für sich. Die Katalogtabellen habe ich anfangs in AP12-Dateien gespeichert. Da eine dieser Tabellen sehr groß war, waren die Zugriffszeiten entsprechend mit Wartezeit versehen.

Spaßeshalber habe ich den Katalog nach DB2 migriert. Das machte für mich Sinn, da ich dieses System bereits installiert hatte und APL2 mit dem AP127 eine "native" Schnittstelle zu DB2 besitzt. Die Arbeit hat sich gelohnt:

Die Zugriffszeit vor allen für Queries sind erheblich kürzer!

So kann ich den Katalog vernünftig einsetzen.

Schade ist nur, dass nicht jeder mit APL2 auch DB2 bekommt. DB2 kostet (wie auch APL2). Aber Rettung naht in Gestalt von

DB2 Express-C,

einer kostenlosen, voll-funktionsfähigen Version für Software-Entwickler (und das sind wir APLer doch alle). Runter laden, installieren und mit dem AP127 nutzen. Es ist jetzt so einfach, Daten mit APL2 relational zu speichern.

Es geht aber noch einfacher: DB2 Express-C ist kostenlos. Es sollte doch möglich sein, damit ein Paket mit APL2 zu schnüren. Die Frage ist nur, ob IBM (wer auch immer) da mitmacht.