Datenbanken

Es war ein wenig überraschend, wie einfach sich das neue Data Studio installieren ließ. Die ganze Prozedur hat summa summarum wohl nicht mehr als eine halbe Stunde gekostet, und es wurden nicht nur eben mal 10 MB Software installiert.

Die Installationsquellen beanspruchen entpackt immerhin 650 MB, nach erfolgter Erstinstallation hat man ca. 600 MB mehr Software auf der Platte. Darin versteckt sich mehr als nur das Data Studio, denn zusätzlich werden noch ein Installation Manager und Masse gemeinsam genutzter Dateien übertragen. Beides wird mir hoffentlich bei zukünftigen Installationen wie auch immer zugute kommen.

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.

Bis kurz vor Ende lief alles ganz gut mit dem Artikel über die angekündigte Informix-Appliance. Aber dieser letzte Satz, musste der sein?

"Diese Rolle war jedoch umstritten, da IDS gegenüber der DB2-Entwicklung ein Schattendasein fristete und das mit Version 10.0 eingeführte letzte größere Update schon seit Februar 2005 zurückliegt."

Welche "Rolle" ist hier eigentlich unerheblich, die Begründung allerdings ist sehr fragwürdig.

Die Annahme des "Schattendasein" von IDS gegenüber DB2 mag eine Zeit lang als nicht völlig unbegründet gegolten haben, ist allerdings inzwischen widerlegt. Heute klingt eine solche Behauptung wie Oracle-Propaganda.

Richtig kraus ist die Begründung mit einer zweijährigen Wartezeit für die kommende IDS-Version. Ja, es gibt Software, für die es jährlich (oder häufiger) ein Update gibt. Es gibt aber auch Beispiele mit regelmäßig längeren Zyklen. Windows Betriebssysteme sind prominente Beispiele. Die Spanne zwischen XP und Vista beträgt immerhin mehr als 5 Jahre.

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.

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.

Nachdem meine erste Zeilenkomprimierung einer Tabelle eine hohe Verdichtungsrate aufgrund suboptimalen Designs erbrachte, fragt sich nun, ob der Tabelle mit verbesserter Definition ein ähnlich hohes Sparpotenzial innewohnt.

Natürlich konnte ich nicht wieder 78% erwarten, aber die Vorhersage (inspect rowcompestimate) war dennoch erfreulich:

Prozentsatz der durch die Komprimierung gesparten Seiten: 58
Prozentsatz der durch die Komprimierung gesparten Byte: 58
Prozentsatz der Zeilen, die wegen geringer Zeilengröße nicht für die Komprimierung ausgewählt werden können: 0
Größe des Komprimierungswörterverzeichnisses: 45824 Byte.
Größe des Erweiterungswörterverzeichnisses: 32768 Byte.

Also weniger als die Hälfte des Platzes der unkomprimierten Tabelle, nicht schlecht!

Und tatsächlich: Statt 107541 4K-Seiten belegt die Tabelle nach "alter table ... compress yes" und dem Reorg nur noch 44171 Seiten. Dies ist eine Verdichtung auf 41%.

Die Prognose durch rowcompestimate war wieder sehr treffend. Man kann sich wohl darauf verlassen.