Seit kurzem gibt es eine ganze Reihe von Herstellern, die Unix auch für die Online-Transaktionsverarbeitung (OLTP) anbieten. Doch die Zweifel wollen nicht verstummen, ob dieses Betriebssystem für eine solche Betriebsart überhaupt geeignet ist. Im folgenden begründen Ruth Hoffman und Jeff Pancottine ihre Überzeugung, daß die OLTP-Schwäche von Unix der Vergangenheit angehört.

Die Definitionsversuche von OLTP rufen eine kontroverse und emotionsgeladene Diskussion hervor. Eine allgemeingültige Definition gibt es nicht, und wird es wohl auch nicht geben. Daher läßt sich diese Form der Datenverarbeitung gewöhnlich durch die Eigenschaften der Umgebung definieren, in der sie eingesetzt ist.

Typischerweise verarbeiten OLTP-Systeme große Mengen von Daten im interaktiven, sprich: Online-Betrieb, führen also umfangreiche Transaktionen durch. Diese Aufgaben gleichen sich in hohem Maße. Sie beziehen sich auf große Datenpools und erledigen simple Aufgaben wie eine wiederholte Datenbankanfrage oder Konto-Aktualisierung. Die Vorgänge treten meist in schneller Folge auf. Der Online-User verlangt von einem Transaktionsverarbeitungssystem üblicherweise interaktive Antwortzeiten über das Netzwerk im Bereich von einer Sekunde oder darunter.

Transaktionen können nicht dynamisch verifiziert oder wiederholt werden, daher müssen OLTP-Systeme gewährleisten, daß sie vollständig ablaufen. Mit anderen Worten: Ein OLTP-System muß fähig sein, zwischen dem Beginn und dem Ende einer Transaktion zu unterscheiden und einen Mechanismus bereitstellen, um mißglückte Transaktionen anzuzeigen oder sie zu wiederholen. Weiterhin sollte gesichert sein, daß die Datensammlungen oder Datenbanken, auf deren Grundlage die Anwendungen laufen, verfügbar sind, wenn sie gebraucht werden und darüber hinaus gegen Eingriffe in die Datenintegrität geschätzt sind.

Heute verlassen sich immer mehr Unternehmen auf Systeme mit OLTP-Merkmalen, um einen Wettbewerbsvorteil zu erreichen. Diese Systeme sind darauf abgestimmt, schnell auf Benutzeranfragen zu reagieren. Außerdem haben sie zentrale Bedeutung für die Einnahmenentwicklung eines Unternehmens. Sie nehmen Transaktionsdaten auf, die sie in angemessener Zeit verarbeiten. Die Benutzer erhalten so verbindliche Antworten zu genau dem von den Kunden gewünschten Zeitpunkt. (Siehe Kasten).

OLTP-Anforderungen an die Betriebsumgebung

Bei den im Kasten aufgeführten Beispielen ist das Online-Transaktionsverarbeitungs-System von der Betriebsumgebung abhängig. Sie stellt die nötigen OLTP-Kapazitäten bereit.

Die Umgebung besteht aus einem Betriebssystem, das die verfügbaren Hard- und Software-Ressourcen kontrolliert und optimiert sowie aus einer verläßlichen Hardware-Plattform. OLTP-Anwendungen sind von den zugrundeliegenden System-Fähigkeiten absolut abhängig, wenn es um ihre datenverarbeitenden Funktionen geht.

Die folgenden Abschnitte umreißen kurz die Eigenschaften einer Betriebsumgebung, die für OLTP-Anwendungen besonders wichtig sind:

- Datenbank- oder Dateisystem-Softwarepakete müssen die sogenannten ACID-Eigenschaften Atomizität, Konsistenz, Isolation und Dauerhaftigkeit garantieren. Daneben wird eine Software benötigt, die die Transaktionsverarbeitung überwacht und den Transaktionsfluß regelt.

- Das OLTP-Betriebssystem und die Hardware müssen in der Lage sein, große Mengen an Transaktionen in akzeptabler Zeit zu erledigen. Die Antwortzeiten sollten unterhalb einer Sekunde liegen. Das Betriebssystem muß der Anwendung die Leistungsfähigkeit der benutzten Hardware-Plattform zur Verfügung stellen können.

- Das Betriebssystem ist zudem für die Unterstützung großer, schneller und flexibler I/O-Konfigurationen zuständig. Es muß in der Lage sein, viele Hundert interaktiv arbeitende Anwender gleichzeitig zu versorgen. Dies beinhaltet, daß das Betriebssystem zumindest irgendeine Form der Multi-Programmierung zuläßt. Weiterhin sollten Vorkehrungen zur physischen Vernetzung einer großen Anzahl von Usern getroffen werden können.

Die Unterstützung großer Datenbankstrukturen auf Platte und im physischen Speicher ist ebenfalls von Bedeutung. Außerdem müssen die für Wartung und Verwaltung des Betriebssystems zuständigen Funktionen so konzipiert sein, daß sie mit solchen Datenstrukturen umgehen können.

- Unerläßlich ist auch eine Garantie für Datensicherheit und Systemverfügbarkeit. Oft gehen die Anforderungen an die Verfügbarkeit so weit, daß ohne Ausfallzeiten Daten verarbeitet werden müssen. Nachprüfbare Zuverlässigkeit ist ebenfalls ein wichtiger Gesichtspunkt. - Eine sichere Verarbeitungsumgebung hält die Bedrohungen des Verarbeitungsablaufes so gering wie möglich und gewährleistet Datensicherheit. Das Betriebssystem muß die OLTP-Anwendung bei der Abwehr nicht autorisierter System- und Datenzugriffe unterstützen. Das Verfälschen von Daten, sowohl absichtlich und zielgerichtet als auch durch ein Mißgeschick, muß ausgeschlossen werden.

Gleitender Übergang mit skalierbaren Systemen

Dieser Anforderungskatalog läßt sich noch um einige Features erweitern, die für einen sinnvollen OLTP-Betrieb wünschenswert sind. Dazu gehört eine skalierbare Betriebssystem-Architektur, die hilft, Hardware-Investitionen zu minimieren und dabei die Systemverfügbarkeit steigert. Skalierbare Systeme ermöglichen dem Anwender einen gleitenden Übergang von geringer Systembelastung zu hohen Anforderungen.

Außerdem sollte die Betriebssystem-Architektur anpassungsfähig genug konzipiert sein, um Innovationen bei neuen Hardware- und Software-Technologien zu unterstützen. Im Idealfall bedeutet das, daß sich neue Hardware- und Software-Lösungen in ein existierendes System integrieren lassen, ohne die betroffenen Dienstprogramme unterbrechen zu müssen. Ein in geeigneter Weise flexibel gestaltetes System würde eine derartige modulare Aufrüstung sowohl im Hardware- als auch im Softwarebereich erlauben.

Schließlich wird die Forderung nach einer offenen Architektur immer dringlicher. Der Grund: Solche Systeme sind in der Regel von den Anschaffungskosten her günstiger, erleichtern die Anwendungsentwicklung und ermöglichen eine systemübergreifende Kompatibilität. Schließlich sind auch OLTP-Anwendungen nicht isoliert, sondern müssen sowohl am gleichen Ort als auch über große Distanzen mit anderen Anwendungen kommunizieren.

Unix-Systeme für den OLTP-Betrieb

Wie gut schneidet Unix bei diesen hohen Anforderungen an ein Betriebssystem ab? Um den Wert von Unix in heutigen OLTP-Umgebungen angemessen würdigen zu können, müssen wir den Hintergrund des Unix-Systems beleuchten und seine Vor- und Nachteile einer genaueren Betrachtung unterziehen.

Die Vorteile von Unix liegen auf der Hand. Ursprünglich machte AT&T den Unix-Quellcode gegen eine entsprechende Gebühr für jedermann zugänglich. Diese offene Vertriebspolitik führte zur Vorstellung von Unix als einem "offen konstruierten" System. Eigenschaften und Umfang von Unix waren einer wachsenden Zahl von Interessierten bekannt und verständlich. Es gab keinen Versuch, die innere Arbeitsweise des UnixBetriebssystems zu verheimlichen.

Als Nebeneffekte dieser "Offenheit" gelten: Portierbarkeit der Anwendungssoftware, Verfügbarkeit von relationalen Datenbank-Systemen und TP-Überwachungssoftware, eine Unmenge Tools und Utilities und die Zusammenarbeit mit anderen Systemen über ein vielfältiges Angebot an Übertragungsprotokollen. Diese Vorteile verlangen die Anwender nun auch für den kommerziellen Einsatz und wollen daher OLTP-Systeme in den Anwendungskatalog aufgenommen wissen.

Von Anfang an war das Betriebssystem Unix modular und in deutlich unterscheidbaren aufgebaut. Die Hardware-Funktionalität wurde klar durch ihre implementierungen, in den Unix-Kernel vom nicht hardwarespezifischem Code getrennt. Dieses modulare Design machte die Unix-Umgebung relativ leicht über eine Reihe deutlich verschiedener Hardware-Architekturen transportierbar.

Außerdem kündigten einige sehr grundlegende Prinzipien des ursprünglichen Unix-Designs dessen Eignung als OLTP-Umgebung bereits an. Unix war als multitasking- und multiuserfähiges Betriebssystem entwickelt worden.

Der Mehrprogramm-Betrieb erlaubt einzelnen Benutzern und Anwendungen gleichzeitig den Zugriff auf die Systemresourcen. Dazu gehören auch eine Zeitablaufplanung für den Gemeinschaftsbetrieb, Speicherverwaltungsroutinen, Kommunikationsmöglichkeiten zwischen Prozessen sowie Mehrplatz-Sicherheitsmaßnahmen wie Benutzeridentifizierung und -autorisierung.

Das Dateisystem ist hierarchisch aufgebaut und so implementiert, daß es auswechselbar bleibt. Außerdem kann das Dateisystem mehrere gleichzeitig arbeitende Benutzer durch Kontrolle und Schutz der Zugriffsbeschränkungen unterstützen. Geräte- und Datei-Ein-/Ausgabe wurden zueinander kompatibel und strukturunabhängig entworfen. Die Tatsache, daß ein weites Spektrum von Software-Entwicklungswerkzeugen und die Programmiersprache C erhältlich waren, ermutigte zur Entwicklung von Anwendungspaketen.

Die historischen Grenzen von Unix

Die ersten kommerziellen Unix-Versionen tauchten 1974 auf. Diese Produkte waren dazu bestimmt, auf Rechnern wie der PDP-11 von DEC zu laufen. Bis Mitte der 80er Jahre unterstützte Unix weder Hochleistungs-CPUs, umfangreiche Netzwerk- und Terminalverbindungen, noch große physische Speicher- und Platten-Konfigurationen oder Hardware-Simultanverarbeitung. Auch waren weder die Verarbeitungsfunktionen noch der Code des Kernels hinreichend zuverlässig.

Wichtiger für den OLTP-Bereich ist, daß die 110-Leistung und Flexibilität innerhalb von Unix schon immer als die Schwachstellen des Betriebssystems galten. Dateistrukturen und Dateiumfang ließen viel zu wünschen übrig. Fragmentierung und geringe Blockgröße verhinderten hohe Übertragungsraten von und zu den Plattenlaufwerken. Die Unzuverlässigkeit dieses Subsystems führte bei Fehlfunktionen zu Problemen mit den Dateien. Der Mangel an Adressierbarkeit bei großen Platten-Verbundsystemen limitierte darüber hinaus die Größe der Datenbanken.

Die Art der Vernetzung von Terminals und Rechnern paßte selten zu den anderen verfügbaren Geräten. So konnten große Platten-Verbundsysteme und Netzwerk- oder Terminal-Systeme nicht auf demselben System koexistieren.

Das Problem der Datenintegrität hat man einfach links liegengelassen, da Zuverlässigkeit bei Unix nicht zu den ursprünglichen Zielen gehörte. Das gleiche gilt für die Systemverfügbarkeit. jeder Unix-Kenner ist vertraut mit dem berechtigten Unix-"panic". Schon dieses eine Merkmal ließ DV-Managern, die Unix für OLTP-Anwendungen in Erwägung zogen, Schauer über den Rücken laufen.

Weitere Einschränkungen ergaben sich durch die Notwendigkeit, das Betriebssystem bei jeder Kernel-Änderung neu zu generieren. Dazu gehörte die Modifizierung der Kernelparameter, die Rekompilierung des Kernels und einen Neustart des Systems. Die Algorithmen für die Zeitverwaltung von Prozessen und Transaktionen basierten auf einem Zeitscheibenmechanismus nach der unflexiblen Reihum-Methode. Es gab keine Möglichkeit, wichtigen Transaktionen im System Prioritäten zuzuweisen.

Aufgrund dieser Mängel ist es kein Wunder, daß den frühen Unix-Versionen die Fähigkeit abgesprochen wurde, in großem Maßstab Online-Transaktionsverarbeitungen zu unterstützen. Der Bedarf an OLTP war jedoch vorhanden. Nun fiel den Hardwareherstellern, die Unix-Systeme als Betriebssystem für ihre Hardware mitlieferten, die Aufgabe zu, am Unix-Kernel spezielle Veränderungen vorzunehmen, um OLTP zu ermöglichen.

Doch bevor die Hersteller diese Aufgabe in Angriff nehmen konnten, war es nötig, einen Satz allgemeiner Funktionen festzulegen. Die Gemeinsamkeiten wurden inzwischen fixiert durch die verschiedenen Komponenten der System V Interface Definition (SVID) und durch Routinen, die in der System V Verification Suite (SVVS) zu finden sind. jede Anwendung, die in Übereinstimmung mit der SVVS geschrieben wird, ist relativ einfach auf dazu konforme Plattformen portierbar.

Der modulare Aufbau der Unix-Architektur erlaubte eine Modifikation des zugrundeliegenden Unix-Kernels, während das spezifische "Look and Feel" einer robusten Betriebsumgebung für Endanwender und Anwendungsentwickler beibehalten wurde. Die wahrscheinlich bedeutendste Veränderung an den Kernelroutinen betraf die Unterstützung einer größeren Anzahl von Prozessoren mit höherer Leistung.

Dabei gab es zwei Varianten. Eine Herstellergruppe bemühte sich um die Unterstützung von hierarchischen Multiprozessor-Umgebungen. Andere entschlossen sich, eine solche Architektur in Form lockerer Verbände zu implementieren.

Das Ergebnis ist die als System V bekannte Version des Unix-Betriebssystems. Es unter. stützt inzwischen in der Version V.4 symmetrisches Multiprocessing und kommt in bestimmten Implementierungen selbst mit massiv parallelen Prozessorarchitekturen zurecht.

Ein zweiter Problemkreis war die Speicherverwaltung. Frühe Unix-Versionen unterstützten hier einmal mehr nur simple Prozeß-Auslagerungsroutinen, um einen Mehrprogrammbetrieb zu ermöglichen. Die ursprünglichen Anforderungen setzten lediglich voraus, daß das System den Überblick behielt, welche Speicherabschnitte welchen ausgeführten Programmen zuzuordnen sind. Wenn das System mehr Speicherplatz benötigte, wurden ganze Programme vom Hauptspeicher auf Platte ausgelagert.

An den Unix-Speicherverwaltungs-Komponenten sind zahlreiche Veränderungen vorgenommen worden, damit sich auch ein Teil von Prozessen verlagern und eine Aufteilung von Programmabläufen auf mehrere Speicherseiten - soweit die Hardware dies erlaubte - realisieren ließ.

Es wurden Funktionen zur gemeinsamen Nutzung von Speicherbereichen durch mehrere Prozesse hinzugefügt. Diese gemeinsam genutzten Abschnitte konnten vor Swapping und Paging geschätzt werden. Auch Daten und Text eines Prozesses ließen sich im Speicher bei Abläufen mit hoher Priorität gegen ein Verlagern sperren.

Gemeinsam genutzter Speicherplatz ist eine besonders wichtige Einrichtung, um Unix für OLTP-Umgebungen zu optimieren.

Erst dieses Feature macht es möglich, große Datenbanken effizient zu bearbeiten und die Antwortzeiten zu verbessern, da aktuelle Daten anstatt auf Platte im physischen Speicher gehalten wurden.

Mehrere Abläufe gleichzeitig möglich

Die OLTP-Anbieter bemühten sich auch, die Zahl der möglichen Arbeitsplätze zu erhöhen, die sich an ein Unix-System anschließen lassen. Interne Datenstrukturen von Unix sind inzwischen dahingehend geändert, daß zumindest grundsätzlich eine unbegrenzte Zahl von interaktiven Terminal-Verbindungen unterstützt werden. Das System läßt mehrere Abläufe gleichzeitig zu. Auf der Hardwareseite stehen jetzt Schnittstellen sowie Verbindungsstrukturen für lokale Netzwerke (LAN) und Weitbereichsnetze (WAN) zur Verfügung.

Weitere Bemühungen galten der Sicherung der Datenintegrität. Hier lagen lange Zeit die größten Vorbehalte der Anwender. Der Unix-Kernel ist jedoch durch AT&T und das Unix System Laboratory (USL) einem ständigen Debugging unterworfen und in seiner Zuverlässigkeit verbessert worden.

Einzelne Hersteller haben Probleme des Kernels unabhängig von USL beseitigt. Sie entfernten oder maskierten die sogenannten Panic-Fehler, schrieben Teile des Kernels unter Zuhilfenahme von Fehlervermeidungstechniken um und stellten, im Falle von Sequoia, Software-übergreifende Detektions- und Wiederherstellungsmechanismen bereit.

Viele OLTP-Umgebungen verlangen eine kontinuierliche Systemverfügbarkeit. Um sie zu garantieren setzten die Hardware-Anbieter auf die Verwendung von besonders erprobten Bauteilen mit hohen Fehlertoleranzen. Auf diese Weise konnte die Zuverlässigkeit von Unix erheblich gesteigert werden. Auch Plattenspiegelung ist hier ein zentrales Feature.

Zu den Erweiterungen gehört auch die Möglichkeit, Kernel-Parameter während des Programmlaufs - "on the fly" - zu ändern und die Leistung währenddessen online zu überwachen. Somit sind "sys gens" für das Betriebssystem nicht mehr erforderlich, was die Nutzungszeit des Gesamtsystems verbessert. Die Chance, Wartungsarbeiten am System online durchzuführen, einschließlich der Online-Ergänzung von Ressourcen, sorgt ebenfalls für kontinuierlich verfügbare Systeme, die für OLTP-Umgebungen unbezahlbar sind.

Ein weiteres zentrales OLTP-Merkmal ist realisiert worden: Es können feste Prioritätsschemata bereitgestellt werden. Dies erlaubt den Ablauf der Transaktionen in einer zweckmäßigen Reihenfolge mit entsprechend gesetzten Prioritäten und läßt relativ wichtigen Transaktionen mehr CPU-Zeit.

Während all dieser Veränderungen an der Unix-Betriebsumgebung blieb eine gemeinsame, standardisierte Linie erkennbar. Anwender, die mit einer bestimmten Ausprägung von Unix vertraut sind, werden kaum Schwierigkeiten haben, zu irgendeinem anderen Unix-System zu wechseln. In ähnlicher Weise lassen sich Anwendungen, die auf SVVS oder SVID abgestimmt wurden, ohne großen Aufwand auf andere normgerechte Systeme portieren.

Dazu gehören auch aktuelle Anwendungspakete von Drittanbietern wie relationalen Datenbank-Systemen für OLTP und TP-Überwachungsprogramme. Der größte Vorteil liegt jedoch in der Optimierung der Hardware-, Software- und Personalkosten.

Dreh- und Angelpunkt der näheren Zukunft von Unix als Grundlage für OLTP ist die Konsolidierung und Standardisierung der vielen bereits bestehenden OLTP-Funktionen. Die aufgelisteten Leistungsmerkmale haben sich in bezug auf die Anforderungen der Online-Transaktionsverarbeitung bereits bewährt. In den nächsten Jahren werden sich USL und die wachsende Zahl der Unix-Anbieter darauf konzentrieren, standardorientierte Unix-Plattformen mit OLTP-Fähigkeiten zu implementieren.

Transaktionsvererbeitung spielt eine wichtige Rolle

Über die unmittelbaren Aufgaben hinaus stehen den betreffenden Organisationen weitere Herausforderungen ins Haus. Ironischerweise bekommt Unix derzeit gerade im Feld der offenen Systeme Konkurrenz. Immer häufiger melden Fachleute Zweifel an der Unix-eigenen "Offenheit" an. Organisationen wie ACE behaupten, im Besitz anderer Produkte zu sein, die noch "offener" sind.

Geht man jedoch von den Entwicklungsplänen aus, wie sie von Unix International formuliert wurden, so ist die Zukunft von Unix als OLTP-Betriebssystem völlig klar. Dort nimmt die Transaktionsverarbeitung eine zentrale Rolle ein. Schon heute hat die Organisation diverse Arbeitsgruppen unterstützt, die sich speziell mit den Erfordernissen von OLTP unter Unix befassen. Diese Arbeitsgemeinschaften gliedern sich in Gruppen, die für Dateiverwaltung, Simultanverarbeitung, Benutzerschnittstelle, Betriebssystem-Sicherheit und Transaktionsverarbeitung verantwortlich zeichnen.

Pläne für die Zukunft

Eine Hauptquelle für die Pflichtenhefte der Arbeitsgruppen ist die von der X/Open-Gruppe herausgegebene Open Systems Directive (OSD). Diese Richtliniensammlung besteht aus einer Reihe von Standardisierungsvorschlägen, die alle Aspekte der automatisierten Datenverarbeitung abdecken sollen.

Die Zukunftspläne, wie sie in der Roadmap dargelegt sind, umfassen Support für verteilte Transaktionsverarbeitung, Erweiterungen des System-Managements und Systemverwaltungs-Toots, weitere Maßnahmen zur Steigerung der Zuverlässigkeit des Kernels, Fehlereindämmung sowie Unix-Unterstützung für Transaktions-Überwachungssysteme.

Inzwischen existieren Unix-Versionen, die mit der Fähigkeit zum symmetrischen Multiprocessing ausgestattet sind und die die B2-Sicherheitsstufe erreichen.

Beispiele für OLTP-Anwendungen

1. Das klassische und oft zitierte Beispiel für den OLTP-Einsatz ist das Reservierungssystem der Fluggesellschaften.

Zugang zu dieser Datenbank erhalten Reisebüros, Unternehmen und private Anwender, die den Reservierungsservice in Anspruch nehmen wollen, durch ein großes Kommunikations-Netzwerk.

Sobald Anwender auf das System zugreifen können, führen sie eine Reservierungsfunktion - also eine Transaktion - durch. Alle abgeschlossenen Transaktionen werden vom System bestätigt. Die Reservierungsfunktion - in diesem Beispiel eine Transaktion kann darin bestehen, Fluginformationen aufzurufen, die Verfügbarkeit von Sitzplätzen abzufragen, einen Sitzplatz zu reservieren (unter Berücksichtigung von Kostenerwägungen) oder eine Reservierung zu widerrufen. Sobald ein Platz zu einem festgesetzten Preis reserviert wurde, erhält der Benutzer die Bestätigung oder sein Ticket.

Das System muß intelligent und flexibel genug sein, denselben Platz nicht zweimal zu vergeben (obwohl dies oft absichtlich geschieht) und die Datenbank über die kurzfristigen Veränderungen des Flugplans zu informieren.

Dieser für unsere Zwecke Vereinfacht dargestellte Ablauf kann einige tausendmal pro Sekunde auftreten, und das 24 Stunden am Tag. Das Sabre-System der American Airlines erledigt über 2500 Transaktionen pro Sekunde, rund um die Uhr, sieben Tage die Woche, 365 Tage im Jahr. Diese enorme Menge an interaktiven Transaktionen macht es nicht leicht, die Forderung der Anwender nach sekundenschnellen Antwortzeiten zu erfüllen, und dabei zu gewährleisten, daß die Buchungen vom System auch tatsächlich registriert wurden.

2. Als anderes Beispiel für OLTP seien die Geldautomaten genannt, die in Banken den Kassierer ersetzen. Sie bieten Genauigkeit, Systemverfügbarkeit und schnelle Antwortzeiten. Diese Transaktionen sind klar definiert und bestehen im allgemeinen aus Anfragen des Benutzers über den Kontostand, Abhebungen, Einzahlungen und anderen Buchungen.

Benutzer von Geldautomaten erwarten verläßliche und schnelle Bankdienste. Dazu gehört, daß diese Bankdienstleistung rund um die Uhr verfügbar ist. Nichts würde die Kunden schneller zur Konkurrenz treiben als ein Netz von Automaten, die nicht zu jeder Tageszeit abrufbar sind.