Abbildung 1: Auf einem Rechner können mehrere DB2-Instanzen laufen. Jede Instanz enthält Nodegroups, die wiederum Table Spaces enthalten, in denen dann die Datenbanktabellen liegen.

In der leistungsstarken und gut bezahlten Bundesliga der Datenbanken spielen nur wenige Anbieter mit. Die Oracle Kickers gelten als Top-Favoriten, aber IBM ist mit der DB2 auf dem Weg, der Tabellenführer zu werden.

Angeblich sind weltweit bis zu 60 Prozent der gespeicherten Daten in IBM-Datenbanken abgelegt. Mit dem Kauf von Informix werden es noch einige mehr sein.

Die meisten Daten liegen in den Mainframe-Systemen IMS und DB2. Doch die DB2 gibt es seit langem auch für die Midrange-Systeme AIX und OS/400. Auch OS/2 war eine Plattform für IBMs relationales Datenbanksystem. Portierungen auf weitere Unixe und auch auf manches Windows machen die Datenbank plattformunabhängig.

Die Portierung auf Linux ist schon eine ganze Weile her: Sie fand überraschend früh statt, bereits am Anfang des vor mehr als zwei Jahren einsetzenden Linux-Booms. Für die Datenbankfraktion war es einfach eine Plattform mehr, und weil DB2 schon auf anderen Unix-Systemen lief, war auch die Portierung selbst kein großes Problem. Neben Linux auf x86-Prozessoren läuft DB2 unter Linux zurzeit auch auf S/390 (32 Bit) und zSeries (64 Bit).

Damit hat IBM auf seinen Mainframes eine ganze Reihe von DB2-Varianten im Angebot. Aber trotz ihrer großen Verbreitung in der klassischen IT, hatte es diese Datenbank schwer, bei Midrange- und x86-Servern Fuß zu fassen. Zwei Nachteile spielten zusammen: eine komplizierte Installation und ein im Vergleich zur Konkurrenz sehr eingeschränkter Funktionsumfang. Beides hat sich mit der Zeit geändert, wie der Beitrag zeigt, doch nichts ist schwerer, als einen schlechten Ruf loszuwerden.

Dieser Artikel wird in den folgenden Abschnitten zuerst in die Konzepte der Datenbank einführen und danach die Installation besprechen. Einen weiteren Bereich streift der Artikel nur kurz: DB2 aus Sicht der Anwendungsentwicklung. Auf eine Reihe von Goodies, die DB2 insbesondere für Java-Entwickler bereithält, geht dann der Coffee-Shop im nächsten Linux-Magazin näher ein.

Die DB2-Produktlinie

DB2 gibt es in verschiedenen Paketen zu kaufen. Unter Linux sind die folgenden Produkte verfügbar:

• DB2 Personal Edition enthält eine Single-User-Lizenz sowie den Application Development Client.
• DB2 Workgroup Edition ist die Multi-User-fähige Datenbank. Zusätzlich zu den Features der Personal Edition enthält sie noch die Zugriffsmöglichkeit über das Web sowie den Websphere Application Server. Client-Lizenzen müssen zusätzlich erworben werden.
• DB2 Enterprise Edition hat keinerlei Beschränkungen hinsichtlich der Anzahl an Clients. Sie enthält die notwendige Funktionalität für den Zugriff auf Mainframe-DB2-Systeme (DB2-Connect).
• Inzwischen ist auch die DB2 Enterprise Extended Edition verfügbar, nur nicht für Linux auf S/390 und zSeries. Sie bietet zusätzlich die Unterstützung für SMP- und MPP-Rechner sowie Cluster von SMP-Rechnern.

Neben den regulären Produkten gibt es die Personal und die Workgroup Edition außerdem in Form von Developer’s Editions. Diese enthalten zusätzlich noch DB2-Connect sowie Visual Age for Java in der Entry- oder der Professional Edition. Die DB2 Personal Developer’s Edition steht auch zum kostenlosen Download bereit – und sie ist auch nicht laufzeitbeschränkt. Die Enterprise Edition kann in einer auf 90 Tage beschränkten Version heruntergeladen werden. Wem der Download zu lange dauert, kann die PDE auch gegen eine Gebühr von 37 US-Dollar bestellen. Das Paket enthält 20 CDs, da Versionen für alle Plattformen enthalten sind.

Instanzen, Datenbanken und Tabellen

Wie ist eine DB2-Datenbank aufgebaut? Eine in sich abgeschlossene Datenbankumgebung heißt Instance. Sie hat eigene Tabellen, Konfigurationen und Benutzerrechte. Es ist möglich, auf einem System mehrere Instanzen zu fahren, etwa für Test und Produktion. In diesem Fall es ist möglich, Datenbank- und Tabellen-Namen, Benutzer und Benutzerrechte identisch zu lassen, was die Anwendungsentwicklung erleichtert.

In jeder Instanz wiederum gibt es eine oder mehrere Datenbanken. Eine Datenbank besteht aus einer Sammlung von Tabellen, den zugehörigen Systemtabellen (System Catalog Tables) und dem Recovery-Log, das die gerade laufenden Transaktionen speichert. Ein Objekt der Datenbank ist das so genannte Schema, dessen Aufgabe es ist, Tabellen und andere Datenbank-Objekte (beispielsweise Trigger) zu gruppieren. Schemas dienen auch dazu, Zugriffsrechte auf niedrigerer Ebene als auf Datenbank-Ebene zu definieren.

Unterhalb der Datenbank gibt es das Konstrukt der Nodegroup. Jede Nodegroup enthält eine oder mehrere Datenbank-Partitionen. Das Partitionieren von Datenbanken ist eine Möglichkeit, die Daten physikalisch über mehrere Systeme zu verteilen und damit die Performance zu steigern. Bei ungünstiger Verteilung kann dieses Verfahren allerdings auch das Gegenteil bewirken, wenn beispielsweise Tabellen, die regelmäßig per Join verknüpft werden, in unterschiedlichen Partitionen liegen.

Tabellen, Indizes und Views (Tables, Indexes, Views) müssen hier nicht näher erläutert werden. Der Begriff Table Space aber schon: Er ist ein logischer Name für einen physikalischen Ort, an dem die Tabellen, Indizes, (B)LOBs und so weiter gespeichert werden. Um die Performance zu erhöhen macht es Sinn, Systemtabellen und Indizes eigene Table Spaces zuzuteilen. Die Verknüpfung vom Table Space zur realen Welt der Speicherhardware erfolgt über Container, das sind entweder Verzeichnisse, Raw Devices oder von DB2 verwaltete Dateien fester Größe.

Wer dies alles sehr komplex findet, hat natürlich Recht. Aber nur über solche Mechanismen ist es möglich, sehr große Datenbanken mit komplizierten Abfragen performant zu betreiben. Das Lesen und Schreiben von Daten durch die Filesystem-Schicht zu schleusen ist nicht so performant wie Raw Devices, die direkt von der Datenbank verwaltet werden. Und ein geschicktes Aufteilen von Tabellen auf unterschiedliche Container auf verschiedenen Platten kann wahre Wunder wirken.

Ein weiteres wichtiges Element für das Design einer DB2-Umgebung ist der Buffer Pool. Das ist reservierter Hauptspeicher, der für das Cacheing von Table Spaces genutzt wird. Hier gilt im Prinzip: viel hilft viel, aber trotzdem macht es keinen Sinn, Speicher wahllos zu verschwenden. Besser ist es, nur jene Table Spaces zu cachen, die häufig benötigte Daten enthalten.

Eine Übersicht und Zusammenfassung der verschiedenen Objekte ist in Abbildung 1 zu sehen. Einer der großen Vorteile der DB2 wird daraus schon sichtbar: die Skalierbarkeit auf verschiedenen Ebenen. Die Verwendung von getrennten Table Spaces optimiert letztlich den Festplatten-Durchsatz, und Datenbankpartitionen können die Rechenleistung verschiedener Computersysteme nutzen.

Wer darf was?

Eine Datenbank sollte ihre Daten nicht wahllos jedem zur Verfügung stellen, der sich dafür interessiert. Die zwei zentralen Begriffe sind hier Authentifizierung und Autorisierung. Ersteres ist die korrekte und sichere Identifikation des Benutzers. Sie ist außerhalb von DB2 Aufgabe des Betriebssystems. DB2 nimmt folglich an, dass ein erfolgreich angemeldeter Benutzer bereits entsprechend verifiziert wurde.

Intern wird die User-ID auf eine DB2-Authid umgesetzt. Das geschieht durch die Umwandlung in Großbuchstaben. Ebenso werden Group-IDs zu Authids. Die Autorisierung selbst erfolgt DB2-intern. Sie wird in den Systemtabellen und in Konfigurationsdateien abgelegt. DB2 unterscheidet hierbei zwischen Privileges und Authority Levels. Letztere fassen eine Gruppe von Privileges zusammen.

Die höchste Instanz ist SYSADM, gewissermaßen der Root-Account des DB2-Systems. Unterhalb von SYSADM gibt es SYSCTRL und SYSMAINT, die ähnliche Rechte haben, aber nicht direkt auf die Daten innerhalb der Datenbanken zugreifen dürfen. Ein weiterer Level ist DBADM, er wird pro Datenbank vergeben. In großen Installationen ist es also möglich, die Rechte nur für spezifische Datenbanken zu vergeben.

Die eben beschriebenen Authority Levels werden über Linux-Gruppen definiert. Eine Ausnahme ist die Spezialgruppe PUBLIC, die allgemeine, datenbankbezogene Rechte hat. Diese DB-bezogenen Rechte können wiederum sehr detailliert vergeben werden, zur Auswahl stehen etwa CONNECT, CREATETAB und LOAD.

Auch bei den Rechten besteht also die Möglichkeit, sehr viel zu konfigurieren. Für den Einstieg ist oft weniger mehr; in einer Produktionsumgebung wird man aber bei personenbezogenen Daten schon durch den Gesetzgeber gezwungen den Zugriff auf die Daten zu schützen. Root oder nicht Root ist in diesem Fall also eine viel zu einfache Frage: Ein Benutzer sollte laut Zugriffsregeln nur das können, was er auch darf, etwa nur bestimmte Tabellen lesen oder ändern.

Abbildung 1: Auf einem Rechner können mehrere DB2-Instanzen laufen. Jede Instanz enthält Nodegroups, die wiederum Table Spaces enthalten, in denen dann die Datenbanktabellen liegen.

Abbildung 2: Die DB2-Installation mit db2setup geschieht über ein Text-Interface. Hier wird die DB2 Enterprise Edition installiert, mit Customize lassen sich deren Bestandteile auswählen.

Abbildung 3: Die optionalen Bestandteile lassen sich während der Installation mit db2setup auswählen. Hier wurde das Control Center von der Installation ausgeklammert.

Funktionen über Funktionen

DB2 wurde schon immer wegen der Stabilität und Performance geschätzt, allerdings war der Funktionsumfang lange Zeit eher mager. Trigger etwa waren bei anderen Datenbanken bereits lange Standard, bevor sie auch in DB2 implementiert wurden.

Bei der Funktionalität hat DB2 jedoch inzwischen aufgeholt, wenn auch nach wie vor Stabilität und Performance vor Ausstattungsmenge gehen. Im Gegensatz etwa zu den aktuellen Oracle-Versionen hat DB2 keine eingebaute Java Virtual Machine. Aber das sind Randbereiche, die nur für ausgesuchte Anwendungsgebiete wichtig sind.

Bei den klassischen Funktionen sind Views, Trigger, User Defined Functions und User Defined Types zu nennen. Für Letztere gibt es auch ein Type-Mapping, um User Defined Types auf andere Typen abzubilden – etwa auf Typen von Oracle-Datenbanken, auf die über Federated Systems zugegriffen wird. Auch Stored Procedures sind verfügbar. Sie laufen im Kontext der Datenbank, sind also unabhängig von der Anwendung und sehr performant. Aus Sicherheitsgründen können (und sollten) diese Stored Procedures unter einer eigenen User-ID ausgeführt werden, damit ist eine ungewollte Zerstörung der DB2-Umgebung ausgeschlossen (Fenced Stored Procedures).

Für Spezialgebiete gibt es Extender, die die Funktionalität des Systems erweitern. Hier seien etwa Data-Warehousing, Spatial Extenders (für GIS-Daten, also geographische Informationssysteme) und der XML-Extender genannt. Letzterer kann für Linux von der DB2-Website heruntergeladen werden und erlaubt die direkte Speicherung von XML-Dokumenten in DB2.

Ein weiterer Aspekt sei hier nur am Rande erwähnt: DB2 erlaubt den gleichzeitigen Zugriff auf Tabellen in verschiedenen Datenbanken, sogar zwischen DB2 und Oracle. Diese Federated Systems sind für den Benutzer transparent.

DB2 ermöglicht auf Instanz-Ebene die Überwachung (das Auditing) der Datenbankzugriffe. Das Sammeln dieser Informationen ist dann sinnvoll, wenn es vom Gesetzgeber oder von der internen Revision gefordert wird oder wenn ein unberechtigter Zugriff festgestellt werden soll.

Verschiedene Events lassen sich gezielt aufzeichnen, beispielsweise VALIDATE für die Benutzer-Authentifikation. Hier könnte bei einer wiederholt gescheiterten Validierung der Versuch vorliegen, in das System einzudringen.

Backup und Recovery

Neben der Sicherheit spielt die Stabilität eine wichtige Rolle, insbesondere die Unterstützung von Crash-Recovery. In diesem Fall ist die Datenbank inkonsistent. Die dann fälligen Restarts können unter DB2 automatisch geschehen. Operationen, die nicht mit Commit abgeschlossen wurden, werden dann vom DB-Manager zurückgenommen.

Auch das komplette Backup und Restore von Datenbanken auf verschiedene Medien wird unterstützt. Linux-spezifische Optionen bei der Verwendung von SCSI-Tapes sind im Administration Guide dokumentiert. Bei Datenbanken, die Raw Devices nutzen, sind spezielle Backup-Funktionen notwendig: Tar oder Cpio benötigen ein Filesystem, das hier ja gerade umgangen wird.

Tuning

Traditionell stark ist DB2 beim Tuning des Systems. Es kann auf zwei Ebenen geschehen. Einmal auf der Systemebene: Hier wird die Datenbank geschickt partitioniert und die Table-Space-Organisation und die Instanzparameter werden abgepasst. Das sollte allerdings nur nach einer Kosten-Nutzen-Abwägung geschehen: Es macht wenig Sinn, viel Zeit (und damit Geld) in die Optimierung zu stecken, wenn eine einfache Hardware-Aufrüstung denselben Zweck günstiger erfüllen könnte.

Die zweite Optimierungsebene ist die Anwendungsseite. Hier beeinflusst die Wahl geeigneter Locking-Mechanismen und Isolation Levels die Performance. Darüber hinaus hat DB2 einen sehr guten Query-Optimizer. Um diesen Optimizer zu unterstützen, können Datenbank-Statistiken über ein mitgeliefertes Tool gesammelt werden. Das ist immer dann sinnvoll, wenn sich ein größerer Teil der Daten geändert hat.

Ein weiteres wichtiges Tool ist Explain. Es erlaubt den Blick auf die vom SQL-Optimizer erzeugten Zugriffspläne. Damit ist unter anderem ersichtlich, ob die definierten Indizes überhaupt verwendet werden.

# su - db2inst1 -c"db2start"
# su - db2as -c"db2admin start"

# su - db2inst1 -c"db2stop"
# su - db2as -c"db2admin stop"

db2prod 50000/tcp

# db2 catalog tcpip node db2pnode 
 remote arcturus server db2prod

# db2 catalog database sample 
 as arc_smp at node db2pnode

# db2 connect to arc_smp user db2inst1 
  using password xxxx
# db2 "select * from employee"
# db2 terminate

APIs für alle

Egal wie schnell eine Datenbank ist, ohne einen Client macht sie wenig Sinn. Abhängig von der verwendeten Plattform unterstützt DB2 hierfür unterschiedlichste Programmiersprachen: von Fortran über Cobol bis Perl. Für Linux gibt es APIs für C, C++, Perl und Java. Der Perl-Treiber DBD::DB2 steht auf der DB2-Website zur freien Verfügung. Er arbeitet mit dem Perl Database Interface (DBI) zusammen. Verschiedene Tools für alle Programmiersprachen einschließlich Beispielen sind in der Personal Developer’s Edition von DB2 enthalten.

* Product Installation
* --------------------
INSTALL_SOURCE_PATH    = /cdrom/db71uxen/db2/
PROD                  = UDB_ENTERPRISE
COMP                  = JAVA_SUPPORT
*COMP                 = DISTRIBUTED_JOIN_FOR_DB2
*COMP                 = WAREHOUSE_CONTROL_DATABASE
*COMP                 = REPLICATION
*
* Instance Creation Settings
* --------------------------
DB2.USER_NAME         = db2inst1
DB2.GROUP_NAME        = db2iadm1
DB2.HOME_DIRECTORY    = /home/db2inst1
DB2.PASSWORD          = xxxx
DB2.AUTHENTICATION    = SERVER
DB2.SAMPLE            = NO
DB2.AUTOSTART         = NO
DB2.SVCENAME          = db2cdb2inst1
DB2.PORT_NUMBER       = 50000
* Fenced User Creation Settings
* -----------------------------
UDF.USER_NAME         = db2fenc1
UDF.GROUP_NAME        = db2fadm1
UDF.HOME_DIRECTORY    = /home/db2fenc1
UDF.PASSWORD          = yyyy
* Administration Server Creation Settings
* ---------------------------------------
ADMIN.USER_NAME       = db2as
ADMIN.GROUP_NAME      = db2asgrp
ADMIN.HOME_DIRECTORY  = /home/db2as
ADMIN.PASSWORD        = zzzz

Die Installation – kein Hexenwerk

Nach diesem Überblick über die Funktionalität von DB2 geht es an die Praxis. Die Installation ist inzwischen kein Problem mehr, die unterschiedlichen Verfahren ließen sich problemlos unter SuSE 7.x und Mandrake 8.0 durchführen. Es ist tatsächlich so, dass nach wenigen Minuten das erste lauffähige DB2-System steht.

Die Installation wurde mit der Personal Developer’s Edition 7.1 und mit der Trial-Version der Enterprise Edition 7.1 getestet. Brandaktuell wäre die Version 7.2, aber die entsprechenden Medien standen zum Test nicht zur Verfügung und laut Dokumentation auf der DB2-Website hat sich auch nichts Wesentliches geändert. Die SuSE 7.2 Professional enthält übrigens die komplette DB2 Personal Developer’s Edition, Version 7.1.

Wer die SuSE-Version hat, findet nach dem Einspielen des entsprechenden RPMs ein Readme unter /usr/share/doc/packages/db2pe, das den weiteren Ablauf erläutert. Das SuSE-RPM kopiert nämlich nur die Produktdateien auf die Festplatte, die eigentliche Installation der DB2 findet nicht statt. SuSE liefert aber ein Skript mit, das die Installation automatisiert.

Ein Nachteil des SuSE-Skripts ist, dass es eine komplette Installation des gesamten Produkts durchzieht. Damit landen auch so spezielle Teile wie die Codepage-Konvertierungstabellen für Japanisch, Koreanisch und Chinesisch auf der Festplatte. Die eigentliche Produktdokumentation wird jedoch nicht entpackt: Das dafür vorgesehene Kommando muss von Hand ausgeführt werden.

Sinnvoller als das SuSE-Setup ist die Installationsroutine, die von IBM mitgeliefert wird: Das db2setup hat ein reines Textmode-Interface (siehe Abbildungen 2 und 3). Es ist nicht gerade schön zu nennen, aber es ist funktionell und tut seinen Dienst. Wer das SuSE-RPM installiert hat, sollte aber vorher aus /etc/passwd und /etc/group die entsprechenden Einträge der DB2-Benutzer und -Gruppen entfernen, sonst kommt das Setup-Programm ins Schleudern.

Optional in db2setup ist die Möglichkeit, DB2 jeweils beim Start des Systems hochzufahren. Von dieser Option sollte man aber absehen, da sonst direkt in etc/inittab ein Once-Eintrag zum Start der DB2 erscheint. Sinnvoller wären jedoch entsprechende Runlevel-Skripte.

IBM liefert eine Beispiel-Datenbank mit. Mit dieser DB kann sehr schnell verifiziert werden, ob die Installation erfolgreich ausgeführt ist. Sie dient außerdem dazu, sich schnell mit den verschiedenen DB2-Tools vertraut zu machen. Installiert wird sie entweder über die entsprechende Setup-Option oder nachträglich mit dem Skript db2sampl.

Eine komplette Beispiel-Installation ist im Kasten “Client- und Server-Installation bei DB2” beschrieben. Dabei wird aber auf Tuning-Maßnahmen verzichtet. Auf die Installation einer eigenen Datenbank einschließlich der Einrichtung von Table Spaces geht dann der Coffee-Shop im nächsten Linux-Magazin ein.

Abbildung 4: Die grafische Oberfläche DB2 Control Center bietet alle Funktionen, die auch als Kommandozeilenprogramm vorhanden sind.

Im Hintergrund

Es ist schon ärgerlich, dass automatische Installationen völlig undurchsichtig ablaufen. Bei normalen Anwendungspaketen mag das noch angehen. Bei einer kritischen Komponente wie einer Datenbank-Engine sollte aber mehr Klarheit herrschen. Deshalb folgt hier eine kleine Übersicht, was bei den einzelnen Installationsschritten geschieht.

Alle Produktdateien landen unter /usr/IBMdb2/V7.1/. Hier finden sich unter dem bin-Verzeichnis die entsprechenden DB2-Utilities. Neben dem Kopieren der Produkte wird auch eine Datenbank-Instanz angelegt. Der Name der Instanz ist identisch mit der User-ID des Instanz-Owners. Default ist hier für die erste Instanz db2inst1. Ein weiterer Benutzer, unter dessen ID die Fenced Stored Procedures und die User Defined Functions ablaufen, sollte auch vor der Erzeugung der Instanz angelegt sein. Default für diesen Benutzer ist db2fenc1.

Eine weitere Komponente ist der Administration Server, der – wie der Name sagt – für administrative Aufgaben notwendig ist. Der entsprechende User heißt db2as, seine Gruppe db2asgrp.

Der Quick Beginnings Guide for Linux enthält ein Arbeitsblatt, in dem Werte für alle Konfigurationsoptionen eingetragen werden können. Das erleichtert die spätere Installation dann erheblich, falls von den Defaults abgewichen werden sollte. Insbesondere bei den Passwörtern ist das Abweichen vom Default dringend zu empfehlen – leider kommt es immer wieder vor, dass irgendwelche Produkte mit den Defaults installiert werden und dann riesige Sicherheitslücken im System klaffen.

Response-Dateien

Neben der manuellen Installation, die gleichzeitig auch die DB2-Instanz und deren Benutzer definiert, gibt es auch eine automatische Installation: Sie wird über eine Konfigurationsdatei gesteuert, die IBM als Response File bezeichnet. Für produktive Systeme ist dies dringend anzuraten, da die Response-Dateien die Installation sauber dokumentieren und im schlimmsten Fall die DB2 in einem definierten Zustand wiederherstellbar ist. Leider liefert IBM den Response-File-Generator db2rspgn nur für OS/2- und Win32-Systeme mit. Der Generator erzeugt für die aktuelle Installation ein entsprechendes Response-File (Listing 1 enthält ein Beispiel). Da Beispieldateien mitgeliefert werden, ist das Anpassen kein großes Problem.

Starten, Stoppen, Administrieren

Die Kommandos zum Starten und Stoppen des fertig installierten DB2-Systems sind im Kasten “Client- und Server-Installation bei DB2” näher erläutert. Diese Kommandos gehören normalerweise in ein Start-Stop-Skript, das für die verwendete Linux-Distribution anzupassen ist.

Laufen die Datenbank-Instanz und der Administrationsserver, kann DB2 von jeder Workstation aus administriert werden, auf dem der Administrations-Client installiert ist. Als grafisches Front-End ist das DB2 Control Center vorhanden (siehe Abbildung 4). Über diese Oberfläche sind alle Kommandos verfügbar, die auch über Kommandozeilenprogramme ausführbar sind – in gewisser Weise ist das Control Center also überflüssig. Insbesondere in produktiven Umgebungen gilt die Manipulation über grafische Oberflächen sowieso als ziemlich problematisch und von zweifelhaftem Wert.

Wer das Control Center trotzdem nutzen will, stößt erst mal auf Probleme. Es handelt sich hier um eine Java-Applikation, die die veraltete IBM-Java-Version 1.1.8 zwingend voraussetzt. IBM investiert zwar Unsummen in Java, aber offensichtlich schafft die Firma es nicht, einen Java-Experten nach Toronto ins DB2-Labor zu schicken, um bei der Portierung auf Java 1.3 zu helfen.

Dummerweise liefern weder IBM noch SuSE die passende Java-Version mit. Das ist um so weniger verständlich, als die richtige Version beim Websphere Application Server enthalten ist. Wer also zufällig dieses Produkt besitzt, der kann sich dort bedienen, andernfalls ist ein längerer Download fällig.

Nach der Installation der Java-Runtime bleiben noch zwei Hürden zu überwinden: Die Umgebungsvariable LANG darf nicht gesetzt und die DB2-JDBC-Ladebibliotheken müssen im LD_LIBRARY_PATH enthalten sein.

Wer keine Angst vor der Kommandozeile hat, kann sich diese Klimmzüge sparen. DB2 enthält sehr viele Tools für die Administration. Sie sind im Administrator’s Guide hervorragend erläutert und in der Command Reference exakt dokumentiert, so dass keine Fragen offen bleiben sollten.

Vorbildliche Dokumentation

Damit wurde schon ein weiterer Schlüsselfaktor für den erfolgreichen Einsatz der DB2 angesprochen. Das Produkt kommt mit einer ausführlichen, klaren und umfassenden Dokumentation (in HTML), die alle Wünsche erfüllt und als vorbildlich anzusehen ist. Sie ist unterteilt in verschiedene Bücher, die auf einer separat erhältlichen Dokumentations-CD im PDF-Format enthalten sind. Sie sind bei IBM aber auch als gedruckte Ausgaben zu haben.

Die Dokumentation gliedert sich in mehrere Hauptgruppen, darunter “Installation and Configuration”, “Administration” und “Application Programming”. In der ersten Gruppe ist besonders das Dokument “Linux Quick Beginnings” sehr nützlich, um schnell zu einer lauffähigen Installation zu kommen.

Ein weiteres Dokument ist noch hervorzuheben, da man es eigentlich bei einem solchen Produkt nicht erwarten würde. Das Buch “SQL Getting Started” enthält einen Crash-Kurs in SQL, einschließlich der Konzepte rund um relationale Datenbanken – sicherlich eine der besten Kurzeinführungen in das Thema überhaupt. Wer DB2 zwar nicht nutzen, aber in das Thema relationale Datenbanken einsteigen will, für den lohnt sich die Installation schon allein wegen dieses Dokuments.

Fazit

Mit DB2 ist ein professionelles Datenbanksystem für Linux verfügbar. Viele der Funktionen werden aber auch von anderen (Open-Source-)Produkten abgedeckt, so dass unbedingt zu untersuchen ist, ob es tatsächlich DB2 sein muss. Wer allerdings auf ein plattformunabhängiges Produkt setzen will, das performant und skalierbar ist, sollte DB2 in die engere Wahl ziehen.

Weitere Informationen sind im Internet verfügbar (siehe [1] bis [6]). Dort gibt es auch Download-Möglichkeiten für die DB2-Produkte sowie für Patches.

DB2 in der Version 7.2 unter Linux 2.4.3 hat übrigens kürzlich in einem Benchmark den SQL-Server 2000 unter Windows 2000 in der 100GB-Klasse geschlagen. Diese Bench marks haben allerdings nur einen eingeschränkten Wert; in diesem Fall zeigen sie aber deutlich, dass das alte Vorurteil inzwischen überholt ist: Linux ist eben nicht nur eine gute Plattform für Webserver, sondern auch für unternehmenskritische Anwendungen geeignet. ( fjl)