Die zweitschönste Nebensache der Welt

Auch mit APL2 Service Level 12 gilt, was bereits für vorangehende Versionen angemerkt wurde:

• APL-Zeichen wie z.B. "∆" in Namen von APL2-Objekten werden in der Titelleiste des Objekteditors nicht als solche angezeigt - soweit man den Schicki-Micki Aero-Desktop verwendet.
  
  Die Korrektur ist wohl schwieriger als man erwarten sollte. Microsoft legt den APL2-Entwicklern (und nicht nur denen) auch schwere Steine in den Weg.
  


• Bei deaktivierter Benutzerkontensteuerung entfällt die Einschränkung in der readmec.txt bezüglich des Zugriifes auf Dateien im APL2-Installationsverzeichnis.
  

Eine der wesentlichen Neuerungen der CSD 12 betrifft die DB2-Schnittstelle:

"As of Service Level 12, AP 127 has been re-written to use the CLI interface to DB2."

Dahinter steckt eine große Erleichterung: Nie wieder muss ich APL2 an eine DB2-Datenbank binden bevor ich auf diese per AP127 zugreifen kann.

Aber Vista zerstört so manche Verbesserung: Nach Installation der CSD 12 funktionierte das Deklarieren einer gemeinsamen Variablen mit dem AP127 schlicht und ergreifend nicht. Jeder Versuch brachte nur einen Kopplungsgrad von 1, einen zuwenig, um mit dem AP127 sprechen zu können.

Und wer stand wohl zwischen APL2 und dem AP127? Wie so oft die Benutzerkontensteuerung. Erst nachdem ich sie komplett ausgeschaltet hatte, konnte ich auf eine DB2-Datenbank zugreifen.

Netter Nebeneffekt: Bein Starten von Vista taucht nebenstehende DB2-Fehlermeldung nicht mehr auf und mit DB2 lässt sich wieder so bequem arbeiten wie unter XP.

Aber das ist nicht der einzige Grund, die Benutzerkontensteuerung entgegen der Empfehlung von Mickeysoft auszuschalten.

Es ist schon bezeichnend, dass das IBM Data Studio so und nicht etwa IBM DB2 Data Studio heißt. Was kann das nur bedeuten?

Tatsächlich kann es das Data Studio anders als die DWE (oder wie es neuerdings heißt: das DB2 Warehouse) mit mehr als einer Datenbank. Bei den Stichworten Datenbank und IBM dachte man bisher zuerst an DB2, aber inzwischen - nach Jahren des Kampfes - ist nun auch IDS als Datenserver im Hause IBM akzeptiert.

Konsequenterweise unterstützt das brandneue IBM Data Studio auch IDS. Manche IDS-Kunden wünschen sich gleiches in Sachen Warehouse und darauf aufbauender Analysewerkzeuge.

Auch in Sachen freier Entwicklerversionen hat IDS inzwischen nachgezogen. Mit leichten Einschränkungen gegenüber den kostenpflichtigen IDS-Versionen kann man sich die "IDS Developer Edition" kostenlos herunterladen.

"Was nichts kostet, ist auch nichts wert" - dieser Glaubenssatz ist glücklicherweise nicht immer wahr.

"Darüberhinaus kann man jetzt auch das neue und kostenlose IBM Data Studio, dass neben DB2 auch IDS unterstützt, downloaden: ...". Diese Ankündigung flatterte mir noch vor Weihnachten per E-Mail in meine Inbox. Kurzentschlossen, da neugierig, habe ich also die 600 MB "IBM Data Studio Version 1.1.1" heruntergeladen und installiert, bevor sich IBM vielleicht doch noch einen Preis einfallen lässt. Denn vorweg genommen: Diese Software ist was wert!

Wer das Design Studio der inzwischen schon guten, alten DB2 Data Warehouse Edition kennt, wird mit dem Data Studios sehr gut klarkommen. Das gleiche Look-and-Feel, nahezu die gleichen "Perspektiven": Datenbankexplorer, Datenprojektexplorer, Eigenschaftenfenster usw. Kein Wunder eigentlich, denn beide Anwendungen basieren auf Eclispe, und von der Aufgabenstellung her sind sie sich recht ähnlich. Auch IBM Softwareentwickler müssen nicht stets das Rad von Neuem erfinden.

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.

Interessant! Sehr große Tabellen scheinen MySQL an den Rand der Verzweiflung zu bringen. Diese Erkenntnis verdanke ich nicht eigener Praxis, sondern Bernds leidige Erfahrung:

"Ich trau aus Erfahrung keiner MySQL-Tabelle größer als 5 GB ..."

Hm, eigentlich sollten 5 oder 8 oder 10 GB keine Herausforderung für heutige DBMS sein, wohlgemerkt als Größe einer Tabelle. Solche und wesentliche größere Tabellen kommen in den besten Unternehmen vor.

Fragt man Vertreter von IBM oder Oracle danach, ob ihre DBMS diese Herausforderung bestehen, so werden sie gelangweilt mit Achseln zucken und "So what" fragen. Die wirkliche Herausforderung liegt im Terabyte-Bereich. Bis Bernds Tabelle den erreicht, fließt noch viel Wasser den Neckar herunter.

Möglicherweise wird er bereits davor seine Datenbank in ein anderes DBMS migriert haben.

... die kostenfreie Express-Variante des SQL Server 2005 installieren: Das geht nicht!. Zumindest nicht unter XP, immerhin mit SP2.

Ständig hat das Setup etwas zu meckern: Mal fehlt das .NET Framework 2.0, mal passt ihm der vorhandene Windows Installer nicht. Als Setup hat man es schon schwer.

Da lobe ich mir DB2 und gerade die - auch kostenfreie - Express-C. Dort wird alles installiert, was benötigt wird, ohne Aufforderung, zuerst dies oder das zu installieren.

In Sachen SQL Server Express bin ich mir nicht mal sicher, dass nach erfolgreichem Setup die Datenbank auch arbeitet. Denn ich habe in diesem Rechner 2 GB RAM, und Microsoft beschränkt die Nutzung für die Express auf 1 GB. Muss ich jetzt 1 GB aus dem Rechner reißen? Oder beschränkt Express künstlich den verfügbaren Speicher für die Datenbank.

Auch in diesem Falle hat die DB2 Express-C einen klaren Vorteil: Hier liegt die Schranke auf 4 GB RAM. Dagegen sind die freien DBMS-Varianten von Oracle und Microsoft mit all ihren Beschränkungen Kinderkram.

Eigentlich wollte ich nur einen Langläufer testen - eine SQL-Query in der drei Tabellen mit ca. 300.000 Zeilen und eine Tabelle mit mehr als 10.000 Zeilen gejoint werden. Anlass war meine Beobachtung, dass das Komprimieren großer Tabellen neben Speichergewinn auch eine bessere Performance bringen kann. Würde auch hier die Verdichtung der beteiligten Tabellen den Langläufer beschleunigen?

Ich testete ihn also in zwei Datenbanken, eine davon enthielt die Tabellen in komprimierter Form. Anfangs wies db2batch für die Query mehr als 200 Sekunden aus, mit teilweise signifikant besseren Werten für die Variante mit den Komprimanten. Aber eben nur teilweise.

Um vertrauenswürdigere Daten zu bekommen, ließ ich die Abfragen mehrfach mit anderen Abfragen in kontrollierter Form ablaufen. Ich rechnete also mit langem Warten auf die Ergebnisse. Doch, Überraschung, nach einigen Sekunden war alles vorbei.

Was bisher geschah:

• Die Tabellen einer MS-Access-Anwendung sind zu groß geworden für die Jet-Engine. DB2 ist die Wahl der Stunde für die Datenhaltung als skalierbare, performante und vertrauenswürdige Basis.
  
• Tabellendefinitionen und Daten lassen sich manuell oder per VBA-Routine nach DB2 transportieren.
  
• Auch die Anlage von Indizes und Schlüssel in der Zieldatenbank kann automatisiert werden.
  

Es bleibt die Aufgabe, die DB2-Tabellen an die Anwendung anzubinden. Dies geht unter Access natürlich nach rechtem Mausklick unter Tabellen mit "Tabellen verknüpfen ..." für jede einzelne Tabelle. Bei vielen Tabellen gerät das zu einer gesundheitsgefährdenden Klickerei. Aber auch hier lässt sich der Prozess wie folgt automatisieren

Beim Abbilden von Indizes und Integritätsbedingungen aus Tabellen, die unter Access mit der Jet-Engine erstellt wurden, sind leider noch folgende Unebenheiten zu beachten:

Unter Access ist es möglich, Spalten als Primärschlüsseln zu erklären, die laut Definition Nullwerte enthalten können. Das ist schon was Besonderes, denn nicht mal der SQL-Server erlaubt das. Keine vernünftige Datenbank lässt diesen Unsinn zu, also auch DB2 nicht.

Das hat allerdings die unangenehme Konsequenz, dass der Versuch der beschriebenen automatischen Anlage eines Primärschlüssels auf eine Spalte, die laut Definition im Access Nullwerte enthalten darf, nicht möglich ist. Am Besten definiert man die Tabellen gleich standardgemäß oder korrigiert diese Nachlässigkeit noch vor dem Export der Tabelle.

Falls dies aus irgendeinem Grunde nicht möglich ist, bleibt noch die Möglichkeit, in der DB2 Steuerzentrale die Definition solch einer Spalte zu ändern bevor sie zum Primärschlüssel erhoben wird. Bei vielen Änderungen dieser Art geht das auch per Script, die Änderungsanweisung ist allerdings recht unhandlich.

Übrigens: Auch Access kann keine Wunder vollbringen und aus sinnvollen Einschränkungen sinnlose Erweiterungen machen. Jeder Versuch, einen Nullwert in einen Primärschlüssel einzugeben, wird mit einer Fehlermeldung bestraft. Warum man allerdings bei der Definition einer Tabelle solche einen Quatsch zulässt, bleibt mir unerschlossen.

Per Mausklicks, Makro oder VBA-Routine lassen sich in der Jet-Engine unter MS Access gespeicherte Tabellen wie beschrieben leicht nach DB2 migrieren. Eine Datenbank besteht aber nicht nur aus einer zusammenhanglosen Ansammlung von Tabellen. Die Access-Exportfunktion transportiert eigentlich nur Struktur und Daten von A nach B, ignoriert aber Indizes, Primär- und Fremdschlüssel.

Ohne ihn jemals angewandt zu haben, bin ich mir sicher, dass MS mit seinen Upsizing-Agenten auch diese Datenbank-Objekte migriert. Leider eben nur auf den SQL-Server. Als Strafe dafür, dass ich die schöne neue MS-Welt frevelhaft verlassen will, muss ich leider eine Extrarunde programmieren. Aber danach lassen sich auch Indizes und Schlüssel nach DB2 portieren.

Dazu muss ich nur die TableDef-Objekte ausbeuten, so wie ich es für die Export-Routine für alle Tabellen meiner Access-Anwendung getan habe - eigentlich nur eine Schleife um "DoCmd.TransferDatabase". Mit diesem Kommando übertrage ich Struktur und Daten einer Tabelle, das ist dann aber auch schon alles. Beim Transfer von Indizes oder Integritätsbedingungen helfen wieder die TableDef-Objekte. Hier finde ich die Eigenschaften, die ich zur Erstellung geeigneter "create index" oder "alter table" benötige.

Für meine VBA-Exportroutine sieht das im Wesentlichen so aus:

MS Access wird gern als Prototyping-Werkzeug oder als Umgebung für die schnelle Entwicklung von Datenbankanwendungen unter Windows genutzt. Aber oft bleibt es nicht beim Prototyp und die schnell entwickelte Einzelplatzanwendung hat urplötzlich viele Nutzer. Wenn einem dann die Anwendung um die Ohren fliegt, erfährt man, dass Access keine solides Basis für skalierbare Anwendungen bietet.

Das gilt vor allem für die einer Access-Anwendung zugrunde liegenden Datentabellen, soweit sie in der Jet-Engine verwaltet werden. Je größer die benötigten Tabellen, je mehr darauf zugreifende Nutzer, desto notwendiger wird ein Wechsel auf eine solide Datenbank.

Wenn es nach Microsoft ginge, führte der Upsizing-Pfad geradewegs zum SQL Server. Es gibt aber bessere Alternativen, die MS natürlich nicht mit einem Upsizing-Agenten (Extras/Datenbank Dienstprogramme) unterstützt. Trotzdem ist eine Migration der Daten nach DB2 mittels ODBC oder OLE DB eine einfache, gut automatisierbare Aufgabe. Die wesentlichen Schritte werden bestens in "Migrating a Microsoft Access 2000 Database to IBM DB2 Universal Database 7.2" beschrieben. Auch wenn "2000" und "7.2" nicht gerade up-to-date klingt, es funktioniert auch mit aktuelleren Versionen.

Von "Multi-row Fetch" oder "Multi-row Insert" hatte ich bisher nichts gehört, bis mich David fragte mich heute morgen danach fragte. Ein APL2-Fan wünscht sich wohl, dass der AP127 diese DB2-Features nutzt. Recht hat er.

Seit der Version 8 bietet die Programmierschnittstelle der DB2 für z/OS die Möglichkeit, mit nur einem Fetch auf mehr als nur eine Zeile des Resultsets zuzugreifen. Eine sehr sinnvolle Erweiterung, die mit der Version 8.2 dann auch für andere DB2-Plattformen zur Verfügung gestellt wurde. Es liegt wohl nur an der Beschränkheit der Mainstream-Programmiersprachen, dass obwohl ein SQL-Select eine Menge von Tabellenzeilen als Ergebnis ergibt, aber auf Elemente dieser Menge nur einzeln zugegriffen werden kann - Zeile nach Zeile per Schleife.

Für APL mit seiner hervorragenden Fähigkeit, komplette Datenstrukturen verarbeiten zu können, stellt diese Einschränkung eher einen ärgerlichen Logikbruch dar. Nur gut, dass mit dem AP127 per Parameter für den Fetch mehrere Ergebniszeilen mit einer Anweisung zum APL2 übertragen werden können.

Und hier ist die Theorie zur Praxis:

DB2 Explain schätzt für das teuerste Test-Select auf die umdefinierte Tabelle in unkomprimierter bzw. komprimierter Form folgende den Aufwände:

	unkomprimiert	zeilenkomprimiert
Gesamtaufwand	111.757,9453125000 Timeron	49.764,9921875000 Timeron	45%
CPU-Aufwand	6.189.640.704 Anweisungen	7.847.347.712 Anweisungen	127%
Ein-/Ausgabeaufwand	107.542 E/As	44.191 E/As	41%
Aufwand der ersten Zeile	1.755,8646240234 Timeron	786,0233154297 Timeron	44%

Danach wäre der Aufwand für die Ausführung des analysierten Selects für die verdichtete erheblich niedriger. Auf den ersten Blick passt das nicht so richtig zur Praxis, die bestenfalls einen Gleichstand ergab.

Bei näherem Hinsehen wird klar, dass der Gesamtaufwand nahezu komplett durch den geschätzten I/O bestimmt wird. Eine Verringerung des I/O bewirkt fast 10-mal stärker eine Reduzierung des Gesamtaufwandes als eine entsprechende Verminderung der CPU-Anweisungen. Das begründet große Performance-Vorteile für Zugriffe auf stark komprimierbare Tabellen.

Für unkomprimierte Tabellen, die komplett in den Buffer passen, entfällt der Aufwand für I/O. Dagegen entsteht für den Zugriff auf das (ebenfalls komplett im RAM abgelegte) komprimierte Analogon ein zusätzlicher CPU-Aufwand durch Dekomprimierung, der nun ungebremst zu einer entsprechenden Erhöhung des Gesamtaufwandes führt.

Die Theorie zeigt also, dass sich in besagter Praxis die Select-Anweisungen hauptsächlich aus dem Buffer bedient haben müssen.

Übrigens: der Aufwand für E/A entspricht hier der Größe der jeweiligen Tabelle in Anzahl 4K-Pages (npages).

Man kann eben nicht alles haben.

Die gleichen Performance-Vergleiche, die ich für die Original-Tabelle und ihr komprimiertes Abbild durchgeführt habe, habe ich auf die beiden umdefinierten Tabellen angewandt. Ich konnte keinen signifikanten Unterschied feststellen, egal in welcher Reihenfolge ich sie abgespielt habe.

Wenn überhaupt eine leichte Differenz zu erahnen ist, dann zuungunsten der komprimierten Variante. Mag sein, dass in beiden Fällen die Selects sich im Wesentlichen aus dem Buffer bedienen, also kaum teuren I/O produzieren. Für die Ergebniszeilen der komprimierten Tabelle kommen zusätzlich noch die CPU-Zyklen für die Dekomprimierung hinzu.

Das mag den - wenn überhaupt - kleinen, nicht signifikanten Unterschied erklären.