Portabilität ist nicht allein vom Betriebssystem abhängig. Ohne Schnittstellen-Standards für die systemnahe Software, und Datenbank-Management-Systeme kann Herstellerunabhängigkeit nicht Realität werden. Axel Kropp* hat die Kriterien für ein DBMS zusammengestellt, das unter Unix lauffähig ist.
Nahezu alle Computerhersteller offerieren heute Unix-Systeme als Mainline-Produkte. So will es der Markt. Immerhin haben viele Behörden und Großanwender das Betriebssystem in ihre Beschaffungsrichtlinien aufgenommen. Denn die große Idee, unter der Unix einst antrat, hieß Portabilität: hardwareunabhängige Übertragbarkeit von Betriebssystemen und Anwendungen.
Doch dieser schöne Traum war spätestens dann ausgeträumt, als die Hersteller Unix um systemnahe Software ergänzen mußten - zum Beispiel um Datei- und Datenbanksysteme. Wo bleibt die Portabilität, wenn das Datenbanksystem (DBMS) eines Herstellers nicht auf der Hardware des Konkurrenten verfügbar ist?
Das Problem der technischen und vertrieblichen Durchsetzung portabler Anwendungen war schließlich auch der Grund für die elf Mitglieder der X/Open Group, neben Unix alle Komponenten festzulegen, die für übertragbare Anwendungen relevant sind - einschließlich der Schnittstellen zum Datenbanksystem. Das von der Anbietervereinigung definierte und im sogenannten Portability Guide veröffentlichte Ergebnis zum Stichpunkt DBMS-Schnittstellen verdient besondere Berücksichtigung.
Heterogene HW-Umgebungen bedingen neue Strategien
Ein weiteres wichtiges Thema sind die Datenbank-Eigenschaften, die primär in dezentralisierten Organisationen mit heterogener Hardware gefordert sind. Projekte in diesem Bereich tragen den Stempel einer neuen strategischen Ausrichtung: Herstellerunabhängigkeit, langfristiger Schutz der Software-Investitionen sowie die Implementierung von Standards stehen im Vordergrund. Außerdem ist hier eine stärkere Integration von Anwendungen, redundanten oder verteilten Datenbeständen sowie inkompatiblen Systemen gefordert.
Die von Unix unterstützten Ein-/Ausgabe-Funktionen bestehen nur aus Bytestrom-orientierten Schreib-/Leseoperationen in Dateien. Die Bearbeitung von Files als Satzmengen ist nicht vorgesehen. Demzufolge müssen in den Anwendungen Vorkehrungen für die Satzbehandlungen getroffen werden, was einerseits den Programmieraufwand und andererseits die Zahl der nichtstandardisierten Verfahren erhöht. Durch die Kombination mit einem Datenbanksystem läßt sich dieser Mangel beheben.
Index-Knoten zeigen auf die aktuellen Daten
Zwei Punkte beeinflussen die Implementierung eines DBMS unter Unix erheblich: der Buffer Cache und das Filesystem. Letzteres hat eine invertierte Baumstruktur mit dem obersten Verzeichnis als Wurzel. Das Betriebssystem nutzt drei Ebenen des Baumes für den indirekten Zugriff auf die Daten; Index-Knoten zeigen dabei auf die aktuellen Daten oder auf den nächsten Index-Knoten.
Diese Technik erlaubt maximalen Plattenspeicher, kann jedoch eine starke Fragmentierung der Daten bedeuten. Datenblöcke, die zu einer Datei gehören, können letztendlich über viele Bereiche der Platte verteilt sein. Für die Performance einer Datenbank ist wichtig, daß der Datei ein kontinuierlicher Bereich zur Verfügung steht.
Das Filesystem ist rein auf die Verwaltung von Texten und Programmquellen ausgelegt. Es ist problematisch, mit diesem Unterbau ein stabiles DBMS zu konstruieren; insbesondere deshalb, weil der Zeitpunkt, zu dem die Änderung einer Datei aus dem Systempuffer auf die Platte geschrieben wird, nicht ausreichend definiert ist.
Beschränkungen des Buffer Cache aufheben
Bei dem Unix Buffer Cache, dem Systempuffer also, handelt es sich um einen RAM-Bereich, der in Verbindung mit dem Filesystem zum Einsatz kommt (siehe Abbildung). Von der Platte gelesen, werden die Datenblöcke zuerst in den Buffer Cache und dann in den entsprechenden Benutzer- beziehungsweise Anwendungsdatenbereich kopiert. Beim Schreiben auf die Platte gehen die Daten wiederum über den Buffer Cache. Für viele Anwendungen ist das eine gute Lösung, aber nicht für Datenbanken. Dafür gibt es drei wichtige Gründe:
Zunächst wird bei der Beendigung einer DB-Transaktion davon ausgegangen, daß die Daten auf der Platte gespeichert sind. Unter Unix hat man allerdings nur die Garantie, daß die Daten im Buffer-Cache sind. Bei Abbrüchen könnte die Datenbank also verfälscht werden.
Zweitens haben Nicht-DBMS-Benutzer unter Unix die Möglichkeit den Inhalt des Buffer Cache komplett herauszuschreiben. Das könnte einen dramatischen Einfluß auf die Performance der Datenbank haben.
Außerdem sind zusätzliche Systemaufrufe notwendig, um die Daten via Buffer Cache zu bewegen. Das kann die Datenbank-Performance ebenfalls beeinträchtigen.
Ein Datenbanksystem unter Unix muß die geschilderten Beschränkungen des Buffer Cache aufheben. Eine Möglichkeit für die DB-Software basiert auf der Option "Write-through Cache" des System V Release 2. Dabei sind die Dateien während des Warmstarts geöffnet und mit speziellen Argumenten gekennzeichnet. Dem Betriebssystem wird so mitgeteilt, daß es keine Prozesse weiterlaufen lassen soll, bevor die Daten tatsächlich auf die Platte geschrieben sind. Damit ist die Datenintegrität sichergestellt.
Leider aber ist die Option "Write-through Cache" auf einigen hybriden Unix-Systemen nicht verfügbar. Der einzige Weg, hier die Vollständigkeit der Daten zu gewährleisten, basiert auf der Verwendung des "Unix Raw Device". Das ist im Prinzip ein Stück Platte, das vom Datenbanksystem selbst verwaltet wird.
Die Pufferung und Freispeicherverwaltung des Raw Device erfolgt nicht mehr über den Kernel, sondern direkt durch das DBMS. Bei dieser Technik kann auf die Datenbestände nur noch über das Datenbanksystem zugegriffen werden; und dessen Schutzmechanismen lassen sich nicht unterlaufen.
Multivolume-Dateien sind zu unterstützen
Das Unix Filesystem ist nur für kleine Plattenoperationen ausgelegt - normalerweise nicht mehr als 1-bis 4K-Blöcke per I/O. Ein Raw Device kann hingegen bis zu 32 4K-Blöcke per I/O unterstützen.
Nicht zuletzt sollte ein Datenbank-Management-System mit Unix-Eignung Multivolume-Dateien und -Tabellen unterstützen. Das heißt: Eine einzige Tabelle muß sich über mehrere Laufwerke fortsetzen können. Auch dies ist eine Funktion, die das DBMS selber mitbringen muß, da Unix keine Multivolume-fähigen Dateien kennt.
Unabhängige Anbieter bestimmen die Szene
Der Markt für solche Datenbanksysteme ist - im Unterschied zu den DBMS für Hersteller-Betriebssysteme - überwiegend in der Hand der unabhängigen Software-Industrie. Der technische Vorsprung mag ein Grund dafür sein, der Trend zur Herstellerunabhängigkeit ist ein anderer. Auffallend ist, daß die meisten dieser Produkte auf der relationalen Technik basieren und die Abfragesprache SQL anbieten.
In den letzten zwei Jahren hat auf dem DBMS-Markt eine nicht mehr umkehrbare Wende zur relationalen Technik stattgefunden. Datenunabhängigkeit, Flexibilität, leichtere Erlernbarkeit und - daraus resultierend - höhere Produktivität bei der Anwendungsentwicklung sind die Vorteile eines relationalen DBMS. Deshalb sollte auch das Unix-DBMS mit dem relationalen Modell übereinstimmen und die Daten einzig und allein durch seine relationalen Fähigkeiten verwalten.
Hersteller- und produktunabhängige, international verbreitete DV-Standards bilden die Basis für offene Systeme. Diese wiederum sind Voraussetzung für portable Anwendungen, Unix-Anwender haben sich für dieses Betriebssystem unter anderem deshalb entschieden, weil sie DV-Standards anstreben. Um das Ziel herstellerunabhängiger Normen nicht aufzugeben, muß dieses Verständnis bei anwendungsnaher Software, also auch in bezug auf ein Datenbanksystem, beibehalten werden. Eine weitverbreitete und nunmehr offiziell standardisierte Schnittstelle zu relationalen Datenbanksystemen ist die im ANSI-Dokument "Relational Database Language (SQL) - ANS X3.135-1986" definierte Norm: die Standard-Datenbanksprache SQL.
Unix-DBMS-Anwender sollten SQL sowie X/Open-Kompatibilität verlangen. Um der wachsenden Bedeutung von relationalen Datenbanksystemen gerecht zu werden, hat die Anbietervereinigung auch hier Schnittstellen definiert. Diese Festlegung lehnt sich eng an den ANSI-Standard an, der eine Normerfüllung in zwei Stufen vorsieht.
Die meisten der vorliegenden Produkte erfüllen nur die Anforderungen der ersten Stufe. Das dort festgeschriebene SQL ist für die Anwendungsentwicklung nicht geeignet, da noch zu viele Bereiche der Definition dem Implementierer überlassen bleiben. Die Mitglieder der X/Open Group haben sich für diesen Bereich auf einen gemeinsamen Ansatz geeinigt. Der Portability Guide bietet eine vollständige Beschreibung der SQL-Syntax und -Semantik sowie einen detaillierten Vergleich mit dem ANSI-Standard.
Aus Gründen der Herstellerunabhängigkeit sowie im Sinne einer unternehmensweit einheitlichen Informationsverarbeitung dürfen die Datenbanksoftware, die Anwendungen sowie die Daten nicht nur auf X/Open-kompatiblen Unix-Systemen einsetzbar sein. Sie müssen auch die verbreitetsten Hersteller-Betriebssysteme berücksichtigen, zum Beispiel MVS oder VM von IBM, BS2000 von Siemens, VMS von Digital Equipment und auf der Arbeitsplatzebene die PC-Systeme. Voraussetzung ist, daß sämtliche DBMS-Versionen vom PC bis zum Mainframe für den Benutzer identisch sind. Datenbanklösungen, die nur unter Unix ablaufen, sind einfach weniger wert. Dies gilt natürlich gleichermaßen oder noch deutlicher für Lösungen unter Hersteller-Betriebssystemen.
Jeder HW-Typ erfordert eine spezielle Portierung
Im übrigen läuft ein DBMS, das unter Unix System V auf einem beliebigen 68020-basierten Mikrocomputer gefahren werden kann, nicht unbedingt auch unter System V auf einem anderen 68020-Rechner. Der Anbieter muß für jeden Hardware-Typ eine spezielle Portierung bereitstellen, um die jeweilige Architektur optimal zu nutzen. Das betrifft insbesondere RISC-Architekturen, Multiprozessor- und fehlertolerante Systeme.
Keine Frage: Wer mit vernetzten Systemen im Umfeld von IBM Geschäfte machen will, muß SNA-kompatibel sein. Wer sich außerhalb dieses IBM-eigenen Standards bewegt, kämpft vergeblich.
Der gleiche Vorgang wiederholt sich im Bereich Informations-Management: DB2-Kompatibilität oder zumindest Koexistenz mit IBM ist angesagt. SQL-basierende Software, die beispielsweise für ein dezentrales Unix-System entwickelt wurde, sollte mit möglichst wenigen Änderungen auch unter DB2, dem strategischen DBMS-Produkt der IBM, laufen. Und ein künftiges verteiltes Datenbanksystem wird sich kaum durchsetzen, wenn es einen DB2-Knoten für den Benutzer nicht genauso behandelt wie die Knoten, auf denen das eigene Datenbanksystem installiert ist.
Technische und politische Sackgassen umgehen
Es gibt einige Basisforderungen an ein Unix-DBMS für komplexe zentrale und dezentrale Anwendungen von morgen, die nicht in einer technologischen oder herstellerpolitischen Sackgasse enden sollen. Diese Liste liest sich wie folgt: relationales Modell, Datenbanksprache SQL, angemessene Performance- und Sicherheitsfunktionen, Portabilität vom PC bis zum Mainframe einschließlich der Nicht-Unix-Systeme und spezielle Architekturen wie fehlertolerante Systeme, möglichst IBM-Kompatibilität und last but not least ein Verteilungskonzept als Zukunftsoption.
*Axel Kropp ist Geschäftsführer des Büros für Informatik (BFI) in Toppenstedt bei Hamburg.