Die zweitschönste Nebensache der Welt

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.