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.
DB2 gibt es in verschiedenen Paketen zu kaufen. Unter Linux sind die folgenden Produkte verfügbar:
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.
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.
Alle Rezensionen aus dem Linux-Magazin
Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...
